If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#251
|
|||
|
|||
"Paul Repacholi" wrote in message
... 2000 was ready to go to the Win64 interface on Alpha but was stopped from proceding by M$. Is it your understanding that this is the basis for the current 64-bit Windows implementation? Also, out of curiosity (as I don't work on Windows), are there updated APIs for 64-bit applications that are backwards compatibile with the 32-bit ones - or has MS somehow designed their interfaces/control blocks/etc. so that this isn't a concern? Regards Dean -- Paul Repacholi 1 Crescent Rd., +61 (08) 9257-1001 Kalamunda. West Australia 6076 comp.os.vms,- The Older, Grumpier Slashdot Raw, Cooked or Well-done, it's all half baked. EPIC, The Architecture of the future, always has been, always will be. |
#252
|
|||
|
|||
In article ,
Ken Hagan wrote: Nick Roberts wrote: I don't think that's strictly correct. My memory is that Windows 95 was itself the first Windows which supported 32-bit code, when it was launched (in 1995 ;-) The immediately prior version of Windows was 3.11, which was 16-bit only (and ran on top of MS-DOS). The first version of NT (1991?) called itself Windows 3.1. It had its No. -- Thor Lancelot Simon But as he knew no bad language, he had called him all the names of common objects that he could think of, and had screamed: "You lamp! You towel! You plate!" and so on. --Sigmund Freud |
#253
|
|||
|
|||
Dean Kent wrote:
Windows implementation? Also, out of curiosity (as I don't work on Windows), are there updated APIs for 64-bit applications that are backwards compatibile with the 32-bit ones - or has MS somehow designed their interfaces/control blocks/etc. so that this isn't a concern? Short answer is yes. Long answer follows: Microsoft of all companies is very proficient at word size changes, backwards compatibility, and API design borne of necessity rather than purist design. These are the transitions they went through: - 8 bit to 16 bit (early machines, Basics, cloning CP/M) - 16 bits with slightly wider memory (DOS, extended memory, 286 and 386 flavours of early Windows 1/2) - 16 to 32 bits (but mostly 16) in Windows 3 - 32 bits with lots of 16 (Windows 95) - "Clean" design 32 (Windows NT) - 32 bits with longer addresses (PAE, Alpha, MIPS) - 64 bits (Itanic, AMD64) In general a binary is marked for a particular subsystem/version which implies sizes. When the underlying OS uses a different size various thunking or stub mechanisms are used to translate to the right sizes, as well as lots of backwards compatibility shims. Note that backwards compatibility doesn't just mean theoretically pure. It also means bugs or other behaviour. For example Windows 95 specifically recognised the Windows 3 version of SimCity which had a bug that used memory just after it had been freed. They run the memory manager in a different mode that ensures no crash happens. I recommend reading the historical articles in Raymond Chen's blog. http://weblogs.asp.net/oldnewthing/c....aspx?Show=All A selection: Why 16-bit DOS and Windows are still with us http://weblogs.asp.net/oldnewthing/a.../01/82103.aspx History of calling conventions: http://weblogs.asp.net/oldnewthing/a.../02/47184.aspx http://weblogs.asp.net/oldnewthing/a.../07/48303.aspx http://weblogs.asp.net/oldnewthing/a.../08/48616.aspx http://weblogs.asp.net/oldnewthing/a.../13/58199.aspx http://weblogs.asp.net/oldnewthing/a.../14/58579.aspx Sometimes an app just wants to crash: http://weblogs.asp.net/oldnewthing/a.../19/44644.aspx When programs grovel into undocumented structures: http://weblogs.asp.net/oldnewthing/a.../23/45481.aspx Why not just block the apps that rely on undocumented behaviour: http://weblogs.asp.net/oldnewthing/a.../24/45779.aspx Why are structure sizes checked strictly: http://weblogs.asp.net/oldnewthing/a.../12/56061.aspx What do the letters W and L stand for in WPARAM and LPARAM? http://weblogs.asp.net/oldnewthing/a.../25/55850.aspx What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? http://weblogs.asp.net/oldnewthing/a.../15/55296.aspx Why is address space allocation granularity 64K? http://weblogs.asp.net/oldnewthing/a.../08/55239.aspx My all time favourite about why Win95 didn't use the HLT instruction: http://weblogs.asp.net/oldnewthing/a.../28/54719.aspx Roger |
#254
|
|||
|
|||
"Dean Kent" wrote in message ... "David Brown" wrote in message ... Porting applications, on the other hand, is far easier. You have to consider the effect of having 64-bit integers, and you might have to consider endian issues, but mostly (if the original code is well-written) its a matter of re-compiling and testing the new binary. Well, I am not an OS developer - but I do work on system level applications (requiring hooks into the OS, use of low-level OS services, etc.). It seems to me that the biggest problem for the OS is the compatibility with existing applications. There will be control blocks (structures, whatever) and APIs that include addresses to data areas, calls to communicate with other programs, etc. You can't just change the size of the address areas for two reasons - the offsets for following data areas would change (requiring all applications using that structure/control block to be recompiled), and you have no idea if the applications using it can actually use the 'bigger' addresses. It also seems to me that you would have to include a mechanism whereby the OS knows whether the application is running 32-bit or 64-bit to make sure it doesn't allocate memory where the application can't access it - and it can't load the program in an address range it can't handle. The calls to other modules would have to include a mechanism whereby programs running in different addressing modes can still pass parameters and data to each other without causing major problems and crashes. IOW, moving an OS to 64-bit would not only require changing integer sizes and recompiling, but actually redefining the interfaces to work with both 32-bit and 64-bit programs (perhaps even mixed addressing modes). Making sure all of this works would be a huge undertaking, and could create situations where 95% of the code works fine, but a few critical apps have major problems that delay the OS release. That's all very true - that's more reasons to back up my "porting an applicaiton is relatively easy, porting an OS is hard" post. The OS has to sit between the hardware and the apps - I only mentioned that the low-level stuff was hard to port, but you are correct that there are issues on the app side to consider. Hence Win-on-win for 16-bit app support on 32-bit WinNT, and 32-bit loaders and libraries as well as 64-bit versions on 64-bit linux and Win64. Backwards compatibility matters, particularly in an environment where the OS vendor has support issues to deal with and wants to control what is running in the field. It may not be as big an issue with Linux (or may be), since there are no support issues to deal with and there is no attempt to control what is running in the field. "Want a 32-bit OS? Fine, run an older kernel - or someone else's 64-bit kernel that has support for it." Most people get their linux from OS vendors - what else would you call Mandrake, Suse (Novell), Red Hat, etc. ? Support and backwards compatibility is a big issue - in the linux world, if something works then people use it, they don't re-write it and expect people to pay for upgrades just that it will run on the latest version of your OS. There are programs in continuous use in linux systems (and any other *nix system) that haven't been changed in years - decades, maybe - simply because they already do the job they were meant to do. Most of these can, of course, be simply re-compiled at 64-bit for a 64-bit linux, but there are certainly plenty of occasions when you would want to run 32-bit binaries on 64-bit linux. At least, it works that way in the environment I am familiar with (not Windows or Unix... :-). Regards, Dean |
#255
|
|||
|
|||
Thor Lancelot Simon wrote:
In article , Ken Hagan wrote: Nick Roberts wrote: I don't think that's strictly correct. My memory is that Windows 95 was itself the first Windows which supported 32-bit code, when it was launched (in 1995 ;-) The immediately prior version of Windows was 3.11, which was 16-bit only (and ran on top of MS-DOS). The first version of NT (1991?) called itself Windows 3.1. It had its No. The first version of NT was released in 1993 and was called Windows NT 3.1. http://www.microsoft.com/presspass/f...98/winntfs.asp Details and screenshots of all Windows releases are at http://www.microsoft.com/windows/Win...roGraphic.mspx http://www.microsoft.com/windows/WinHistoryDesktop.mspx Roger |
#256
|
|||
|
|||
"Douglas Siebert" wrote in message
... (Patrick Schaaf) writes: Casper H.S. Dik writes: "Stephen Sprunk" writes: AMD64 is just another platform, and the third (or higher) platform supported is of marginal cost compared to the second. The free software world has had to contend with dozens of platforms for over two decades, and so the fact Linux (and all the common apps) ported over cleanly is hardly surprising. It's not really all that simple: while you can run a pure 64 bit OS on AMD64, there are many Linux applications only available as "32-bit, IA32" binaries. There are a few, yes, but most of the folks developing Linux couldn't care less if they cause closed-source developers a little pain. I haven't heard any complaints about problems running i386 binaries on amd64 kernels, so it appears to be a non-issue -- unlike with WinXP64. I don't see many of them on the ~1000 Linux systems I've got at work. There are bound to be some commercial apps where that's the case, but I'm sure Stephen was thinking about the ease for _open_source_software_ to be ported over. Actually, it applies to commercial software too. I worked at a company where the main product (an embedded OS) was shipped on a dozen different CPU types and once the cost of porting was paid (over a decade ago) for the second arch, the cost of adding a new arch was nearly zero. The key is making sure all new code is written portably, which so far has not been necessary in the Windows world. Some ISVs may decide it's cheaper to develop non-portable code over time; they'll pay dearly for porting once a decade and usually drop support for the older arch (as happened in the Win16-to-Win32 conversion). Do the AMD64 versions of Redhat and SuSE recompile everything? It seems kind to silly to have a 64 bit /bin/ls, for instance. They always left most stuff for which performance didn't matter compiled as i386, and for stuff where performance mattered (the kernel, openssl libraries, etc.) there were i686 versions. I would assume it is the same way for AMD64 stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have to do a lot more versions if they bugfix /bin/ls and have to compile a 64 bit version to go along with the i386 version! If /bin/ls were patched, somebody has to recompile it for dozens of other platforms, so what's the marginal cost in recompiling for amd64? It seems to be less than the cost of deciding which binaries on an amd64 installation should be kept as i386 and compiling your distribution appropriately. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov |
#257
|
|||
|
|||
In comp.sys.intel David Brown wrote:
Win32S was available before Win95, as was NT 3.51 (I believe NT 3.5 was the first easily-availble version of NT - marketing's idea of persuading people that it was a mature product). NT 3.1 was the first version available, with the 3.1 selected to be in parallel with the version of (non-NT) Windows available at the time. not support multi-tasking. It was mainly used for "big" programs, like CAD, or development tools, which could take advantage of the better memory management. And for a lot of the Windows 3.x web browsers. I remember deploying a ton of copies of Win32s so the lawyers I was supporting could use some now-archaic version of netscape while the higher-ups in IT planned how to transition to Win 95 (and then to WinNT 4, which was what we ended up moving to, right around when I left.) -- Nate Edel http://www.nkedel.com/ "I do have a cause though. It is obscenity. I'm for it." - Tom Lehrer |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Sudden Reboot - Dell XPS P4 3.0GHZ | Steve Buck | Dell Computers | 0 | November 17th 04 11:45 PM |
Harddisks: Seek, Read, Write, Read, Write, Slow ? | Marc de Vries | General | 7 | July 26th 04 02:57 AM |
Please Read...A Must Read | Trini4life2k2 | General | 1 | March 8th 04 12:30 AM |
Slow read speed on P4C800E Dlx | Dave | Asus Motherboards | 6 | January 20th 04 02:36 AM |
Seagate SATA 120GB raw read errors | Kierkecaat | General | 0 | December 16th 03 02:52 PM |