| Date: | April 3, 2006 / year-entry #117 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060403-59/?p=31693 |
| Comments: | 64 |
| Summary: | Mistakes were made. Mistakes such as having Windows NT put Notepad in a different location from Windows 3.1. (Though I'm sure they had their reasons.) Mistakes such as having a TCS_VERTICAL when there is already a CCS_VERT style. Mistakes such as having listview state images be one-biased, whereas treeview state images are zero-biased. But what's done is... |
Mistakes were made. Mistakes such as having Windows NT put Notepad in a different location from Windows 3.1. (Though I'm sure they had their reasons.) Mistakes such as having a But what's done is done. The mistakes are out there. You can't go back and fix them—at least not until time travel has been perfected—or you'll break code that was relying on the mistakes. (And believe me, there's a lot of code that relies on mistakes.) You'll just have to do the best you can with the situation as it is. Often, when I discuss a compatibility problem, people will respond with "That's your own damn fault. If you had done XYZ, then you wouldn't have gotten into this mess." Maybe that's true, maybe it isn't, but that doesn't make any progress towards solving the problem and therefore isn't very constructive. I sure hope these people never become lifeguards. "Help me, I'm drowning!" "Are you wearing a life preserver?" "No." "Well, if you had worn a life preserver, then you wouldn't be drowning. It's your own damn fault." When faced with a problem, you first need to understand the problem, then you set about exploring solutions to the problem. Looking for someone to blame doesn't solve the problem. I'm not saying that one should never assign blame, just that doing so doesn't actually solve anybody's problem. (If you want to blame somebody, do it at the bug post-mortem. Then you can study the conditions that led to the mistake, assign blame, if you're looking for a scapegoat, and take steps to prevent a future mistake of the same sort from occurring. As a lifeguard, you first rescue the drowning person, and then you lecture them for not wearing a life preserver.) |
Comments (64)
Comments are closed. |
Even if you did have a time machine, you couldn’t change anything because you have to maintain compatibility with the timeline. Imagine it: you go back in time and have Windows NT put Notepad in the same location as Windows 3.1. The next thing you know, the colour red has gone and never even existed!
Ah – "bug post-mortem". "Blamestorming" (think brainstorming crossed with apportioning blame) is a much more appropriate term…
There is one problem with the lifeguard comparison, namely that the drowning fellow (who is Microsoft) is not a simple bypasser (byswimmer) but a professional swimmer or seaman :) Not wearing a life-belt (or similar) has to be considered a bad mistake from a pro, sorry.
Many of these mistakes are old ones, and it’s best to correct them the earliest possible, as the solutions can take ages to take effect, but they are at least some steps into the right direction. Better start them late then never, though.
A good example for this is the Windows dir structure (not just Notepad). Maybe Vista will fix it, but naming/placing mistakes are still common.
I wonder if MSFT has any official plans to properly obsolete APIs/other old stuffs in a way that it gets out of the way completely after a while.
Thanks for this post, it’s good to see someone cares.
vsz: So if a professional swimmer is drowning, a lifeguard shouldn’t try to save him?
"It’s best to correct them as early as possible."
Okay, go for it. Tell me how you would correct the "two copies of Notepad" mistake?
Microsoft plainly shouldn’t be bloating the OS trying to save every sloppy programmer from his own blunders. Windows by now probably contains more code for handling exceptional cases caused by bugs in 10,000 dead third-party programs than code for actually doing the work.
Instead of spending time fixing other people’s mistakes, communicate better to these people, at the very least in form of better API documentation.
How about a hardlink from one to the other, or both to a new location?
I would assume %WINDIR%Notepad.exe is the canonical way to call notepad, but I’m probably wrong. Publishing "best practices" might be a good idea; I would assume that they are up there.
"I wonder if MSFT has any official plans to properly obsolete APIs/other old stuffs in a way that it gets out of the way completely after a while."
I’ve been wondering this myself. Apple have a system in their headers where APIs can be marked as "deprecated", with the option to show a warning during a build whenever your code uses a deprecated API. These are still supported for now, but there’s a clear message that in N years they’re either going to go away or may suffer a large performance cost.
This does a reasonable job of migrating developers from older APIs to modern replacements (e.g., everyone is well aware that the equivalent to GDI is going away and all drawing should go through the equivalent to GDI+).
How far back you want to support code which will never be rebuilt is a different story, but this system means APIs go through 3 stages of being exported but deprecated (warnings when you build), being exported but not visible in the header (old apps will run, new code will need updating), to not being exported at all (old apps won’t run).
Does Microsoft have anything similar?
Except not every filesystem has hard links, and you certainly don’t want to have different sets of installed files for different filesystems.
"vsz: So if a professional swimmer is drowning, a lifeguard shouldn’t try to save him?"
I think the swimmer should look around, calm down, and he could save himself alone. But I agree that lifeguards should help, that’s their job after all. This comparison really can go far away from the original topic :)
Notepad. First off I’d try to make guesstimate of the size of the problem as of now. Maybe it’s not even a problem anymore. If it is, I’d make a note for developers (upcoming Vista release gives a very nice momentum for this) that 1) NOTEPAD.EXE won’t be available in two locations anymore 2) the placing/naming of the app is not guaranteed to stay the same in future OS versions 3) that the recommended action to launch a .txt file is this and that (let’s say "START <filename.txt>" equivalent).
To go a step further, Vista could let’s say introduce a System Applications folder somewhere (looks like this is mostly %SYSTEMROOT%system32 for NT class OSes), add an envvar (%WIN_SYSAPP%) and extend the API to retrieve this folder, and store all apps in that folder from this point on. In this case the name of the system applications (NOTEPAD.EXE) could be retained for better compatibility (which will still leave some potential problems for the future). This would also solve all those apps which want to launch CALC.EXE and whatever else system apps directly.
If FAT32 support could be dropped for system drives, it would make it possible to utilize hard-links to handle similar problems in the future (Like a name change for the NOTEPAD.EXE executable).
And when the lifeguard has two people drowning, whom should he rescue first? My guess is that he’ll probably go get the person that he hasn’t hauled out of the water six times today. Particularly if that other person is still not wearing a life preserver. And that lifeguard is gonna be pretty mad, even though he might hide it out of respect if the guy croaks.
Relying on the lifeguard constantly is no substitute for actually leaning to swim properly. But hey, if you must go into the water before you know how to swim (any time), and do so outside the boundaries (any place), with an anchor tied to your belt instead of a life preserver (any device), then I guess you gotta go!
vsz,
Do not ever become a lifeguard. If you do, let me know where so I will know to never swim there.
Maurits,
I have seen better comments from you in the past. Far better. Are you ok?
Everyone,
What we are seeing here is the old saying of "hind-sight is 20/20." Get over it. Linux and Mac do a great job of avoiding problems like what we are talking about here by DESTROYING YOUR APP and causing your company to go bankrupt when they rewrite their API’s. Despite how horrible some apps and hardware may be, despite whether or not the company that made that app is in business or not, MS does what it can to make certain that all this stuff runs.
No other company goes through so much trouble for its customers. There are two words for this: Customer Service.
This is why MS is number one and opensource/Apple isn’t.
James
Chris Moorehouse: Again, that’s bug prioritization, not bug fixing. Again, a valid step in the process, but not the step I’m interested in. I care about fixing bugs.
While playing the "blame game" may not actually solve the specific problem at hand, it can still be useful as part of the problem solving process:
1) there may be several (less than ideal) solutions to the problem; figuring out how you got to where you’re at may help determine which solution to use. Part of this quest for "why?" almost inevitably includes determining where the mistakes where made.
2) Learn from mistakes of the past; part of that is realizing that a mistake was made in the first place.
Isn’t that "one-based" and "zero-based" instead of "one-biased" and "zero-biased"?
At least according to all my programming books…
I wonder when MS will (to continue the lifeguard analogy) require everyone to wear life preservers instead of randomly saving people who jump in after not regarding instructions.
Lifeguards are nice and necessary and all that, but they’re entirely a reactive solution to a problem – and that’s something that MS has been doing for a while.
Maurits, why?
Notepad is a 70K file. What do you actually achieve by moving it, other than some nominal sense of purity?
that their API is far older, tested, and cast in stone (POSIX)
Don’t forget, Microsoft did everything from scratch, over a period of many years, and so it’s entirely possible that they made a few mistakes along the way.
The other problem is that there’s half a dozen different flavors of Windows out there with various abilities (such as having hardlinks or not in its filesystem) whereas there’s only one thread of Linux and now one thread of OS X, plus the large market share of all the copies of Win95, etc that will always be out there.
The other part is that not enough folks can get copies of new versions of Windows far enough in advance to test on. So that if (for example) MSFT said in Vista 2.0 "Notepad will be in Program Files" nobody would find out about it until it was nearly released, which is far too late. They could SAY it, in prerelease docs or whatever, all they wanted but until people’s code actually breaks, they don’t fix it, so that wouldn’t work either.
This is where the benefits of open source "release early, release often" shows up. Things mostly get corrected early before they’re big cast-in-stone problems.
I’ve sat and thought about these problems and there’s not really anything you can do, IF you want to maintain compatibility. MSFT would have to do something like Apple going to OS X, where they have a mostly clean sheet of paper to do things right.
I think some people may be overlooking the fact that one of the goals of all the backwards-compatibility work is to keep existing applications working. It’s not just to keep lazy 3rd party application developers from fixing a couple of mistakes they made in the past. Sometimes those developers aren’t around any more, but the app has to keep working. Many companies have Windows-based applications that they bought a long time ago and that still work, and that are needed to run their business. You can’t tell them "tough luck that your app is broken, just fix the source code and recompile it". Their response would be "I can’t recompile it, because some consultant created it 10 years ago and then disappeared". Companies in that situation would conclude that the next version of Windows is not going to work for them, and stick with their current version. They would not care much that the new Windows is much more "elegant" and "pure". They just want their apps to work.
er, Mike’s "write" link should be here:
http://blogs.msdn.com/oldnewthing/archive/2006/03/28/563008.aspx#563448
"You can’t go back and fix them—at least not until time travel has been perfected—or you’ll break code that was relying on the mistakes."
Only if you can’t have version1 and version2 installed side-by-side. If you create a listbox2 that can be used by new apps with a corrected API, but keep listbox1 for old apps to use, you ought to be able to fix old problems without breaking old apps.
If you wait enough time before releasing listbox2 (say at least 5 years after listbox1) then you should be able to shake enough bugs out to not need a listbox3.
(OK, this probably doesn’t help with the notepad thing)
I have just the solution for you, mikeb:
1) Download alias.bat from here:
http://channel9.msdn.com/ShowPost.aspx?PostID=51329
2) install it
3) Type "alias wordpad write"
Then you can type "wordpad" from the command line and it will call write… which will, in turn, call WordPad…
On the duplicate Notepad issue:
Invent symbolic links. Oh wait, someone already has.
GRRR ARGH
"everyone is well aware that the equivalent to GDI is going away and all drawing should go through the equivalent to GDI+"
Nope, it seems GDI+ is the one going away.
GDI+ is much slower, and support for complex scripts is worse than the one in GDI. This is a reason why .NET 2 switched from GDI+ to GDI
See: http://msdn.microsoft.com/msdnmag/issues/06/03/TextRendering/default.aspx
The problem here is the weird way which MS separates "OS" from "applications".
Under Linux this is not a problem because there is no default editor.
There’s no guarantee any editor is installed by default, and depending on which of the various distributions or gui options you install (and in what location in the filesystem they install at) it makes no sense to hard-code a location in.
So on Linux it’s actually easiest to use the built-in mechanism for properly determining which editor to use.
Wheras on Windows, I’d estimate at least 95% of people use the default, normal install of Windows. The "OS" contains various utilities, and since there is no competition at the OS levle overall (Microsoft controls everything) people get lazy and rely on that fact. Good for MS’s bottom line, but bad whenever they want to change things.
MS has painted themselves into a corner, there’s really no good solution to this problem at all. It’s just one of the hazards of running a closed-source platform where the majority of the software is also closed-source.
Vista DOES require NTFS for the system partition. So the symbolic link solution can be used.
"I was responding to Raymond’s question: ‘Okay, go for it. Tell me how you would correct the "two copies of Notepad" mistake?’"
Ok, well since you put your solution out there, I’m assuming it’s open for evaluation. If we had to vote, I’d call Microsoft’s solution better.
Your solution had 5 steps with a lot of hidden costs (updating documentation, planning for removing the shims, perhaps providing a contingency plan for the case where a billion-dollar customer says their critical app is broken, 2 test phases–one once the shims are in place and then 1 when not). The advantage is that you save 68KB – 2*shim_size (rounding up to the nearest block size), and you get a sense of personal satisfaction that you’ve put the application where the other applications go.
The current solution has a one-time cost of 68 KB (and a single test phase I suppose) as far as I can tell.
I also think that "special" folders should have a random string tacked on to their names at Windows install time:
"C:Windows-1i5PBWJF"
"C:Program Files-1i5PBWJF"
"C:Users-1i5PBWJF"
etc.
That would put a quick stop to hardcoded paths. It would make dual-booting a lot simpler too.
Those same people are equating Microsoft to a Darwin Award winner.
OK, Raymond, where does the compatibility subsystem fit into this. Obviously, it would be overkill in "fixing" the two notepad situation, but certainly it could help in the one-based listview. Or is the compatibility subsystem only to be used as a reactive measure instead of a proactive one?
"Linux and Mac do a great job of avoiding problems like what we are talking about here by DESTROYING YOUR APP and causing your company to go bankrupt when they rewrite their API’s."
Not exactly. However, both Linux and Mac systems do have a higher tendency to remove APIs even if it means apps will stop working. The important thing to remember is that just because a new version of Linux or Mac OS X comes out doesn’t mean you should upgrade all your systems.
Part of evaluating new software in a business always has to be testing whether or not it breaks vital applications. This is true whether it’s upgrading to a whole new version of software or merely applying a security patch. One needs to look no further than the WMF exploit, which is actually used as a legitimate feature by variuos programs, to recognize that at some point companies have to decide whether to upgrade their system and live without a vital app, possibly killing the company, or maintaining older, independent software systems in a secure environment (ie, non-networked). The fact is, companies are probably the last group that wants compatibility hacks. Compatibility hacks means more code that could go wrong and when it comes to maintain features that could be exploited, leaves open a large area of human engineering (look no further than activex and outlook express). Beyond that, compatibility hacks almost never mean faster code (sheer size means cache misses are likely to increase), and that’s obviously further a big negative to a company where time is money and faster systems to compensate mean more money.
Having said all that, this isn’t to say Linux or Mac OS X are some sort of perfect systems. But they recognize that it’s better some times to simply throw away bad design, even if it means having to adjust to new apps or maintain separately older ones. To argue that concern for business is truly the driving force of these hacks seems ludicrous. To argue it’s more a driving force for pushing businesses to upgrade so Microsoft doesn’t have to keep applying security patches to separate forks or to prevent infuriate businesses by requiring them to de-network their non-vitality networked systems seems more probable.
Of course, none of this is speaking about non-companies. When it comes to the desktop, compatibility hacks are probably vital. It’s more important to keep apps running and add new features than it is to maximize security or performance. Of course, when incredibly bad design is involved, it’s sometimes necessary to completely disregard app compatibility. Thankfully that’s occurred very rarely for desktop users. But so long as most apps are not fixable by anyone but the original author, there will always be the looming threat. The closest thing I’ve seen so far is various attempts to firewall off dangerous things and try to give the user control over things that might go boom (ActiveX, for example). Without being cynical about using it as a basis to blame the user, I’d say it’s the best possible compromise to maintaing everything the user wants without entirely pissing them off.
I’m not sure how Apple handles it, except through some elitism and some good virtualization software of their own.
So what Raymond is suggesting here is for the public to first fix all of the problems in the APIs and then lecture MS about proper software design decisions?
I fail to see how that makes any sense.
"I fail to see how that makes any sense."
You are correct. Your interpretation of what he’s saying indeed does not make sense.
Maybe it’s just me, but given all the effort that Microsoft has put into fighting the Samba project, I’m quite amused that anyone working for Microsoft feels entitled to whine and bitch that "the community" isn’t feeling suitably generous and charitable.
Somebody at Microsoft bet that they could kill Samba. They failed, and now they’re being introduced to that amazing thing known as "consequences". Yeah, there’s not much they can do that won’t cause poor publicity in one way or another. So? When did that become my problem?
Besides, we’re not life guards refusing to save a drowing man. We’re passers-by making cracks about life jackets while waiting for the guy in the water to realise that it’s only 2ft deep and he’ll be able to stand up as soon as he stops trying to hold another guy down.
/me checks mirror, takes temperature… hmm, I seem to be OK. :)
I’m not implying that the "two notepads" problem *needs* to be fixed. I’m just saying that there *is* a way to fix it.
The method I propose is very similar to the Write => Wordpad migration Mike describes here:
http://blogs.msdn.com/oldnewthing/archive/2006/03/28/563008.aspx#563212
Note that %SYSTEMROOT%system32write.exe is currently a shim for:
C:Program FilesWindows NTAccessorieswordpad.exe
(Check the icons and the file sizes)
The sunset date could be pushed arbitrarily far into the future, in principle.
Mihai, he meant OSX’s versions of those; of course GDI will never go away, at least until Windows 2025 or so. :p
Windows already uses a lot of side-by-side DLLs, see all the vbrun*, msvcrt*, mfc*, etc, and of course the actual SxS copies of differing major versions. For fixing minor problems, I’d just use SxS to publish a new version of the dll, which the system ensures is only used if the manifest matches (so it has to be compiled against it), but how to ensure that developers know about the change so they don’t go blindly recompiling what might now be buggy software?
i see hundreds of small utilities .exe files around in windowssystem32 folder.
i wonder, why don’t just invent a new type of .EXE, you may call it .EXE2 or .FXE (ABCDE "F") that could house several .exe files.
so, you could put eg.
calc.exe
notepad.exe
…
into one sytem_utils.fxe and they should still could be accessed naturally. (like from START->RUN, typing notepad would still lauch notepad)
ping.exe
tracert.exe
route.exe
system_network.fxe to store network utilities.
so. wat the benefits,
1. more manageable. (10 peoples are more manageable than 100 peoples). so as files.
2. save a little bit hard disk space. (i know 10GB is cheap nowadays, but.. wasting is always no good)
3. easier version management since stuffs are grouped into their own category
4. the best thing is, application developer eg microsoft could make something like program_office.fxe that contained all word.excel, pp, access and so on. or program_adobe.fxe would have photoshop, … and so on.
so when somebody double click eg. program_office.fxe, a dialog box would box up and user could select wat application they want to launch. and if let say they want to start word directly, short-cut to application would be like, "c:program_office.fxe msword" so MS word would start
if somebody take a closer look on c:windows or else where… files are here and there, lots of the dll files are ungroup, they just sit there in system32, wonder how many times they are used monthly.
just imho.
> "Help me, I’m drowning!"
> "Are you wearing a life preserver?"
> "No."
> "Well, if you had worn a life preserver, …
Well, The Old New Thing the part of the world I’m living there is an very old saing
Uppuja päästmine on uppuja enda asi!
Which translates to something like …
If you drown, you must save your self!
I know its rude, but often true.
I’d fix the notepad.exe problem like this.
1. Throw away current notepad.exe. It was way cool 15 years ago, but it’s been a walking corpse for a long time.
2. Buy one of the very nice lightweight notepad replacements available from one very happy and [now] rich developer (heck, I’ll write you a better one, my rates are reasonable, especially given the US-AUD exchange rate :).
3. (bug-fix, test cycle, still cheaper this way)
4. Installs into /program files/JotPad (whatever).
5. Install 2 notepad.exen into current locations (shims with smarts to read some configuration setting to determine the System Text editor which defaults to JotPad).
[There is a separate, and no-doubt passionate debate over what features are required in an enhanced notepad. Let’s save that for another day folks, it’s even less relevant than my ‘solution’ :]
Now this is a very concrete answer to a single example of a generic issue. To me it seems a no-brainer for MS to have as much backward compatibility as possible. You can wax lyrical about virtuous customer support or lose sleep over blemished sourcecode, but ultimately the real reason is to keep selling Windows.
How many gazillions of Windows users are out there? How many of you have relatives still running 95 or 98? The next time they upgrade it’ll probably be when you replace your current PC and give them your piece of rubbish. They’ll want GardenPlanner or FamilyTree or KnittingPatterns or RayGunz to keep running.
They wouldn’t give a flying frisbee that the operating system has some thingies that start at 0 and some thingies that start at 1. They just want to use their software, not be forced to admire the side-effect of some wanker’s masterpiece of abstract technical purity.
Sash said: "So what Raymond is suggesting here is for the public to first fix all of the problems in the APIs and then lecture MS about proper software design decisions?"
It’s impossible to create a system of the complexity of notepad without any bugs (I think they’re all fixed now, though), how do you propose to do it with something like an operating system?
"proper" design decision? What’s a "proper" design decision?
Bah!
Mistakes get made. Children cry about them, adults got on with it.
s/adults got/adults get/
Apple stopped supporting Apple ][ binaries when they introduced the Mac. Microsoft still run DOS binaries in Windows XP. This is a large part of the reason why Microsoft is the dominant vendor.
I heard a rumor that 64-bit Windows XP will not support DOS binaries. Has Microsoft given up backwards compatibility?
If we’re at it, MS did a great job maintaining DOS compatibility in NT via the NTVDM. It has it’s quirks, but the concept is nice and clean.
AFAIK they had to drop NTVDM (and Win16) support in x64 due to CPU mode limitations.
mikeb> "So now when I’m writing a new application I have to understand why there’s 2 listbox APIs and know why I want to use one over the other."
That’s what documentation is for. Yes, end-users shouldn’t need to read documentation for every little thing they do, but if you’re a developer selecting between listbox1 and listbox2, reading the documentation would probably be a good idea.
If the documentation for each class included one page that detailed all the API changes between them linked from the top level, something like:
Listbox2:
methods
properties
events
changes from listbox1
Then there wouldn’t be much of an excuse for missing it.
"And the difference is just that they start counting at 0 or 1?"
Like I said, wait a few years between versions. Get all the bugs out at once.
"Yikes – I’d rather keep with the current bit of mess than add another level of mysteriously different (but mostly similar) APIs."
Yeah, ‘cos developers get really confused between different versions of APIs, like the half-dozen variants of DirectX.
Oh – no they don’t. Because they can continue using the old stuff if they’re comfortable with it as it will be kept around.
Hi Raymond,
Why not release the checked builds of windows totally free for download, rather than only to MSDN subscribers… not only that, but in the checked build, remove all the backwards compatibility stuff like duplicate notepads and shell folder registry keys and even shims for deprecated programs like write and whatnot. The point is, make it free to download, so any developer can boot into it and see if their code runs.
While this solution won’t help fix apps that are no longer maintained, it may force current developers to use best practices, so that eventually some backwards compat can be dropped after a period of time, and it may minimize the number of new compatibility shims that need to be added to work around buggy apps. And since its a checked build, it wont be useful to anyone other than developers looking for issues as it will probably be too slow and assert too often for normal use.
Two notepads, I seem to recall that the original (Win3.1 ish) notepad.exe could only support up to 32k in size while the NT notepad could support larger documents. People would copy the old notepad into the windows directory. If the supporting > 32k version was there then it would be munched by it’s crippled little brother. Makes a certain amount of sense.
I appreciate all the work that Microsoft put into their products to make them backwards compatible in the face of all the things that misinformed developers do.
The purist in me hates it, but the realist says that it needs to be done in order to not affect the bottom line – ship more units, make more money.
Commercial Unix has similar commitments to not breaking things when you upgrade, primarily due to the lower-level nature of the API and their stability.
However once you start wandering into the GUI layer all bets are off (gtk1 vs. gtk2 vs. qt2 vs. qt3). The only way to ‘ensure’ stability at that level was to use static linking, but that makes things worse for everyone.
Comments on a couple of comments
[Quote]
The best way forward (IMHO) is DotNET, MS should say to developers: DotNET is the way to go, starting today al new apps should be written as .NET managed code, win32 support will be in Windows for another 5-10 years, after that only .NET apps will run.
[End Quote]
Remember back when .net came out and some people ported Quake II? Managed code ran at something like 85% the speed of compiled code. It ran at ~ 70% of shipped code, which included some assembly. For people who really need performance, .net’s still not an option. (SQL servers are also a bad fit. Notice that SQL Server 2005 hosts .net, and not the other way around.)
[Quote]
Apple stopped supporting Apple ][ binaries when they introduced the Mac. Microsoft still run DOS binaries in Windows XP.
[End Quote]
1) The hardware difference between an Apple ][ and any Mac was a lot different than current PCs and the original IBM PC.
2) Apple continues to sell and support the Apple ][ series for several years after the Mac was introduced. They added the (32 bit)][ GS to the line and an Apple ][ card for Macs.
Aaargh! — That sounds like a great idea, but *only if* .net would let you do everything that Win32 lets you do.
(Maybe .net 2.0 is better about this, but 1.1 doesn’t support serial ports, or direct printing using a custom printer control language (useful for barcode printers, which have a text-only PCL, and which there’s no good way to control via GDI), or directly talking to USB HID devices like barcode scanners, or GetGuiResources, or named pipes, or FormatMessage, or access to SSPI, or the IP Helper stuff, or a bunch of other things. To do any of this, you need P/Invoke and the Win32 API. Of course, even if the framework could do all of this, so that P/Invoke’ing the Win32 API wasn’t required, P/Invoke itself would still be needed, because there are other APIs that need to be used from .net: WinPcap is one. But it would remove the requirement for the Win32 API.)
Do developers actually learn from past mistakes? Not nearly enough people do.
Some of today’s software installers still try to overwrite system files with older ones.
Some production drivers still crash, even though running Driver Verifier would have easily caught the error.
Buffer overflows in privlidged code are still common – 16 years after the first public demonstration.
When I report software bugs, more often than not I get a canned response: "turn off virus scanner", "run as Admin", etc. instead of a thoughtful analysis. I don’t use those companies’ products anymore, but they’re still in business selling buggy software – that Windows has to be compatible with.
And by the way, there are some Windows driver problems that have been reported to Microsoft by at least two large hardware manufactures. These are not obscure problems – some consumer sites have written "use WinXP SP1 drivers" to work around the problem. MS’ response has been "show us the business case" before fixing the problem.
Um, you need justification to fix a problem reported by vendors and consumers alike? (This blog isn’t the place to share details… Raymond?)
Now do you see why we are so fustrated?
Now that Virtual Server 2005 is free – or so says an article I read yesterday – then it would be possible to run any ol’ app, eg, as 16-bit DOS, in a Win95 guest OS on 64-bit Vista, right?
That’s true backwards compatibility. And keep Vista clean.
DriverDude: I already discussed with a virtual machine doesn’t help. http://blogs.msdn.com/oldnewthing/archive/2005/10/05/477317.aspx
Not exactly related to this thread, but seems that now you Raymond will be dealing with fixing compatibility issues in Mac :)
http://www.dealcatcher.com/forums/m_402248/tm.htm
"1. Boot into Mac OS X – this wakes up the iSight USB camera
2. Reboot into Windows without turning off the Mac (turning it off/back on apparently disables the iSight in Windows, and it won’t wake back up unitl you go into OS X)
3. Control Panel > Scanners and Camers > USB Video
4. If you haven’t BSOD’d yet, click whatever option you see
5. Enjoy your BSOD."
I like dhiren’s idea. After all, checked builds should run a bit faster without all the compatibility shims to slow them down. I only wish I’d thought of it first.
Vestigial organs.
Hmm, there seems to be