Fragmentation in the Windows World
Greyfox writes "While various members of the Industry press have been raising the spectre of potential Linux fragmentation, we've been seeing some very real fragmentation in the Windows world. This story details the fact that there are now 7 different versions of the Windows 98 second edition and they're not all the same product! Add that to the assorted versions of Wince, NT (3.whatever to 5.0 betas) 95, and the die-hard 3.1 users who are STILL out there and you have a real mess on your hands. And programs for most of these versions of Windows are much less portable at the source code level than UNIX programs are. I've got a fair shot at taking any given UNIX program (Say, Gnome) from Linux to HP/UX to SCO or Solaris and having it work without any (or any major) changes to the source code. Most of the time you'll have to write your windows code from scratch. "
You don't even have to recompile. 16-bit code runs fine under win95, win98, and winNT. I've been running several 16-bit apps on my win95 (now win98) setup, and they run fine. In System Monitor it shows them as taking all the free CPU cycles due to some multitasking difficulties, but it doesn't slow the system down - the 16-bit programs just get allocated all the spare cycles.
Most code would benefit from a recompile and some minor changes, but it's not necessary.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I was under the impression that a.out binaries no longer ran under (most) default Linux distribution installs.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Yeah, but how easy is it to port an application that uses all of the 2.2.x features back to Linux 0.0.99? I don't think that is "just" a recompile either.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Linux has the same problem. Try running your q3test binaries on LinuxPPC.
This means that there are many different versions of Linux in your view. Not to mention how many hundreds of OS/processor combinations of UNIXes there are...makes Windows look positively unified.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I agree that this is being exaggerated. While there are some minor compatibility problems, they are just that - minor. I run several 16-bit programs written for win3.x under my win98 system, and they run fine.
Compare that to Linux binary compatibility. Just look at the mozilla binaries directory. Just for the x86, there's separate binaries for glibc and libc5 and libc4 systems. Plus there's the fact that none of those will run on old a.out systems.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
M$ is tearing their ass up to maintain backward compatibility, and that's one of the reasons they aren't getting on. And as of the different Win98
versions, what do you have to recode to get it from one to the other? The changes are cosmetic, because having no source code every little freaking change on source level needs a completely different version.
First ?
--
"The use of COBOL cripples the mind.
Its teaching, therefore, should be
The fact that Wince, Win98, and WinNT all have entirely different source code and are administered differently is IMHO a big liability.
If I outgrow my Linux box I can upgrade to a big SGI (or Sun or IBM) Unix box and it still works more-or-less the same way. Sure the GUI admin tools look different, but their not so radically different that I can't adapt in a day or two.
On the other hand, if my company wants to change all it's Win98 desktops for WinNT, I have to learn a different operating system entirely. Unlike Unix, the similarities are cosmetic and the differences are fundamental.
Changing technologies like this is a big deal for companies that have large existing staff that either need to be replaced (in a very competitive market) or retrained.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
Among the two major product lines, consumer Windows (95/98/98SE) and small business Windows (NT3.51, NT4, NT2000), there are lots of differences and incompatibilities; even major chunks of the APIs are different. Then, there is CE, which is really just a completely different operating system.
With all that complexity, Microsoft's operating systems still don't scale over a large range of hardware: all you get is systems that run from hefty PDA to small server. Linux spans that range with just a single OS and API. UNIX/POSIX systems more generally run from on anything from small, embedded, real-time system to the largest scientific supercomputers, parallel machines, and mainframes.
Compared to UNIX/POSIX, I find that both the interoperability and the scalability of Windows platforms are disappointing.
That's not really a significant problem. What's more of a problem is that Win32 programming requires a number of subtle changes to the C compiler to really do right -- i.e. Windows code in general is not pure ANSI C. "Strict" type checking comes to mind, although it's not the best example.
Now, in practice it's not that big a problem for most people (the differences are not normally a compatibility issue), but it has been a serious headache for the folks working on winelib with ANSI compilers that don't like the Microsoft-isms.
---
DNA just wants to be free...
Backwards compatibility isn't the same as lack of fragmentation.
Major chunks of the APIs are different or missing between the different Windows versions (even leaving CE out of the equation). What is shared is often incompatible in subtle or not so subtle ways. And a lot of the backwards compatibility is only a short-term workaround and impractical (do you really think you can use an 8.3 version of Word on NT for long before it becomes a logistical nightmare?).
Similarly, in theory, you can keep your old source code and still compile it. But in a commercial development environment, that's not really an option. When Microsoft comes out with MFC, ATL, or a new database access library, you have to use the new stuff to be able to take advantage of the new features and remain competitive, and that often requires a fundamental rewrite of your application.
Which matters to you more as a developer and user depends. But I think it is accurate to say that the Windows platform is quite fragmented, even though it may offer a lot of backwards compatibility.
I wrote a large VB application in VB 3.0. A consultant hired by our company said that the Access database in VB 4 worked better and had some whizzo new features, so we decided to upgrade.
The experience was vile. All our old VBX controls were replaced by OCXs. In the case of one of the controls we used (Truegrid, if anyone cares), the entire interface was rewritten. As a result, every form I had using a grid had to be rewritten. In addition, the database interface had some bizarre bugs that required major changes in the tools I used to generate SQL queries.
Suffice it to say that the whole thing was a hideous mess. My best advice after going through that is to stick to whatever version of Visual Basic you first started using. Do not upgrade under any circumstances.
D
----
So what happens when you compile a multithreaded application on a kernel-0.99-libc4-System, sucker?
You install the pthreads library first?
First off, the way he counts seven versions of Windows 98 is dishonest, since it counts the same thing bought in a store and downloaded electronically as two separate versions. Yeah, right. By my count it's more like four of five, which is still a really stupid way to release software, so it would have been better to report the sad truth honestly instead of trying to inflate the numbers.
Others have addressed the way that many Windows applications port more easily between 95/98/NT[1] than UNIX applications port between e.g. Linux/AIX/HPUX. Heck, thanks to glibc-maintainer incompetence, even portability between Linux distros is often questionable. What I'd like to point out is the issue of driver portability. Windows 98 adopted the "Windows Driver Model" which is a minor variation on the model NT had used all along. While this doesn't necessarily mean that the same driver binary will work with both, the changes required are trivial. Compare this to the situation in UNIX-land. Driver models are drastically different between UNIX versions, even between those that supposedly use standards such as DDI/DKI or DLPI. Occasionally a driver can be ported with little change, but more often 30-50% of the driver code has to be different for each platform. The saddest part is that there have been efforts to agree on a common UNIX driver model, but people right here always shout them down as a way to make it easier for vendors to ship closed binaries. *sigh* You want openness, you take fragmentation with it as a necessary consequence, and I wish everyone who tries to have their cake and eat it too (in this or other contexts) would just choke to death.
[1] As an owner of and programmer for a CE device, I think it's fair to say that CE isn't truly part of the "Windows family". Yes, it has the same GUI, mostly, but the internals are totally different.
Slashdot - News for Herds. Stuff that Splatters.
it handles a hell of a lot more that linux does.
But what Linux handles, it handles well. That in spite of the driver writer generally having NO documentation, NO vendor assistance (occasionally outright vendor hostility), and charging nothing for it. MS handles a lot of hardware because the hardware vendors wrote the drivers.
On the other hand, when's the last time you booted NT on your Indy or SparcServer?
Well, sorta. My VB 3 real world program was painfully slow. Then we got a Pentium/75 and it became reasonably fast. Then we upgraded to VB 4 and it was slow again.
Now that we have 400mhz machines running it, it's fast again. But of course we haven't upgraded to VB 6. My recommendation is that we don't.
D
----
Probably as many as there are Windows patches. The difference is, most of the Windows patches are MS internal. Most of the Linux patches are also Linux internal, it's just that with open source, internal only means freely available.
My experience was a little different. I installed a new disk drive in my system, making the new one the primary IDE master (I do SCSI at work, don't want it at home) with the old one as primary slave. I could still boot Windows 95 - yes, 95, not 98 - via LILO off the old drive and it would figure out what happened and be happy. When I tried to boot Linux off the old partition it wasn't happy because what used to be /dev/hda was now /dev/hdb etc. So I restored the old hardware config, booted Linux, fixed up LILO and /etc/fstab and so on and so forth, and rebooted. Still doesn't work. Maybe there's some step I forgot, but if anyone here says it's my own fault for not remembering to change /etc/shove_this or whatever then I don't ever want to hear a comment from the same person sneering about config.sys and win.ini and "that just works on Linux" because there's just as much nobody-could-have-known crap on Linux as on Windows. I've been working on UNIX kernels longer than Messrs. Torvalds and Cox, and it's entirely reasonable to say that the OS should be able to figure out something as simple as this and deal with it instead of crashing. Remeber, even lowly Win95 managed it, and Linux fell over itself.
Slashdot - News for Herds. Stuff that Splatters.
Sorry, but this is bullshit. You cannot compile win16 code with any compiler made after 1995. The API for say, reading from a serial port, changed between 3.0,3.1, then 95. And indeed, there are changes to serial port handling with 98, and NT, and Win2k, and none of these changes match up. This is just an example. You cannot even get documentation on win16 anymore, let alone write code for it. And just in case you didn't know, a 'recompile' does not convert your 16-bit code to 32-bit code. Sorry if I now think you have never written a line of code in your life. Also, which VERSION of win32 are you porting to? There are features in Win32s (the 32 bit addon for windows 3.1) that never made it into 95, and definately vice-versa. There are features in win16 that have no win32 alternative, such as the fine-grained functions to shut down windows. And there are versions of windows being released RIGHT NOW (WinCE, and soon NT Embedded) that have next to no support for the win32 API. I spent a week evaluating what would be neccessary for a CE port of our code, and my advice to my employer was to just encourage people to buy laptops- passing on the cost of the MONTHS of work needed for the port would quickly outway the slightly cheaper price of the CE machines. Let alone that there are close to a hundred different versions of CE. For instance Dreamcast CE, which does not even contain Windows GDI.
It's also pretty funny for Office 2000. I work in a computer store, and when someone walks in asking for the price of the product, it's hell.. Also, I'm in Montreal, so there are french and english versions:
:)
:)
- Standart
- Professionnal
- Premium
- Developpers
+ Now, double that for the academic versions.
+ Also add 4 more for the upgrade versions. (but you can't upgrade an academic version).
* 2 because there are french translations of all the products, they are all in the same box as most linux apps do.
= Total: 24 different boxes of Ms Office 2000.
But wait! You can also buy all the products individually (frontpage, word, excel, whatever..)
Imagine how fun it is, and how clients are usually pissed when they need to buy these products.
Now that's what I call Marketting:
This forces most stores to buy a big load of Ms Products, since to get a better "cost" price they have to buy alot. But they also have to buy all the different versions. Therefore, they have to store these boxes somewhere, and that's why in all stores you see a wall full of boxes, since it's either they have alot of this crap, or they won't have any.
Therefore, stores are forced to make free publicity for Microsoft products and they make it sound very important because they have a big pile of boxes. But they don't have a choice but to have a big pile of boxes since there are so many different products to display!
(that was hard to explain, don't be too supprised if I typed it all wrong
What the hell is this? quite frankly, windows is almost perfectly compatible. I realize that UNIX code is not going to port with out much trouble, but portability between Windows programs is at the *binary* level. You might have some trouble running newer win 95/NT code on windows 3.1, but try running the latest version of Mozilla on XENIX or whatever. (there's also the Direct X issue, witch has effected me personally... rrr)
there are some issues relating to driver incompatibility between NT and 9x, but other then that, all win32 platforms are compatible. Apps don't need recompiling. NT and 9x can run win3.1 code, and 9x can run DOS code. (NT can run some DOS, but not all. I think)
I realize that a UNIX program is not going to compile out of the box, (although NT is postix compliant, I'm not sure if its a very good implementation or not though) But neither will Mac or BeOS program. what does that have to do with anything?
I've seen this type of anti-MS FUD before, in a document stating that win64 OS's wouldn't support win32 properly. This was because the original version of win NT didn't support win16 very well (NT 3.5 has an emulation layer, or something). It was blatantly false, however, considering that windows NT currently supports 16 bit code, and 9x is half built of it (not that that's a good thing....)
Please realize that when you are dishonest, it calls into question everything you say. I for one never believed anything Apple said in there information, because some of the things they said weren't true at all (or no longer true). If you don't want to alienate potential linux users, you must not tell them things that they know aren't true. If you don't use windows, or have any experience with it, don't say things about it (the same is true for win* crashing all the time. It's not 100%, but it's not 0% ether)
Disclaimer: I use win98, I hate NT, I think linux is cool, and plan to install it, and I dislike Microsoft.
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
ReadThe ReflectionEngine, a cyberpunk style n
Yeah, that's why Win3.1 had no mouse or video card support.
--
Business. Numbers. Money. People. Computer World.
Well, if you don't like notepad, you can run vi.
--
Business. Numbers. Money. People. Computer World.
Trying to do anything while accessing the floppy has routinely blue-screened every 95 and NT machine I've used (not BSOD, the 'an error has occured while writing' full-screen nonsense).
The fact that NT doesn't do a full blue screen unless the kernel has crashed proves you're full of it. You're example is purely a DOS/Win behavior.
Basically, I'm sick of hearing slashdotters try to extrapolate their 9x horror stories to NT because it makes them sound more legitimate. Hopefully people here are smart enough to see past the similar GUI.
--
Business. Numbers. Money. People. Computer World.
Actually, blame Microsoft too. Just like Adobe, MS Office 95 and 97 isn't multi-user aware either. (Office 2000 is.)
So, if Microsoft can't even code their own applications to take advantage of NT features which have existed for 6 years, why would 3rd parties even bother?
--
Business. Numbers. Money. People. Computer World.
Umm, Exchange is an server application that runs under a service account on NT. It has nothing do with NT's multiuserness.
And to answer your question, it can't because MS Outlook and Exchange groups at MS are too retarded to be even on the same page, so you get a sucky client-server product. Exchange does allow server-side scripts, but they all run under the same privlege level as the server. Not good for user mailboxes.
So, your options are to either run Lotus Notes (which has a server-side security model) or a brain-dead type user-level mailstore such as traditionally found on Unix systems.
--
Business. Numbers. Money. People. Computer World.
MS SQL 7, MS Exchange, MS SMS, COM, DCOM, ActiveDirectory, ADO, CDO, IIS, MFC, WDM, DirectX, etc.
Despite this
Think of Apple a few years back. Many folks (including some on the board of directors) thought they should drop the Mac and just make high end WinTel boxes. They chose to make Macintoshes, even if meant going out of business. You don't think Microsoft is just as arrogant to do the same with Windows?
--
Business. Numbers. Money. People. Computer World.
The question is: is fragmentation a technical problem or a marketing problem?
A more important question is: how does fragmentation actually harm a platform? There seems to be a general fear of fragmentation about in the Linux community. But fragmentation doesn't seemed to have harmed Microsoft any; If anything, the confusion just encourages their customers to go out and buy the very latest of everything "just to be on the safe side". In the realm of Consumer Linuxism, this would translate into the latest Redhat or the latest Caldera, wouldn't it?
Personally I want everybody to do it my way.