Calling all old-timers. 16->32bit now 32->64b switch

[ravedave]

What was it like back in the day switching over from 16 to 32 bit os + apps. Was it pretty bad?
I'm just trying to think what its going to be like with the hammer.

Assume x86-64 win XP comes out. Assume it has 32/64 bit mode switching (I've heard something along those lines) Will you have to reboot? COuld you run 32 and 64 bit apps at the same time?

Just think of the pain in the ass its going to be when you have to choose 64 or 32 bit versions of your apps. I'm betting it will be at least 3-5 years after the intro before x86-64 apps are completely available everywhere. Poor download.com is going to have to host 2 of every app now. How long do you think it will take M$ to releases VC++ VB and other compliers for the new platform?

I guess we should consider linux too but not really, Linux will make an excellent platform and I'm sure it will be the first out with os and app support (well thats easy since you have to compile most of your own apps anyways!)

 

[Pariah]

It won't be a big deal. With Hammer the 64bit mode is just an extention of x86 so it's backwards compatible. You won't need 2 copies of anything. The only difference is that in order to take advantage of 64bit computing you will need a 64bit OS and applications. If you run wintop.exe in Win98, you will see a combination of 16bit and 32bit dll's and applications running, it's not a big deal. Intel's Itanium and subsequent CPU's from this line are different in that they need all new software.

You won't have to do anything to switch between modes, the computer will do it behind the scenes on its own. Do you need to reboot windows now to run 16bit applications? As for choosing between 32bit and 64bit software, I don't see the confusion. If you have a 64bit capable system, you buy 64bit software to take advantage of it, if not, you buy 32bit.

 

[Oyeve]

Ah, back in the day program had tight code. no BSOD. Switching to 32bit just caused probs. Remember, 32bit coincided with windows. Not a good thing back then. I remember running native 32bit apps in dos but it was mainly high-end (for that time) video demos and such. I dont think there will be too much of a problem going 64. It'll be just as screwed up as it is now.

 

[ravedave]

Okay so assuming win xp x86-64 comes out then we should be able to run all 32 bit apps fine....
I've heard 64b doesnt give most apps any boost, so i wonder if most apps we migrate..
For a while compainies will have to compile both versions, simply because some ppl wont have the 64 bit.

How long did it take for 32b to become the standard? (It will probably take 2x longer now because of the AMD/Intel thing)

 

[arcas]

Re: conversion from 16-bit to 32-bit apps

From a low-level software development point of view, the conversion was a pain in the ass. At the time the conversion from 16- to 32-bits on x86 was taking place, I was working with a group that developed system level debuggers and compiler tools. The conversion from segmented 16-bit addresses to flat 32-bit addresses meant that basically any code that dealt with pointers needed to be examined and modified. It wasn't just low-level code like what we developed that was affected. At the time, the Windows 3.1 and OS2 1.3 APIs had alot of 16-bit pointer arguments. When the conversion to 32-bit came, all applications that used these APIs had to be changed. It wasn't as simple as merely recompiling your program with a new 32-bit compiler. It sucked and more importantly, it was error-prone.

The conversion from 32-bit to 64-bit will be similar but I think alot was learned from the hell people went through before. So now what you typically see is not so much hard-coding of pointer sizes and the like. Lessons have been learned. Overall I think the 64-bit conversion will go smoother.

The thing you have to keep in mind is that there was a pressing need for migrating from 16-bit to 32-bit apps: segmented 16-bit mode was a kludge and affected basically all applications. Today x86 is pretty much a world where addresses are a flat 32-bits. In general apps today have no need to migrate from 32- to 64-bits except for those apps that require huge (> 4GB) address spaces like databases. Going from flat 32-bit to flat 64-bit mode really doesn't imply a performance boost...you can test this for yourself using Solaris8/SPARC boxes.

And, in fact, that's what system designers are discovering: even on platforms like RS6000 and UltraSparc, there is somewhat of a reluctance on the part of developers to migrate their apps to 64-bit just for the sake of having a 64-bit app.

 

[Auric]

I remember adding the "Win32s" pack to Windows 3.1x so that some 32bit applications could be run. There was no compelling reason to but I suppose it eased the transition from the developers POV.

 

[splice]

One of the major benefits of the x86-64 is the additional new registers compilers/assmb. will be able to use. Increasing the number of registers is always going to increase performance. After all, it is the fastest memory.

 

[ravedave]

mmm sweet sweet registers..

 

[ravedave]

Is AMD just extending x86 and not trying to fix it at all? does anyone know the details of what thier adding??