| Date: | March 1, 2004 / year-entry #78 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040301-00/?p=40453 |
| Comments: | 65 |
| Summary: | Many people are calling for the abandonment of 16-bit DOS and 16-bit Windows compatibility subsystems. And trust me, when it comes time to pull the plug, I'll be fighting to be the one to throw the lever. (How's that for a mixed metaphor.) But that time is not yet here. You see, folks over in... |
But that time is not yet here. You see, folks over in the Setup and Deployment group have gone and visited companies around the world, learned how they use Windows in their businesses, and one thing keeps showing up, as it relates to these compatibility subsystems: Companies still rely on them. Heavily. Every company has its own collection of Line of Business (LOB) applications. These are programs that the company uses for its day-to-day business, programs the company simply cannot live without. For example, at Microsoft two of our critical LOB applications are our defect tracking system and our source control system. And like Microsoft's defect tracking system and source control system, many of the LOB applications at major corporations are not commercial-available software; they are internally-developed software, tailored to the way that company works, and treated as trade secrets. At a financial services company, the trend analysis and prediction software is what makes the company different from all its competitors. The LOB application is the deal-breaker. If a Windows upgrade breaks a LOB application, it's game over. No upgrade. No company is going to lose a program that is critical to their business. And it happens that a lot of these LOB applications are 16-bit programs. Some are DOS. Some are 16-bit Windows programs written in some ancient version of Visual Basic. "Well, tell them to port the programs to Win32." Easier said than done.
Perhaps with a big enough carrot, these companies could be convinced to undertake the effort (and risk!) of porting (or in the case of lost source code and/or expertise, rewriting from scratch) their LOB applications. But it'll have to be a really big carrot. Real example: Just this past weekend I was visiting a friend who lived in a very nice, professionally-managed apartment complex. We had occasion to go to the office, and I caught a glimpse of their computer screen. The operating system was Windows XP. And the program they were running to do their apartment management? It was running in a DOS box. |
Comments (65)
Comments are closed. |
This is an overwhelming argument for why Windows needs to be able to support 16 bit legacy apps. Great explanation.
Could the 16 bit support be optional at some point, though? Either a separate Windows Component (like IIS or MSMQ), or as a separate edition of Windows (like Media Center or Data Center Editions)?
I know I’m going to look dumb for asking, but that’s never stopped me before. I realize componentizing legacy support (jusk run the Add / Remove Thunking Wizard…) is not at all trivial, but at some point we need to move forward, right?
And on another note – is SysWOW64 an awful name for the 64 bit Windows on Windows system, or is it just me? I realize Joe User shouldn’t have to dig through his system directories, but that name is just plain silly. "No, Mom, like sis… wow… 64… no, that’s wow… no, no, Mom, I’ll e-mail it to you."
Speaking of Win64, isn’t it delightfully head-explodey that %SystemRoot%SYSWOW64 is the home of OS 32-bit binaries and %SystemRoot%SYSTEM32 is the home of OS 64-bit binaries?
Backwards compatability sucks!
"delightfully head-explodey".
Wow. I like that phrase a lot.
I’m guessing you also spent too much time on "Lemmings" a few years back :)
In a similar line to Jon’s comment, could Microsoft not use their Virtual PC technology to internally sandbox Win16 applications (essentially shipping an earlier subsystem with future versions of Windows)?
Sure you can sandbox them, but then they wouldn’t interoperate with Win32 programs.
E.g., document type ".lwd" is associated with a 16-bit program called "Litware Deluxe" via DDE. You go to Explorer and double-click a .lwd file and… um… a new VM opens up and Windows 3.1 starts up inside the VM and then Litware Deluxe is started. And then Explorer says "Okay, let’s do some DDE" and tries to send a message to that copy of Litware Deluxe that’s running in the VM… How do you EnumWindows across VMs and make sure the window handles are unique?
If I remember correctly, x86-64 does not support 16-bit VMs under a 64-bit OS. Does Windows for x86-64 have an x86 emulator for running Win16 programs, or will this be added in a later version, or will customers have to choose between Win16 and Win64 programs?
I’ve yet to stay in a hotel where their reception doesn’t have some DOS application on their computer screens.
Reuben Harris: you forgot to mention the %SYSTEMROOT%SYSTEM folder for 16-bit stuff :) Nice confusing names for the folders.
Raymond, do you know if the reason for this foldername-mess is because of just stupid programs (hardcoded to system32 instead of using eg. SHGetFolderLocation with CSIDL_SYSTEM), or is it another reason?
I guess the SYSWOW64 folder really should be called SYSW32OW64, but that name is > 8 characters(seems like Windows prefers 8.3 paths for kernel-stuff etc… at least, I can’t see any such dll/exe in %SYSTEMROOT%). And since there isn’t any SYSW16OW64 there isn’t any need for the ’32’ part anyways :)
Ben: You have to choose between Win64 and Win16.
Andreas: Yup, the confusing naming is for compatibility. Lots of people hardcode "system32".
If an application at a company relies on Win16, why not sell them Windows 3.1?
If an application at a company relies on DOS, why not sell them DOS6?
Because they already paid for Win3.1 and DOS, and MS (like all software companies) can’t make money unless they ship new code. People aren’t going to pay for old code.
Because they also rely on other programs that don’t run on DOS or Windows 3.1 (e.g., they use Office XP for writing proposals). They need an OS that runs both Office XP *and* their LOB programs.
Manual trackback: http://mikedimmick.blogspot.com/2004_03_01_mikedimmick_archive.html#107817459629776377
Not that Microsofts’s SCM and defect tracking systems are 16-bit, right?
Right, I was using those as examples of LOB software, not as examples of 16-bit software.
****************************
Real example: Just this past weekend I was visiting a friend who lived in a very nice, professionally-managed apartment complex. We had occasion to go to the office, and I caught a glimpse of their computer screen. The operating system was Windows XP. And the program they were running to do their apartment management? It was running in a DOS box.
****************************
Real example of my own: my lawyer uses WinXP, but writes his documents using some ancient WordPerfect program through DOS. No mouse support, no WYSIWYG. But, damn, he can create a document very fast, knows all the keyboard commands, etc., etc.
I don’t quite understand; it’s (some of) the 32-bit apps that hardcode "system32", don’t they want the 32-bit binaries?
It turns out they usually don’t! A 32-bit program that builds the path "C:WindowsSystem32control.exe" probably wants the 64-bit control panel, for example.
But wait, how can they really be with us? Can people still buy computers with Win16 on them? I thought MS EOL’d Win3.x long ago? Win95/98 are having a hard enough time staying on MS’ support infrastructure and tools radar, I don’t see this argument about "us having to deal with win16". Unless a developer kept that dusty VC 1.5.1 CD that came with their visual studio 2.x, I don’t even see how somebody could still write something that would run on Win16.
This whole 16bit legacy thing seems to be more of an issue for MS’ operating systems _sales_ dept. more than technically related. Due to those LOB apps on critical paths and being entrenched, MS can’t make headway in getting them to buy new licenses.
Win32 came from Win16. That to me is the reason (and only reason) we still "deal" with it.
What about the ideas I mentioned with separating out 16 bit support, either as (1) a Windows Component or (2) a separate Windows Edition?
Both are likely expensive – (1) more upfront, and (2) from a support point of view. But it’s got to happen some time, right?
That means, that the next 5 Windows versions will support apps based on Win32 API and there is no need for learning .NET? :o)
Great explanation, but I’d be very interested to know how much of a performance boost I would get if my Windows 2000/XP was stripped of its 16 bit abilities
Andrew75: None. 16bit DOS/Win16 is implemented in a subsystem that only exists when you run 16bit applications. In fact, they’re implemented in 32bit code, designed to emulate the 16bit environment. Every version of NT has been 100% 32bit except for the small bit of compatibility code in those subsystems.
I assume it’s possible to ship the Win16 compatibility ("Windows on Win32") separately, for example like Windows Services for UNIX.
However _most_ people would have to (download?) and install it separately then. Lot’s of Win32 applications uses 16-bit installers for example…
Andrew75: You could try to remove the WOW by removing/changing values under this registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlWOW
The registry values under this key is described in KB102986 (see also KB105992). But, as Carmen already said, this will not affect the performance of your system.
In the example about a company running a line-of-business app without source code (so that they couldn’t port if they wanted to), I would consider that a *huge* risk for the company. In that situation — especially if the LOB app is critical — I would think they would be desperate to migrate to code they own and know just to manage the risk.
And yet I know it doesn’t work that way. Why?
Regarding the base note, I don’t code much 16-bit stuff (I was using 32-bit computers before Microsoft ever existed) but I do use a, um, bit of it. For example, Microsoft always warns how dangerous it is to use Regedit. Notice how much safer it is to edit an .ini file. I do use things like GetPrivateProfileInt and WritePrivateProfileString. Of course I abhor the inadequate error checking built-in to GetPrivateProfileInt, but it doesn’t seem to be a problem, because customers who edit their .ini files don’t seem to mind fixing their editing errors.
3/1/2004 1:35 PM Raymond Chen:
> A 32-bit program that builds the path
> "C:WindowsSystem32control.exe"
is enormously badly broken and shouldn’t be allowed to run.
Usually I avoid putting an OS on drive C because it would get smashed when I install badly broken applications or drivers in OSes on other partitions. It is safer to use ONLY other partitions for OSes.
But then there are these neat little recovery CDs from some vendors, when I buy a new machine and have to pay for yet another unwanted copy of an OS, and the vendor refuses to warranty their hardware unless I reinstall their recovery version on C. Fortunately they don’t seem to mind the repartitioning and the installation of OSes from MSDN etc. on partitions other than C. But then I don’t get to notice when a buggy application created C:Windows or C:Progra~1.
3/1/2004 2:46 PM russ:
> Unless a developer kept that dusty VC 1.5.1
> CD that came with their visual studio 2.x,
And with MSDN. (It used to be on the FrontPage CD but has moved to a more sensible place.) As mentioned, I don’t code much 16-bit stuff, but about 2 years ago I did for an embedded system. Of course Longhorn or XP weren’t an issue for that. (Yeah I know, XP could theoretically be an issue for an embedded system.)
The danger in editing the registry is not inherent in the structure of the registry. GetPrivateProfileXxx is extremely dangerous on Win9x where a lot of critical system configuration information is kept in INI files. Editing your system.ini file incorrectly can render your Win9x machine unbootable.
The danger is in what the database is used for, not in the technicals of how the database is represented.
What would be your alternative to building a path to (say) control.exe? Surely you don’t want to use SearchPath or you become subject to current directory security bugs!
"What would be your alternative to building a path to (say) control.exe?"
The only one I can think of is to remove the ability to reference your system32 directory through a path (such as c:winntsystem32), and instead only allow it to be accessed via a symbolic name (eg %SYSTEM32%).
Of course, the horse has bolted on that one, and you have to leave it accessable for backwards compatability reasons now!
"Surely you don’t want to use SearchPath or you become subject to current directory security bugs!"
Well, cmd.exe still executes whatever is in the current directory before searching the path. Yeah I know, backwards compatability. But surely security should come first.
Raymond, thanks for the feedback :)
I can see your point about using the VM technology in Virtual PC to handle the 16-bit compat, but what are your feelings on making the 16-bit compat layers optional components. Assuming they’ll need to be removed someday anyway, wouldn’t making them a component now save work down the road?
"What would be your alternative to building a path to (say) control.exe?"
Why that’s easy. Use shell automation to open a window on the path "::{21EC2020-3AEA-1069-A2DD-08002B30309D}".
;-)
> 3/1/2004 6:15 PM Raymond Chen
> The danger in editing the registry is not
> inherent in the structure of the registry.
That’s a little bit debatable. Whether it’s inherent in the Regedit command itself is also a little bit debatable, except for one famous exception. Nonetheless your employer always warns about its danger.
> GetPrivateProfileXxx is extremely dangerous
> on Win9x where a lot of critical system
> configuration information is kept in INI
> files.
Please enlighten me.
> Editing your system.ini file incorrectly can
> render your Win9x machine unbootable.
Yes, but GetPrivateProfileXxx is reading, and both GetPrivateProfileXxx and WritePrivateProfileXxx are writing to named .ini files. The purpose of private profiles was to avoid contaminating system.ini, right? They continue to be valuable in making it possible to avoid Regedit.
Even in Windows 1.0 there was a way to get the path to the system directory (GetSystemDirectory); just nobody used it. And given the state of technology back then, it wasn’t feasible to say "Sorry, but this directory you can’t access unless you go through me." Windows programs still used int 21h to talk directly to DOS.
And would that fly even today? Suppose there was a new rule: "Programs written in WinFX cannot access the system32 directory directly." Would you cry foul?
On the subject of system.ini and win16: Basically, system.ini was the win16 version of HKLMSystem. That’s where drivers came from. That’s where driver configuration settings came from. Mess with that file and you can render your system unbootable the same way that messing with HKLMSystem will do.
Whether the config info is in the registry or ini files – the point is, "Don’t change it unless you really know what you’re doing."
Imagine if somebody took away your current editor and gave you a new one with different keybindings. "But the new one is better.")
—
I still use Brief for OS/2 as my "IDE" of choice ;) You might as well break all the fingers on my hands if that ever stopped working….
As another example, the app I work on has some 16 bit components. Long ago, when OLE was the in thing, some small OLE apps were written for the application. The features in these apps have been replaced by code in the main 32 bit application but we still have to keep around these old applications to load old documents and so old documents draw in the same way. While it might be possible to write code to read in the data these old apps wrote out and replace the objects they created with 32 bit versions, it would be a lot of work for very little gain. Of course they might stop working on 64 bit Windows but hopefully by the time our users start using 64 bit systems, there won’t be many documents with the old objects any more.
I’m stricken by how much an overwhelming argument this article is for free software / open source.
How so? Why would a financial services company open-source their top-secret trend prediction software?
Raymond asked Why 16-bit DOS and Windows are still with us, and Mike answered. This is something I’ve thought about…
Mike: OS/2 app _have_ stopped working, as of Windows XP — os2ss and psxss have been removed.
The registry has a bad reputation in the OSS world, mainly due to Windows 9x’s relatively poor implementation, which didn’t offer much protection against hardware faults, system crashes and power loss. The registry could be saved back in an inconsistent state.
Windows NT’s implementation is journalled (separately from the file system; remember that NTFS only protects its own metadata, not your data, and that NT also has to work on FAT file systems), but is still susceptible to hardware faults. Some parts of the system configuration data are edited by the system as it boots up (particularly the write of Last Known Good and hardware detection) and this can, on rare occasions, cause an inconsistent registry to be written back to disk.
It’s easier to write the usual disclaimer in a KB article than to say that the _act_ of editing the registry isn’t liable to cause any harm on its own, but writing incorrect values or deleting keys that the system depends on can cause it never to boot again. This is like deleting or misconfiguring your /etc/inittab or /etc/rc.d on a UNIX system. Get it wrong and you’ll be booting from a recovery disk or reinstalling your system.
The registry also has the advantage of being _fast_. Try reading initialisation information from a text file quickly enough to generate a context menu on the fly – after all, that’s what Explorer does with the registry. The Send To menu is noticeably slower than the parent context menu – it reads the file system.
I don’t believe I’ve ever suffered from registry corruption in over ten years of using the registry, from Windows 3.1’s minor implementation for OLE right through to Windows XP. This could be because my hardware has been reliable.
The first edition of Windows 95 broke its own registry on an all too regular basis. Since then it’s been solid though. I agree the registry gets a bad reputation for reasons that aren’t grounded in fact.
It concerns me a lot more that the values in the registry aren’t always documented well than the implementation. I know regular users aren’t supposed to touch the registry directly, but there’s a ton of infomation scattered across various microsoft sites telling you how you can tweak such and such a value to achieve some effect. Surely this should all be documented in a central location.
Additionally, it would be nice if there were better tools for repairing your own registry if you do manage to break it. I think that’s part of where the complaints come from. It’s simple to fix a text config file on a UNIX system if you add a bad value – boot up from a CD and use any text editor. Unfortunately, Windows doesn’t come with anywhere near as nice a recovery environment. It would be wonderful if the next version of windows came with a bootable mini-install on CD, that at least let you run the basic programs one might want to use to recover a system (such as regedit!).
I’m not holding my breath. :)
Windows does come with a very nice recovery environment – the recovery console. Boot up the Windows XP CD and choose ‘R’ to start it… See the document at http://www.microsoft.com/windows2000/techinfo/administration/management/safemode.asp for more information about it.
But there is (at least) one utility which is missing there – the reg.exe utility which lets you edit the registry from the console. Why isn’t this utility supported? :)
One thing I’d like to see in the recovery console is a text editor. The ability to tweak my boot.ini (because SP3 ate my install) would be nice.
Cooney: yeah, that’s another useful thing they missed.
But.. there isn’t any decent console-based texteditor in Windows :( so I’d like to see it both in the RC and in normal use. Something like vi or similar… and please not edlin ;)
3/1/2004 10:08 PM Raymond Chen:
> On the subject of system.ini and win16:
> Basically, system.ini was the win16 version
> of HKLMSystem.
No kidding. That’s why I’ve said (twice) that I call functions of the sort GetPrivateProfileXxx not GetProfileXxx, and reminded you that GetPrivateProfileXxx uses a named .ini file. Perhaps I should further add that the named .ini file, in addition to not being system.ini, is not even in a system directory. (Though in cases where I let a caller specify a filename, it could potentially be named system.ini and/or be located in a system directory.)
GetProfileXxx reads from win.ini. To access system.ini you had to use GetPrivateProfileXxx and pass "system.ini".
Note also that you can’t store unicode data into INI files. (Well, you could convert it to binary, I guess, but that sort of ruins the readability.)
And of course if the INI file is recording per-user data, make sure to store it in the user profile and not in a shared location.
OK, whichever system file is accessed by GetProfileXxx, I DO NOT USE GetProfileXxx. And when I use GetPrivateProfileXxx, I SPECIFY A FILENAME which is a private file, not system.ini, not win.ini, not even in a system directory (except that if I am allowing a caller to specify a filename then they are allowed to name a dangerous one).
My .ini files do not record per-user data (unless the customer arranges their data that way). If I’m coding an application, the customer generally wants the administrator to set options once and have the application use them without interference from the operator, so I put the .ini file in the same directory as the .exe (unless otherwise asked). If I’m coding a DLL then the customer or the customer’s other contractor gets to decide where the .ini file goes. In both cases, customers have not wanted the administrator to use Regedit for it.
I suppose you could say that a separate program should be written to store options which an administrator selects for each program. Well, one way is for a separate program to be Notepad and then we have .ini files. One way is for a separate program to be Regedit and use the registry. One way is to write a separate administration program for each separate application, but that has not been proposed by anybody. Customers want to use Notepad and .ini files.
If you want to use INI files then more power to you. Just be aware of their limitations. (For example, they’re slower since the file is loaded and parsed each time you call GetPrivateProfileXxx, and you can’t store unicode data there, and binary data is pretty clumsy, and woe unto you if two threads try to write to the same INI file simultaneously.)
Yes the .ini file is loaded and parsed several times for each time the .exe file is loaded and executed. I infer that the registry might only be loaded once, but reading a 1KB file 10 times is faster than reading a 3MB file 1 time. 9 out of 10 times it’s probably still in the disk driver’s cache too.
Yes strings have to be stored in the code page used by the customer’s Windows product and administrator and operators.
Yes binary data is clumsy, no negative values, and (as already discussed) no error checking.
Of course if the administrator has two Notepad windows open at and tries to write the same .ini file from both of them at the same time then there might be corruption. Hmmm, I did say I use WritePrivateProfileString, so I really deserved your comment about two threads. Actually I only recall using it during debugging.
"Windows does come with a very nice recovery environment"
It comes with it, but it is in no waay, shape or form "very nice", especially when compared to the competition. Some Linux distros can boot into a full blown GUI with web browser, mail, etc all off a CD.
"so I put the .ini file in the same directory as the .exe (unless otherwise asked)"
And therefore your application can never run with normal user level privileges.
> Note also that you can’t store unicode data into INI files.
Actually, you can. Write a Unicode BOM (byte order mark) to the beginning of an .ini file, and voila – you have a Unicode .ini file.
I’ve never actually seen someone use that technique, but it does work…
True, you can do that, but nobody does as far as I know, and it requires you to use a unicode-enabled editor to edit your ini files.
3/3/2004 5:11 AM Frederik Slijkerman:
>> "so I put the .ini file in the same
>> directory as the .exe (unless otherwise
>> asked)"
>
> And therefore your application can never run
> with normal user level privileges.
But somehow it does. As already mentioned, when the customer wants to change the configuration, the administrator uses Notepad to edit the .ini file. When operators use the product, it seems to have no trouble reading the .ini file.
This is why we have the concept of "Sub Systems" on NT and later. We have POSIX and OS2 subsystems etc.
>And like Microsoft’s defect tracking system and >source control system, many of the LOB >applications at major corporations are not >commercial-available
Isn’t Microsoft on Perforce? That’s commercially available.
One more reason why WOW is still there is that some old folks like me love to write their stuff with languages that do not produce bloatware, and are incredibly comfortable to use – like GFA Basic, which was used to write the dashboard at http://esl.jrc.it/envind/dashbrds.htm
The wowexec also offers a somehow "protected" environment: its behaviour won’t change with the next Windows version.
By the way: is there an elegant way to get the original index of an item from a listbox with LBS_SORT style?
Commenting closes after two weeks.
http://weblogs.asp.net/oldnewthing/archive/2004/02/21/77681.aspx
PingBack from http://castalie.comoj.com/?p=248