Timeline for What key factor led to the sudden commercial success of MS Windows with v3.0?
Current License: CC BY-SA 4.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 13 at 15:22 | comment | added | cher-nov | Here is also proof that it was David Weise's success that prompted Microsoft to abandon OS/2 and break with IBM: news.microsoft.com/2000/09/10/… | |
| Dec 19, 2022 at 20:14 | comment | added | Thorbjørn Ravn Andersen | @supercat These days OpenJDK Java support compressed OOP's which use 32-bit references shifted left 3 bits (so refering to 8-byte chunks) to give a 35-bit address space. | |
| S Nov 18, 2020 at 6:20 | history | suggested | Dranon | CC BY-SA 4.0 |
Updated URL
|
| Nov 18, 2020 at 2:06 | review | Suggested edits | |||
| S Nov 18, 2020 at 6:20 | |||||
| Jun 22, 2018 at 4:57 | history | edited | jwzumwalt | CC BY-SA 4.0 |
deleted 20 characters in body
|
| Jun 21, 2018 at 0:19 | vote | accept | Brian H | ||
| Dec 1, 2017 at 21:40 | comment | added | supercat | ...but used 32-bit segment registers, such a mode could allow programs written in Java or .NET to access up to 64GiB of address space while using 32-bit object references (which could be more efficient than using 64-bit references everywhere). | |
| Dec 1, 2017 at 21:38 | comment | added | supercat | The 8088's segmented architecture design was IMHO vastly under-appreciated, in significant measure because of the poor quality of programming-language support and a shortage of segment registers (adding even one more would have helped a lot). Despite its limitations, it did a better job than any other architecture I've seen since of allowing a machine with 16-bit registers to access about 1024KiB of address space reasonably fluidly, and of avoiding any per-segment overhead beyond the requirement that segments be 16-byte aligned. If the 80386 had a mode that was similar... | |
| May 22, 2017 at 20:38 | comment | added | mschaef | @MichaelGeary Thanks so much for the note (as well as all you've done over the years to make the profession better.) | |
| May 21, 2017 at 7:00 | comment | added | Michael Geary |
@mschaef Wonderful job telling this story! And of course thanks for the kind mention. You're right, the FixDS technique worked in real mode. That's what I originally wrote it for, long before Windows 3.0. In fact, it would have worked fine with Windows 1.0 apps! The entire EXPORTS/MakeProcInstance() misadventure really never did need to happen. Raymond Chen has an article on it here, and this page on calling conventions is interesting too.
|
|
| Mar 10, 2017 at 9:02 | comment | added | Neil |
@mschaef Not GlobalLock specifically, but far pointers in general - you didn't have to worry about functions being relocated in memory. (Perhaps MakeProcInstance always returned a fixed far pointer, which would explain my confusion.)
|
|
| Mar 8, 2017 at 0:02 | comment | added | mschaef |
@Neil Maybe this? Selectors let the OS move blocks around without the application being aware, so GlobalLock looks like it mostly became superfluous: blogs.msdn.microsoft.com/oldnewthing/20041105-00/?p=37383
|
|
| Mar 7, 2017 at 22:34 | comment | added | Neil | @mschaef Sorry, I think I might have got that confused with the far call odd BP rule, but I was sure there was some other more significant benefit of protected mode, if only I could remember it. | |
| Mar 6, 2017 at 13:37 | comment | added | Luaan | @BrianH PC users also didn't have a problem with that. The main problem was for the programmers, not the users; utilising all the memory was tricky, so many didn't bother. DOS protected memory extenders already made that easy enough - though unsurprisingly, they evolved at pretty much the same pace as Windows. The 386 finally made it quite natural, especially in combination with Windows 3. | |
| Mar 5, 2017 at 12:14 | comment | added | mschaef |
@Neil That was Michael Geary who made the discovery. (He was also the key developer behind the amazing Adobe Type Manager.) MakeProcInstance was made irrelevant through the fact that SS was always what DSshould be at the time control was transitioning into a callback. It worked on real mode too. geary.com/fixds.html
|
|
| Mar 5, 2017 at 12:13 | history | edited | mschaef | CC BY-SA 3.0 |
edited body
|
| Mar 5, 2017 at 10:40 | comment | added | Neil |
Protected mode was important to developers too, for example it was discovered that you could make MakeProcInstance irrelevant by requiring protected mode.
|
|
| S Mar 4, 2017 at 23:13 | history | suggested | user | CC BY-SA 3.0 |
Copy-editing
|
| Mar 4, 2017 at 22:57 | review | Suggested edits | |||
| S Mar 4, 2017 at 23:13 | |||||
| Mar 3, 2017 at 21:42 | comment | added | maple_shaft | These are the answers that make this site awesome. This is why I am addicted to this site. | |
| Mar 3, 2017 at 20:20 | comment | added | mschaef | @BrianH Yeah... anything with a 68K was automatically in much better shape. Not only was there a wider address space, it wasn't segmented. MacOS had some self-inflicted issues going from 24 to 32 bit pointers, but nearly as bad as the growing pains from real mode x86. (Developers on pre-32 bit MacOS systems would sometimes store extra information in the top byte of a pointer.) | |
| Mar 3, 2017 at 19:29 | comment | added | Brian H | This answer really resonated with me because it tries to identify the "killer feature" that Windows 3 brought. Certainly PC users with high-end processors and memory must have felt hamstrung by an OS that could not utilize their hardware. Non-PC users did not have this problem. My Amiga, for example, could easily access every megabyte of RAM I could afford for it. | |
| Mar 3, 2017 at 15:30 | history | answered | mschaef | CC BY-SA 3.0 |