Re: As programmers...have we come a long way since 1993?

From: gswork (gswork_at_mailcity.com)
Date: 10/10/03


Date: 10 Oct 2003 01:09:49 -0700

Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message news:<bm1s8g$gc7$1@titan.btinternet.com>...
> gswork wrote:
>

> >> > Now, it's all very OOP, very structured framework GUI, RAD/STL
> >> > approaches, DirectX/OpenGL and other big media libraries, 32 bit
> >> > memory models,
> >>
> >> That's about to change. 64-bit Windows is almost upon us.
> >
> > I haven't been keeping up with all that. Will things change
> > radically, or will it be gentler than the 16->32bit migration?
>
> Hard to say. I browsed briefly through the AMD 64-bit manual today and
> didn't see anything desperately radical, but I didn't look very hard. I
> guess it'll be same as last time - those who program with an eye for
> portability will have few or no problems, whereas those who don't give a
> damn will struggle.

It'll be interesting to see. If 'win64', as the main OS of PC users,
is notably different in compatibility with old win32 software then
it's going to be a headache. I found Win32 to be largely tolerant of
Win16 (very similar in many ways, anyway) and even DOS - so that being
the case Win64 should be largely tolerant of win32, which in turn is
largely tolerant of win16. So at least solitaire will still run!

(ok, i know it's gone 32 bit now....)

I think the main thing (or should that be 'winmain thing') for Win32
programmers is how to migrate, or not, to .NET VM code or Win64,
whatever that may be.

> > To some extent, with 'kitchen sink' software tools like java, c++/stl,
> > delphi & c# much of the data structures and algorithms are prepackaged
> > into the likes of Vectors, Tlists or whatever.
>
> True enough, but...
>
> > They're good stuff,
> > but perhaps mask some of the 'advanced fundamentals' from people
> > trying to learn about programming.
>
> ...this is the problem. If you don't know about, say, trees and lists, how
> will you know when to use a map and when to use a vector?

precicesely, much as i like those things i do ensure my understanding
before choosing to use them. If i can't implement a simple version
myself then i'm 'not allowed' to use the advanced one!

> >> We've certainly come a long way. But have we progressed? IMHO, with
> >> regard to quality, robustness, and efficiency, we have /regressed/ to
> >> quite a large extent.
> >>
> >> And that's a shame.
> >
> > Regressed? Perhaps in a sense of machine efficiency ('most work per
> > cpu cycle'), i'm not so convinced we've regressed in terms of overall
> > software quality and robustness though. At least i can think of no
> > overwhelming experience of mine, or research/anecdotes that point to
> > an actual regression.
>
> Find one of those touch-screen public information terminals - the kind you
> get in libraries, for example. (No, I don't have a particular model in
> mind.) Play with it for half an hour or so. Explore as many options as you
> can. (Try going Back/Forward/Back/Forward/Back/etc...) The chances are good
> that you'll be able to provoke either a Java null pointer exception or a
> Blue Screen of Death within the half hour. (And that exception is rather
> ironic, given that everyone /knows/ that Java doesn't have pointers!)

Who *does* write those things?!

In general though, casting my mind back to 1993, i don't think
software, at least PC based software, was more relaible then. I think
i encoutered the same 'rate of bugs per hour' as i do today, but i use
the PC more now - so notice more bugs.

> Look at the voting machine in Florida that recorded -16022 votes for Al
> Gore. Yes, MINUS 16022.
>
> Look at Windows XP and Windows 2000, with that very scary DCOM exploit.
> Suddenly, the mantras of "don't use pirate software" and "don't open email
> attachments" and "don't run strange binaries" are no longer sufficient to
> protect you against viruses.

Anyone online should have a simple firewall, there's loads available
for free too. That an OS for home use doesn't install one by default
is a bad start!

When i first used a software firewall years ago i was suprised just
how many attempts were being made to connect to port xx or whatever.
Not generally malicious i'm sure, but traffic i didn't want!

What was curious for me about the W2000 thing, i'd been using Win98
online for a while again - and for the first time felt safer than all
those people with their shiny new XP computers!

Windows 9x is now like DOS - almost all the virrii and exploits are
done, it's old hat for the crackers & wormers. Rigged up with good
protection it's less likely to come under any new attack, XP however
is the focus of the afforementioned so there'll be new attacks there.
 If Linux gets to a critical mass of use it'll attract them more and
more too, at least a properly set up Linux has more chance of
defending itself.



Relevant Pages

  • Re: The Future of native code
    ... the API targeted for 64-bit versions of Windows" ... But I still wonder about the future of native Delphi in the Win32 world. ... So, even risking being wrong as it can be dangerous to do "futurology" in IT, I'd say that CodeGear has enough Win32 and Win64 around for a few more decades. ... And if that runtime somehow fails to install, how well do you think those users will be able to "fix" it? ...
    (borland.public.delphi.non-technical)
  • Re: .Net and 64-bit
    ... Peter Morris wrote: ... Win32 or Win64. ... The version of Windows that the OP has doesn't tell you if it's a 32 bit system, but it tells you if it's a 64 bit system. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: .NET - end user reality check
    ... Kostya wrote: ... > Win32 and Windows in general had taken years and years to become ... And in the meantime Win64 is here, ...
    (borland.public.delphi.non-technical)
  • Re: Vista and .NET (Win32 life may be limted)
    ... but it will happen for the 32-bit API ... Maybe when there's a 128-bit version of Windows. ... Plus Win64 is pretty much Win32 with bigger integers. ...
    (borland.public.delphi.non-technical)
  • Re: Win32 TSR program skeleton
    ... under windows a "comsole" is just a thing used for display. ... are not avaible to Win32 apps, and are not created for Win32 console ... I need to write a TSR that does some periodical checks over another ... You should say that I can simple pipe the output to my app, but, ...
    (microsoft.public.win32.programmer.kernel)