5 ms·

> and their insistence on keeping strict backwards compatibility with sub-par products (DOS, basically) might be debatable. All 64 bit versions of Windows can

> and their insistence on keeping strict backwards compatibility with sub-par products (DOS, basically) might be debatable. All 64 bit versions of Windows can neither run DOS applications nor Win16 applications (I described the technical reason for this at https://news.ycombinator.com/item?id=14246521 https://news.ycombinator.com/item?id=14246521).

temac 9y ago
I'm pretty sure that excuse is random bullshit. First, are handles limited to 16 bits in 32-bits Windows? I'm pretty sure they are not, especially when the 2 lsb are 0 for NT handles... Second, you could cherry-pick other random resource pointer and make up another excuse with the same power: e.g. "32-bits programs can not work under 64-bits Windows because pointers are 64-bits wide with 'all' (at least > 32) their bits used, so they won't fit in 32-bits pointers of 32-bits programs" That's not how retro-compatibility involving virtualization is engineered - that's pretty much the other way around! If MS wanted to make Win16 run on 64-bits Windows, they could have engineered it (without much difficulty). They choose not to (and I don't blame them too much for that) and as a result, maybe some (or a lot) of details that would have been needed to ease that implementation do not exist (maybe SOME handles were limited to 16-bits on 32-bits Windows, all the time or when the program was a 16-bits one - and the provision to limit to 16-bits is not there anymore in 64-bits Windows as a result of the lack of purpose it would have given the general lack of support of win16 on this plateform), which maybe makes it harder to do for a 3rd party now... (and even by MS, given Windows has evolved a lot since introduction of 64-bits)
- tracker1 9y ago
  If you really have 16-bit windows/dos software, these days dosemu or WINE may be better options under a VM (Not sure if ReactOS would work well enough). DosBox may work as well, depending on specific needs.
oblio 9y ago
While that's strictly true, there's a wider range of backwards compatibility they're keeping. See the whole Rust/Cargo problem on Windows. Windows files can't be named con, aux, etc., because the Windows file systems are backwards compatible, generationally, all the way to DOS, which didn't have subfolders initially and which reserved those keywords for special files. Then as DOS added subfolders it still kept that global restriction, then Windows adopted it... and here we are today. Windows is full of these things, a lot of them coming from DOS and more coming from Win16 or even early Win32. I know they broke backwards compatibility in the strict sense with Win64, but apart from this not many situations where they did it come to mind. And even for that, they only did it because the overall market for DOS/Win16 was tiny at the point when they did it.
- wolfgke 9y ago
  POSIX and its ecosystem is also full of this backwards compatibility baggage (I for example claim that X11 has a lot more outdated backward compatibility legacy than WinAPI - no surprise since it is much older). Just to give a few basic texts about this: The Unix-Haters Handbook: http://web.mit.edu/~simsong/www/ugh.pdf http://web.mit.edu/~simsong/www/ugh.pdf A Tale of Two Standards: A text by a person (Jeremy Allison) who understands both WinAPI and POSIX: https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html https://www.samba.org/samba/news/articles/low_point/tale_two... The reason why people tell this all the time with respect to Windows, but much more rarely with respect to POSIX and its ecosystem, is in my opinion that much more programmers have inhaled the latter.
- i336_ 9y ago
  Concurrently occurring Creation -> Obsolescence produces overlap: DOS Win3.1 Win95 Win10 Creat. Obsc. |---------App----------| |---App---| |-----App-----| ~1980=========================================~2020 |-----App-----| |-------App-------| |--------App--------> (Okay, that looked a little better in my text editor.)
  - tracker1 9y ago

temac 9y ago

I'm pretty sure that excuse is random bullshit. First, are handles limited to 16 bits in 32-bits Windows? I'm pretty sure they are not, especially when the 2 lsb are 0 for NT handles... Second, you could cherry-pick other random resource pointer and make up another excuse with the same power: e.g. "32-bits programs can not work under 64-bits Windows because pointers are 64-bits wide with 'all' (at least > 32) their bits used, so they won't fit in 32-bits pointers of 32-bits programs" That's not how retro-compatibility involving virtualization is engineered - that's pretty much the other way around! If MS wanted to make Win16 run on 64-bits Windows, they could have engineered it (without much difficulty). They choose not to (and I don't blame them too much for that) and as a result, maybe some (or a lot) of details that would have been needed to ease that implementation do not exist (maybe SOME handles were limited to 16-bits on 32-bits Windows, all the time or when the program was a 16-bits one - and the provision to limit to 16-bits is not there anymore in 64-bits Windows as a result of the lack of purpose it would have given the general lack of support of win16 on this plateform), which maybe makes it harder to do for a 3rd party now... (and even by MS, given Windows has evolved a lot since introduction of 64-bits)

tracker1 9y ago
If you really have 16-bit windows/dos software, these days dosemu or WINE may be better options under a VM (Not sure if ReactOS would work well enough). DosBox may work as well, depending on specific needs.

oblio 9y ago

While that's strictly true, there's a wider range of backwards compatibility they're keeping. See the whole Rust/Cargo problem on Windows. Windows files can't be named con, aux, etc., because the Windows file systems are backwards compatible, generationally, all the way to DOS, which didn't have subfolders initially and which reserved those keywords for special files. Then as DOS added subfolders it still kept that global restriction, then Windows adopted it... and here we are today. Windows is full of these things, a lot of them coming from DOS and more coming from Win16 or even early Win32. I know they broke backwards compatibility in the strict sense with Win64, but apart from this not many situations where they did it come to mind. And even for that, they only did it because the overall market for DOS/Win16 was tiny at the point when they did it.

wolfgke 9y ago
POSIX and its ecosystem is also full of this backwards compatibility baggage (I for example claim that X11 has a lot more outdated backward compatibility legacy than WinAPI - no surprise since it is much older). Just to give a few basic texts about this: The Unix-Haters Handbook: http://web.mit.edu/~simsong/www/ugh.pdf http://web.mit.edu/~simsong/www/ugh.pdf A Tale of Two Standards: A text by a person (Jeremy Allison) who understands both WinAPI and POSIX: https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html https://www.samba.org/samba/news/articles/low_point/tale_two... The reason why people tell this all the time with respect to Windows, but much more rarely with respect to POSIX and its ecosystem, is in my opinion that much more programmers have inhaled the latter.
i336_ 9y ago
Concurrently occurring Creation -> Obsolescence produces overlap: DOS Win3.1 Win95 Win10 Creat. Obsc. |---------App----------| |---App---| |-----App-----| ~1980=========================================~2020 |-----App-----| |-------App-------| |--------App--------> (Okay, that looked a little better in my text editor.)
- tracker1 9y ago