Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Microsoft

Fragmentation in the Windows World 413

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. "
This discussion has been archived. No new comments can be posted.

Fragmentation in the Windows World

Comments Filter:
  • Okay, I've got to address this becuase I've been painfully building GNOME on Sparc Solaris in bits and pieces since the 0.2X releases.

    So... it's 95% working on Solaris now, and I'm happy, but...

    Do you know how many times I've found
    #include linux/*.h
    in gnome code?

    or how many times I found that shell scripts with #!/bin/sh really meant #!/usr/local/bin/bash (sorry, linux users sh and bash are not the same!)

    I'd seen some #define CFLAGS -m486 stuff in there as well or sound stuff hard coded to use /dev/dsp, too.

    I can't blame linux developers for writing software to take advantage of linux features like glibc2.1 and linux headers, but be aware that the result is code that needs to be ported to other unices.
  • So when you install Office 2000 you don't think that its upgrading all your DLLs to the current Win32 API level. A classic case in point is InitCommonControlsEx which I got burned on recently since this function didn't appear in Win95 but did appear in Win95 OSR2 and all version onwards. The MSDN documentation clearly indicates that you ALL new apps should use InitCommonControlsEx and not InitCommonControls, so they are clearly insuating that someone is going to have to update COMCTL32.DLL so that your app will actually load. When you say that MS is maintaining backward compatability with new apps, they just upgrade your old system to run new apps. I bet that Office 2000 upgrades you to at least IE 4.02 if not IE 5.0, in which case you as well have just installed Win98 SE. Whilst this is all well and fine if the new DLLs are backward compatible with old apps, there have been some instances where this is not the case. WININET.DLL springs to mind. This DLL had its interface completely changed if you installed IE 4 on a Win95 box rendered all apps that relied on it useless.

    Ugh.
  • 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.
  • I am no lover of Micro$oft, and I curse their products regularly. However, there are a few things they are getting better at, and Windose is one of them. I've installed Win98 SE (full blown) on two computers at home:

    1) Fresh install on a Celeron 400 with an unusual zenon motherboard with built-in components. Runs fine. In fact, it is my main system which I do everything on, including software developement, and I never turn it off. It stays up for weeks at a time without any system crashes.

    2) Upgrade from Win95 OSR2 on a Pentium 166MMX with standard components. This system runs fine as well. In fact, the Win98 install/upgrade went off without a single problem and it cleared up several nagging problems I was having with Win95.

    I also happen to use win98 SE on several systems at work. I am quite pleased with the product and I would recommend it to anyone. I especially love the internet gateway feature they've built in. Now I don't need a linux system to get my home network on the internet.

    That is my 2 bits on win98.
  • The thing I remember most about the 95 beta was trying to get it the hell off my machine! =) It took me quite a while to find all the files it had dumped on my harddrive. Ah well.
  • I was under the impression that a.out binaries no longer ran under (most) default Linux distribution installs.
  • Yes, I believe this is true. I worked on a port of a VB app that was written in VB 2.0, and I had to gather all the "major" VB releases 'cause apparently VB = 4.0 uses normal text files.
    However, even after I had a full upgrade path to 6.0 (what the customer wanted it re-coded in), I STILL had a problem with legacy controls inside the forms. It was a monsterous project, to port a simple futures calculator. After that fiasco, I decided to stick to MFC only (when I actually program under Windows :)
    Where I work, we had problems with Word and Access macros too. If you don't upgrade version by version, you'll be left behind in the Microsoft world...
  • Eh.. "Slightly" off Topic, but ... This release was utter garbage. I am not surpriced that people experience problems with it.
    I am sure fragmentation doesn't help either, the more fragmentation, the more codebase. In the world of Linux, fragmentation happens within several different companies (like distribution) and sometimes in various code-bases, but the fragmentation isn't covered by any one company, like with MSoft. The extra effort hurled into supporting and upgrading all these different fragmented code-bases, Win9x in all it's forms, winNT, W2k, WinCE etc. etc.
    Maybe it is time for Windows to stop charter everyone and their kitchen sink, and start putting effort into releasing systems that fix things while not breaking other things. Win98 SE got the cute nick-name: Shit Edition after it refused to work on several peaces of hardware which its "old, buggy" version works just fine at.
    In some 15 installs, the new edition has only worked on 2. Someone will probably scream: change your hardware, but seriously, I would rather just change to an OS that actually work with what I have (it seems like 98 SE has a special affinity for not working with various network cards).
    It's about time Windows got it's stuff together, soon it won't even be good for playing games at if this is to continue, thus loosing it's usability all together.
  • At the end of the second sentence, I meant to say = 4.0.

    Sorry...
  • Amen,
    My experience is much the same. Win95 SR1 was crashing on me at least once every 15 minutes. I then upgraded to 98 RC 2, and crashed maybe once an hour. After further upgrading to RC 3, the machine ran better than it ever had for almost 9 months. At that point i was installing a new HD and doing general cleanup and decided "hey, while i'm at it i'll just put 98 full ver on"
    Big mistake:
    80% of the time the machine doesn't boot properly.
    3/4 of the time i get at least 2 blue screens, even on a simple restart. every time this happens i have to reset, boot into safe mode, _then_ restart, at which point normal mode comes up fine.
    But it works great after that!
    And people wonder why i leave the damn thing on all the time.

    RC 3 was/is far more stable than the final ver in my opinion.
  • 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.
  • 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.
  • Well, excluding Win3.1, Microsoft has to support all the major versions of Windows with Office 2000 - and thus obeying the "standards" of the Win32 API. The fact that Microsoft now has so many different versions of Windows to support is actually a good thing for us. As an example, Wine was able to run Office 2000 the day it was released. From what I have read in the newsgroup, it runs pretty well, too.
  • CRAP!
    LESS THAN OR EQUAL TO!
    I keep forgetting. (preview, PenguinDude, preview)
    Sorry.....
  • Although Microsoft doesn't sell a 16bit compiler anymore, Watcom does.

    Who is going to go out and develop a new Win31 project who doesn't already have 16bit development tools? The last release of Microsoft's 16bit compiler (8.0c) runs fine under Win98 and WinNT, even supports long filenames.

    As for "API reading from a serial port" changing, the only real changes were a few function names (open, close, read, write all changed to standard file i/o versions). All the wierd DCB stuff is still supported with no changes!

    I'm near the end of porting a big Win16 program to Win32 (maintaining both at the same time from the same source). Very little of the work is API oriented. Most of the work is rewriting 16bit assembly language, and wierd 16bit specific stuff with FAR or HUGE pointers and other kludgey hacks.


  • Win95 almost never crashed on my system. I don't know what you guys do with your stuff but Win95 always worked well.

    Which is a common occurence.

    Take the office I just stopped working at. There were five computers there: two Dells with P166's, an older Gateway, a pair of brand new Gateways with PII's, and a no-name clone.

    The old Gateway flakes out three or four times before lunch, but that's because the user is a serious 'cute little applet' freak. One of the Dell's can't run for more than 20 minutes without a GPF some days, and other days complains not at all. The new Gateways haven't had time to get twitchy and run happily all day long with little complaint. The other Dell (which used to be mine before I got a new Gateway from the boss to shut me up) once had to be rebooted 10 times in a day.

    The administrative intern in the office told me I was the only person she'd ever heard complain about Windows, and that she'd been using it for years with no problems.

    Fact is, there's no telling some days. It took me a long time to get over using a computer very gingerly once I installed Linux at home, because I was tired of things breaking every ten minutes. Other people use their Win boxes as functional multitasking workstations and have little trouble.

    I've given up arguing with anyone about it because I've learned that 'works for me' is the great argument ender.

    People will denigrate happy Windows users to the high heavens as having anemic skills and no clues, or as being brainwashed victims of the Redmond thought control sattelites, when the fact is, toy operating system or not, it gets the job done for people. Especially (but not exlusively to) people who are sort of timid about doing much but using what their box came with.

    I personally don't like Win 9x much as a result of my experiences, and have the usual complaints about Microsoft's business practices, but I've learned my experiences are on the negative side of a pretty wide spectrum of opinions from all sorts of people.

    I just wish people would stop worrying about Microsoft and get on with their lives. As much as I despise the apparent need some people have to define themselves in social terms based on their computer's OS, it's hard to ignore, because the fixation on the topic permeates the discourse of the community.


    ----------
    mphall@cstone.nospam.net

  • 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.
  • Note "...using the basic APIs..."
  • Sorry to say, but that's crap. You don't have to rewrite a Win3x Program to run on W2k.
    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

  • When was the last time you tried wine? The recent snapshots run most of the stuff quite well. Since wine is in development, more and more things run correctly. Comapring wine a year ago and now is irrelevent.

    Half of the stuff runs? Like, what might that be? From the apps I've tried, nearly all of them worked to what I expected.

    -xk
  • A confused Win98 user, discussing the random "shutdowns" experienced under Win98 SE:

    Is that a bug in Win98?

    She sounded mildly surprised!

    -k

  • Wow, I never thought of it that way, so it has to be interesting. =) Is Win3.1 really *that* fragmented from, say, NT, though? I never even thought of them under the same umbrella. Correct me if I'm wrong, but just how multiuser is 3.1 (not 3.11)?
  • M$ is tearing their ass up to maintain backward compatibility,

    That's absolutely correct. I can write one program and have it crash with exactly the same error code under every version of Windows! ;-)

  • I'd have to say from my Windows programming experience it would have been your fault. If you had followed the Win16 APIs like you had said to the dot, it would have looked fine in Windows 3.x. Remember, Win 3.x had a different look and if you hardcoded any single line of code instead of getting all metrics from Windows you would have amde a mistake.
  • What else need be said?
  • I had that run time issue. Guess what win32 program wouldn't run because I installed MSVC 6?


    Wordperfect. Coincidence?

  • First of all, it doesn't look like you read the article in question.

    Second, I ran Win95 for about a year total, and let me tell you, it crashed every single day, sometimes more than once. I don't have any odd hardware, just an NE2000 ethernet card, an SB AWE32, and an ATI video card. If that's not standard hardware, supported by just about every OS, then I don't know what is.

    And I did run NT for a time. What drove me nuts (other than the weird, super hard crashes that occurred every couple of weeks or so) was the configuration. Every little thing required a reboot--that doesn't drive you insane? And I bet the specs on NT uptime wouldn't be what they are (and they are pretty poor to begin with) without the constant rebooting.

    But back to Linux. Since I have installed Linux, my computer has been like a well trained puppy--always doing exactly what I want it to do, and never shitting on the rug, if you know what I mean.

    It is the best OS for the desktop.

    -k

  • So what happens when you compile a mutithreaded win32 application under win16?
  • 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.

  • If I remember rightly even Windows CE has different binaries for the different processors it runs on. This means that there are different versions of CE in my view.
  • Ahh, the FUD word. =/ Every OS I have used has had some sort of "fragmentation" or binary compatability issues as it has rolled versions.

    I think the story poster was trying to highlight that the IT media seems to be concentrating on potential linux fragmentation without looking at other OS's.

    That said, as far as the topic goes, if it is fud, it is fud-light. I've personally experienced significant issues moving our source base forward from Win16->Win32, and then sprinkling "if (HIBYTE(HIWORD(::GetVersion())) lessthanssymbol 0x80)"'s arround my printing code. If I was to bitch it would be with printing and gdi in particular. (I can't seem to get the less than symbol to appear when posting "plain old text" I must be an idiot.) =)

    Also, the various releases of comctrl32.dll have subtly changed certain message behavior of some controls our software uses. Admittadly it was somewhat cosmetic, but we have a commitment to making sure our UI is consistant across software releases, so it was something we had to spend time working around.
  • ...to just click "Save As Text" in VB3, and VB5/6 vill load and convert the forms/modules just fine.

    We just moved at pretty large app from 3 to 6 at work, so I know for a fact that it's possible :)


    --
  • Well, when the binary only app doesn't work, I ldd the app and then download the libraries which it needs.

  • Calm down, calm down.

    Alot of what the author said was false. Alot of it was FUD. BUT.. I think everyone is missing the point. The point here is that it IS true that if a software vendor designs a program SPECIFICALLY for, say, Win95, there's a fairly good chance that it will NOT work on ALL versions of Windows.

    Sure, with a little effort, you could probably solve the problem. Sure, a clueful developer would not design software that way. THAT DOESN'T MATTER.

    M$ and the Linux FUD-meisters are going on and on about Linux fragmentation, yet the issues Linux faces if the distributions become much more different are IDENTICAL to the ones the various Windows distributions (NT, CE, 98, 3.x) face TODAY. ie: MINOR issues that a smart software developer can work around and/or suggest user-implemented fixes for.

    So let's keep it apples to apples (no pun intended). EITHER Linux is in no danger of fragmenting OR Windows is fragmented already. You can't have it both ways and this article, in my opinion, is merely an attempt to attack Windows using the same logic and language used to attack Linux.
  • While there aren't seven incompatible versions of Windows, there is a lot of fragmentation on Windows platforms.

    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.

  • In general you're making some pretty good points here, but I think it's even worse than you describe. Micro$loth doesn't even need to create their own Linux distro. For the past month or so I've had the creepy feeling that when RedHat issues it's IPO MS (or at least Bill Gates) is going to end up as a majority shareholder. Then they could build a proprietary GUI on top of it and make use of both their own and RedHat's name recognition among newbies. They would be able to seed the single most popular linux distro. with their own proprietary gratuitous incompatibilities and call it an 'enhancement'.
  • Might fragmentation be a good thing for Windows? The UNIX market fragmented. Each guy took a copy and rewrote it and made it better and better. Then linux came along. Now every guy could add their own improvments but keep it non-propiatary.

    What if we could get the Windows market to fragment in the same fasion? Could we end up with a Windows that might actually be usable and stable?

    Jack
  • Preview? How am I going to get first post if I waste time previewing?

    Ok, deep breaths, PenguinDude. Count to 10...

  • For the record:

    Microsoft included an entire separate CD-ROM of Visual C++ Version 1.52 in the shrinkwrapped box that Visual C++ 4.0 came in, because VC 4 can't build Win16 (or DOS) binaries.
  • Hmm, I wasn't aware of that. My old computer has a non-IDE (Panasonic proprietary) CD-ROM drive (one of those that hooks up through the sound card), and it used a MSCDEX driver for DOS. When I installed win95, it continued using that driver (it still starts up in the autoexec.bat), and everything appears to be fine. As far as I can tell, there's no 32-bit driver loaded for the CD-ROM drive.
  • ooh that hadn't even occured to me. Now I really am scared.
  • Its true people, I've used it.
    The difference is:
    Win9x internals use ASCII
    WinNT internals use UNICODE
    if you decide to use the other one, it has to convert it to make use of it.
  • Actually the 'Basic' API isn't all that portable either - if you start from Windows NT and want to use all of it's features. For instance, I once took advantage of the 32-bit GDI coordinate space under NT4 for a map function (Considering 4Bx4B is _far_ bigger than say 1024x768, this works really well and allows smooth scrolling/zooming.) It could be modified for Win9x, but it wouldn't work nearly as well.

    Same goes for many of the other cool NT features... I wouldn't be suprised if most of the things in the 1st edition of "Advanced Windows NT" wouldn't work on 95 quite right. :)

  • Watch it if you're running NT. The last several times I've run it on my machine, NT's filesystem has decided that it just doesn't feel like existing any more (i.e. I boot up one day to 'no operating system found', and then proceed to thank various Ancient & Powerful(tm) deities that I never kept any Real Work on there). The filesystem implosion thing has happened twice to me, and at least once to another person I know.

    Am I alone in this happening to me?

    (yes, well, obviously if it happened to another person I know, I'm not really alone in it, but I was speaking within the context of slashdot. I think. Anyway, it's coffee time. mmmm.... raspberry chocolate.......)
  • Yes, you are right. In fact, I did use the "Save as Text" option to get the form saved (cause the company I was doing this for only bought me a copy of VB 2.0 and 6.0, not later ones).
    The main problem I tried to illustrate was the fact that ealier versions of VB used controls that were no longer supported in the later versions. As any VB programmer knows, when you got a ton of controls all squeezed onto one form, maintenence becomes a real bear. Anyone know of a way to port the old controls over to VB 5.0/6.0? I'd rather use the new controls for 5.0/6.0 that replaced the legacy ones, however, if there is a faster way to simply import the legacy controls, that would make the job a piece of cake.
  • Bullshit
    I test Windows 2000 and every single Win32 app has worked besides games which the installers were written in a stupid way, instead of checkig for DirectX they check for Windows 9.x and then fail....Thats not Microsoft's fault, that is the people who write the software.
  • Almost everybody has tons of libraries and code installed on their Linux systems, because there is such tremendous fragmentation when it comes to developing X apps. I remember what fun I had building XCDRoast on my Linux system. I didn't have Tix installed. Tix needed to be integrated with TCL. I had to rebuild TCL with debug turned on in order for Tix to integrate with it.

    I may be forgetting a few of the details in this mess (nitpickers, have at it! we'll all be fascinated by your recall of arcana!) but I remember what a horrible mess it seemed at the time.

    XCDRoast was great, once I had it installed.
  • Well...
    I just got a full time Linux Programming job. I will be leaving a Windows only company. Here is my experiance. First let me say that I work for a realy big company. The second largest in the world. Here is what I found about windows programming and the reason I can't wait to delete all the windows programming software off my Hard drives at home.
    First I will start with C code. At a large company you have a lot of programs that are old as dirt. Like one C program I had to kinda redo to get to compile with MSVC++ 5.0. When I looked at the code for the first time I thought It was very well written. There were even If defs on the reusable source files that could be re-compiled to OS/2 and Unix. It was these files that caused the most problems. Why you ask? Because Microsoft in a attempt to kill portable C code has changed alot of functions that were ANSII Standard functions to functions that Now have a underline in the frount and capitals in the function name. This turned out to be a nightmare since the Help files for Microsoft sometimes did not make the new names clear. Not to mention the fact that now the code was not nearly as portable as it was befour. since most of these functions were part of the code that should not have needed to be changed to compile on other OS's. After 4 years writing C code that should be as easy as a recompile to another OS this deeply affected my opion of Microsoft. Okay Okay... so this is a pretty easy problem to fix.... It was time consuming and still sucked. It is also a reason why I will be using a different compiler then MSVC++ in the future. ( if i ever do windows again ).

    Second problem. This time MSVB. From VB4.0 16bit to VB6.0 32bit. This time a control from a 3rd party that worked perfect under windows 3.11 did not work at all under windows95. So... I had the task to compile to VB 32 bit. When trying to compile under VB6.0 I was presented with a ton of other problems. Seems that all the other 3rd party Objects that was used in the VB program would not work at all under VB6.0. Seems that Microsoft had purchased all these controls and put them into VB6.0 with the same names only now they all used the Variant data types. This nightmare extended it self to all most every method that displayed data to the user. So yet again. Not a real hard problem, but very time consuming and it sucked.
    I have done quite a bit of Unix type programming in my time. Most of the time I would write things like BSD Socket services on linux first. Almost every time I would take my Linux source and move it to UnixWare, SCO, or BSD. All I had to do was to change the compile options in the Makefile. The *nix code I wrote 4 years ago can still be compiled on all most any *nix box. I can't say that for my C code for Windows. Now I don't even try to make windows code portable.

    I don't think that the "Hard Core" windows programmers even care about running there code on other platforms. So maybe they are more inclined to dink around every time Microsoft comes out with a new Dev Package. I'm not. Thats why I'm leaving the world of MS Windows. Besides InfoWare ( or Web based applications ) will make the OS a client is using a mute point anyway.
    Also. since I work for a really large company that has based there application on MS products there will be quite alot of programming needed to be done when they try to get the current application Security model working on Win2000. I'm glad I wont be around for that!
  • Humm... there should be a RealTek driver for Linux, but it is a slow chip anyway. (Grr. All the GOOD cheap NICs vanished the day Intel bought DEC Semi.) As for sound cards, I've found the Ensoniq-chip Creative boards (AudioPCI, SBPCI64(D/V)/128, _not_ PCI512) cheap ($30) and well supported. There are probably some other good cheap PCI sound cards too with native (no SB emulation) Linux drivers.
  • This is true. Portability is a non-issue for 99% of Windows developers; my Win32 program will run on any version of Windows 9x without any changes. In many cases it will also run on NT. Portability is a must in the *nix world where there really is fragmentation between operating systems, window toolkits, &c. Incidentally, I see a bunch of questions about porting a program from Win32 to Win16, which is just plain stupid; it almost never needs to be done. You might as well port it to MS-DOS. If you have a win32 program that absolutely needs to run under Windows 3.x, you install the Win32s library, which allows Win 3x to run most 32bit apps.

    One of the reasons I have not started programming Linux yet is that I am loath to waste my precious time distributing two versions for just KDE and Gnome.

  • Yes, there is POSIX support in NT. HOWEVER...

    The posix subsystem is separate from the win32 subsystem. That means that you can't make any calls to the win32 API if your program uses the posix subsystem! No graphics, none of the standard windows tools. As such the POSIX subsystem is almost entirely useless, and the only place I have seen it used is in the latest 'get administrator privs' crack.
  • 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.
    ---
  • If you write under Win95/98, using the basic APIs (MFC, Winsock, etc.), the resulting code will run identically under Windows NT.

    Now, the reverse is Not true, but can be if you are moderately careful.
  • I did most of my high school programming in VB, because I was forced to. Even in the simple programs I made, Windows and VB incompatibilities really pissed me off. Some examples:

    -A setup program for a VB3 program made with the VB3 setup wizard works in 3.1, crashes in 95
    -the grid and database controls changed significantly between VB3 and 5, requiring a great deal of recoding to port the program.
    -One VB5 program which, while compiled as a .exe, wouldn't run on the target system unless VB was installed on it. I've had this problem with VB3 as well.
    -One VB5 program which ran fine in the VB IDE, but crashed when run as a .exe. THAT was a bitch to debug.

    And they wonder why they're losing developers.....
  • Start an install using the upgrade CD on a formatted harddrive. It will ask you to insert your Win95 or 98 CD for verification. It will proceed with a full, clean install.

    Create a blank text file on your formatted harddrive called "ntldr"; no ".txt", just "ntldr". Install from your Windows 98SE upgrade CD. Win98 will see that you have NT on your system and will "upgrade" it, and replace any and all portions that are "missing".

    You will need to have the CD drivers on a boot floppy or boot from the CD.

    For Win95 create a text file with these lines:
    [Setup]
    ProductType=1
    ccp=0
    Run D:\win95\setup.exe C:\"filename".txt from DOS.
    This will install a full version.

    It's important to note that you must have a legal right to do so, but ability does not equal authority.

    All of this assumes, of course, that you want to install Win 9x on a system. I personally wouldn't want major software upgrades cluttering a system regardless of the OS. If we've all followed good housekeeping procedures with regards to partitioning system and data, this shouldn't be a traumatic experience.
  • My experience has been that PCI swaps pose no problems in NT4, but ISA does. It takes some finagling to get NT4 to play nice with the new configuration. However . . .

    I've changed the motherboard twice on my NT4 machine with the same installation. I had to make sure that the drives stayed on the same Controller and in the same master/slave configuration. My ISA modem had to be set up again, but that was it. The only time I've reinstalled was for shits and giggles and to reconfigure where the OS and the data lived.
  • "Each guy took a copy and rewrote it and made it better and better."

    How would you suggest that we "[take] a copy [of Windows] and rewr[i]te it and ma[k]e it better and better"?

    Without the source, we cannot improve things. It just means that Microsoft's (and their OEMS') already overworked undercapable support structures will become worse and more monolithic.

    This whole situation is evenn further compounded by Windows' braindead approach and culture around shared libraries. Would any Linux users here be happy if, when an application was installed by an unprivileged user, without asking the user, it went and replaced libc.so or any of the X libs with a newer, incompatible version? This _is_ the accepted way of doing things on Windows. The net result is you have a complex system of applications, all stepping on each others' toes. Would you like to be providing the support for this system?
  • by warmi ( 13527 )
    This article is nothing but a bunch of pro-linux FUD. I came to Linux after 5 years programming on Win16 and Win32 and Linux is much , much more fragmented than Windows ever was. Just think about this: how many times were you unable to run something on linux due to incompatible libraries ??
  • ...but it was win95.

    it's werd to one day bootup your system and get 'error no operating system found'. this really freaked me out. and was one of the meny reasons i moved to linux.


    nmarshall
    #include "standard_disclaimer.h"
    R.U. SIRIUS: THE ONLY POSSIBLE RESPONSE
  • Well, I don't really have that much exotic hardware, but I had much less problems installing, for example, my ethernet card in Linux than I did in Windows. In Windows, the first time you put it in, it "detects" it, but it doesn't always know what to do with it. I just had to fool around with it and boot it a billion times until I got everything right. And I still have like phantom drivers for it in my system devices. In Linux, it was simply a matter of uncommenting all of the modprobes, rebooting and then looking to see which one worked, then recommenting the rest. If I had known which one it was, then it wouldn't have even been that hard. In Windows, if I didn't know what I had, I would have to reboot 200 times trying every ethernet card I thought could be mine.

    The only thing that was more difficult in Linux was my soundcard, but only because it comes with a special install disk for Windows. Without that disk, Windows has problems with it, even though it's a genuine SB.

    The only thing I had to manually enter any settings for was my soundcard. Every thing else is automatically figured out at boot.
  • This is one of the worst submissions ever !!!

    Complete bulshit !
  • "example: i'm still "fighting" with my colegue on photoshop pelettes positions and some other preferences
    because adobe takes same "multiuser" policy as microsoft."

    Well, I know I'm going to get flamed for this.. but..

    NT _is_ multiuser. Each process has an owner (which can be any user on the system), and inherits the permissions of that owner. Processes running on the machine at the same time do not need to have the same owner. In fact, when you're logged onto an NT server, there's usually processes owned by three other users (System, WWW, and maybe Administrator) running continuously during your session. In this way, NT is somewhat like UNIX.

    However, from NT 3.x to 4, there has been no way for multiple users to interactively log on concurrently. The windowing system is basically based off of the same code that was introduced in Windows 3.0, which doesn't even pretend to be multiuser. The only functionality that NT 4 really lacks compared to Linux in "multiuser-ness" are a remotely displayable windowing system, a text-based way to log in remotely (telnetd/ssh/what have you), and multiple virtual consoles.

    This changed a little bit with the introduction of RConsole in NT 4 Resource Kit, which provides a text-based interactive login for remote users, and VDesk, which provides up to 9(?) multiple virtual desktops (in which you can be logged in as one user on one desktop and another user on the other).

    However, Windows 2000 is where a Microsoft OS will finally have all the 'real' multiuser perks. Remotely displayable GUI (which I'm sure the Samba guys or someone else will produce a Linux/X client for) will be included (in Win2k Advanced, at least), and get this.. a telnetd. Plus the functionality of VDesk.

    As for the fact that Photoshop doesn't save your settings correctly, blame Adobe and not Microsoft. In the Registry (which, yes, is evil), there's HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. When you log into an NT (or even 95 or 98) box, it reads in the values of HKEY_LOCAL_MACHINE, and then overrides those values with the values in HKEY_CURRENT_USER, if they exist. Applications are supposed to store settings like window position, etc, in HKEY_CURRENT_USER, and only the out-of-the-box defaults in HKEY_LOCAL_MACHINE (in case a user hasn't used that particular app before). However, application vendors are often stupid and store all their settings in HKEY_LOCAL_MACHINE, which means that no matter who's logged in, the app uses the same settings.

    I don't mean to sound like an NT cheerleader here.. I actually use Linux at home and prefer it. However, it annoys me to see people bashing NT for things that (in my mind) it actually does correctly (such as multiuser-ness in the registry and dynamic web pages). One would sound much more intelligent by bashing NT for things it sucks at (such as being a mail server or not having to reboot).


  • NT doesn't allow any direct access to hardware. Thus, DOS games' sound often wont work, nor will DOS communications programs.

    Matt
  • That's stupid. If anyone prime interest is in Warcraft than he/she should stay with Windows - it is completely pointless to go thru all this just to play a game that you could already play with no effort whatsoever !!
  • "Can anyone actually name me an app that requires specific kernel version (or at least a certain version). Oh
    yeah, closed-source binary only kernel modules from don't count!"

    ipchains. It requires at least a 2.1something kernel (though you can patch a 2.x kernel to work with it) and doesn't dig pre 2.0 kernels at all.
  • I do scientific computing, in large heterogeneous networked environments. There are usually several versions of everything running. The code base is large enough that it is a pain in the a** to have to re-compile and re-link everything (even if everyone had consistent versions, which they don't).

    Among other things, I've had to deal with the Sun WorkShopPro family of compilers, particularly f77 and f90, versions 3.0, 3.2, 3.5, 4.0, 4.2, and 5.0. Taken pair-wise, that's 12 combinations -- no two of which are link-compatible. (Of course, Sun claims that they are... :-) I wish they'd reimburse me for about $12K in extra labor that incompatibility has cost us just this last week;-(

    And the PHB's are Sun-bigots, in love with their stuff. It's hard to make them listen to reason.

    fwiw

  • You are writing this from Win box , arent' you ??

  • "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."

    When will people understand that WinCE (the most appropriately named Microsoft product ever) and NT Embedded are not Windows and Windows NT? They're completely different operating systems, with different code bases, and similar but different APIs, that try to share a common look and feel with MS's other products. It's kind of like complaining that porting your NeXTSTep wharf applications to LiteStep isn't seemless. Similar look, completely different guts.

  • Try moving any card to a different PCI slot, windows will flip out and reinstall the driver for the thing, Linux won't even care...

    Move your NIC, windows will install a second driver for it, losing ALL the settings for the thing...

    Install a new mother board, when you boot windows you will have no cdrom, and it will try to install drivers for the disk controller, but you can't use the cdrom to access your friggin win98 disk! To fix this, boot off a floppy and load some dos cdrom drivers, then boot windows and you have access to your cdrom again.

    in linux...

    Install new mother board. Boot Linux. Linux sees the disk controller just fine, finds all the hardware you had in your machine and boots without a problem.

  • >Don't worry. You are.
    Wow...a tad touchy, aren't we?

    In reply to the rest of your comment:
    Let me guess...you also believe that little green men abduct people on a regular basis.
    MS has played a big brother role...that's not in question. But you toss out the idea that MS distributes unseen patches...now, correct me if I'm wrong but something like that would leave finger prints...such as extra packets being transmitted, changed dll's that some AV program would pick up. You might suggest that the Windows API allows for such modifications. Well, considering the quality of the rest of Windows, I think evidence to that point would have already come about. When you have proof of such calls, then you can start throwing out your "theories."

    When it comes to MS specific URL requests, I ran a couple request on altavista and yahoo using both NS and IE on a Mac at my place of emplyoment. Identical results (at least the first 20).

    Let me play devil's advocate for a second:
    kfm:KDE::ie:Windows
    Without kfm's web intergration, KDE would be a significantly different desktop enviornment. Are you telling me that KDE can do web integration, and MS can't?

    As far as the "Windows 95 Compatable" deal goes, its MS..its a big corportaion, and like most big corporations, its multifacited(sp?). One comittee judges 3rd party software, and another one actually writes the OS. Such problems are to be expected.

    Wow, I sound like a Microserf here. Makes me feel kinda dirty. ;-)
    --------------------------
  • You're missing the point. The point is there are at least seven ways of getting something that is called Win98 SE. And each way gets you something different. Some fix some bugs, other ways fix other bugs, some methods give new features, and some don't. But they all have the same name.

    We're not talking here about WinNT vs Win9x vs Win3.1. When a customer buys one of those products, they know what they're getting, just as customers understand that SuSE and Redhat may be considerably different. But what about two Win98SE people, who each got it by a different method? Something might work for one, but not the other, because of subtleties related to the install. Confusing, no?
  • What the hell is this? quite frankly, windows is almost perfectly compatible.

    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.

  • The last time I had an IRIX box on my desk, I missed a few fine points from GNU system utils (on my Linux box). No problem, they all compiled and ran 'out of the box'. Linux can run SCO apps (I understand that SCO can now run Linux apps as well). If different OSes from different vendors with diametrically opposed philosophies can manage to be compatable, why can't two teams within the same company manage to do the same?

  • Well, you're not exactly on the mark either. I agree you may not have to rewrite your code when you port, but the fact is you very often do have do a rewrite.

    Where I work, we develop Win32 apps to run on Windows 95/98 machines. The same code base typically will work for these platforms. However, in our experience, it is rare that the same code base will produce a properly functioning application on any variant of NT, or on Win 3.x. In fact, one of the developers on our staff is a big NT proponent and develops exclusively on that platform -- developing components whose target platform is Win95/98. It is far and away the norm that the stuff he writes will work under NT but not on the target platform. He is always surprised at this. Likewise, apps the rest of us are developing under Win98 typically misbehave/break under NT.

    Maybe we're morons, but I don't think so. Sure MS is "tearing their ass up" to maintain backward compatibility. That doesn't mean they are accomplishing their goal. And, in fact, it is well known that apps often don't work on one platform that do run on the other. Hell, they seem to have enough trouble keeping apps running under different iterations of Windows 9x!

    I do think the article stretches its point a bit when defining 7 variations of Windows. It's a bit unfair to call separate distribution methods different variants. Sure, based on the distribution method you choose, you may wind up with a different set of code than what someone else got, but the same point could easily be made for other OS's. How many different ways can you aquire Redhat Linux, for instance (source CD, RPM CD, download source, download RPMs, download tarballs, just to name a few)?

    His broader point is valid, however. We have at least Windows 3.x, WfW 3.x, Win 95, Win 95 OSR2, Win 98, Win 98 SE, Win NT 4, W2k, and Win CE. These platforms could be fairly judged to be at least as fragmented as some are claiming exists with Linux. I think the level of fragmentation on the Windows side is actually higher.
  • From an article about Win2000, it appeared that only about 70% of Windows NT4 apps would run OK on Win2000 - allegedly MS has put stability as a higher priority than backward compatibility in this release. However, all previous releases of Windows have been highly upward and cross compatible - there is no need to modify source code much, if at all, as long as it was written right in the first place, to port to a different version of Windows (excluding WinCE, which is a smaller subset of Win32).
  • "How easy is it to port an NT/Win 2000 application back to the good ol Win 3.11? I dont think that is "just"
    an recompile ;)"

    What's the motivation for porting a NT/Win2k application back to Win3.11? What exactly have you been smoking? It's like porting a big Linux application to Minix.
  • "Must be those damned non-Microsoft programs again."

    Here's my theory.

    If you set up ANY operating system in a shitty and haphazard manner, it will crash. This is true for both Linux and NT.

    Linux comes out of the box (or the tar file, or the ftp site) set up in a fairly well-done manner. It's also relatively easy to set up Linux in a well-done manner (it's hard to do it perfectly, but that's hard on any os).

    Windows 95/98/NT, however, comes out of the box set up in a shitty and haphazard manner. It's also fairly difficult to set up in a well done manner (and hard to do in a perfect manner, also).

    However, if you really know what you're doing with NT (which I do, thank you), you'll actually get a groovy thing called uptime. The NT server here has been up since the day they released Service Pack 5, and before that, was up till the day they released SP 4. (and it handles a lot of shit. Shared drives and printers, WWW Server, SQL server, etc). The Linux box here has been up since I moved the kernel to 2.2.10, and before that, was up since I moved the kernel to 2.2.5 (it also handles a lot of shit.. Mail, DNS, WWW, FTP).

    So.. as I see it, NT can be just as stable as Linux. The difference is, Linux usually comes to you already stable. NT you have to put a lot of work into.
  • Fact:

    Cyrix chips suck.


    Theory:

    Crappy companies that release crappy hardware only write drivers or design hardware for Windows consider the driver bug-free if it doesn't crash within 5 minutes of light use. Then they go out of business or get bought and eviscerated by the company that bought them.

    Linux does better with this crappy hardware than Windows does because many drivers for Linux are written by people who really can't afford good hardware, but hate having their box crash. Therefore, they first write drivers that expect the hardware to do exactly what it should, and then write workarounds for particular pieces of crappy hardware so that they'll work correctly, too. Ever compiled a kernel? There's stuff like this all over it, and actually, that's a very good thing. So in many cases, the Linux drivers/code actually work better than the manufacturer supplied drivers/code.

    Windows sucks with this crappy hardware because (a) the company doesn't care, or (b) if you don't have money, MS doesn't really care about you, and since they can certainly afford the top of the line, they aren't plagued by crashes from crappy hardware. If MS has to write a driver, they just write code that expects the hardware to do what it should, and freaks out if the hardware doesn't.

  • 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.
  • 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.
  • 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 :)
  • Well, I just checked my CONFIG.SYS, and the following line appears in it:

    DEVICEHIGH=C:\FORTE16\DRIVERS\CDMKE.SYS /D:MSCD0001 /P:630


    Forte16 is the soundcard, and this non-IDE CD-ROM connects through the soundcard, so i assume these are the CD drivers. It's a 16-bit soundcard, and the drivers are 16-bit DOS drivers, yet are still loaded in CONFIG.SYS, and appear to work fine.
  • 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' ?"
  • Main gets redundant though.

    Even when I create KDE/QT apps main is redundant.
    You really don't need to deal with main!



    int main (int argc, char **argv)
    {
    KApplication *app;
    KExample *toplevel;

    app= new KApplication (argc, argv, "Example");

    toplevel = new KExample();
    app->setMainWidget(toplevel);
    toplevel->show();
    app->exec();
    }


    ---------------------------
    ^_^ smile death approaches.
  • Not a programmer, but ...

    Many NT 3.1 apps broke moving even to NT 3.5. When Office 95 came out, it was accompined by a NT service pack (for 3.51) which, again broke certain things, presumably because NT's Win32 was changed to be compatible with 95's Win32.

    I'd be real curious if MS Office 4.2 for NT (~1994) would even run on NT 4.0SP5 or Win2K. It ouuughhhht to, but the number of NT workstation users was so low back in those days that the lack of backwards compatiblity probably doesn't affect anyone.
    --

  • I know of certain Win 3.1 client-server programs that relied on special network drivers and the like that broke under 95. (Much of this stuff was NetWare ODI/NETX stuff with a *.386 driver to go along with it.)

    As far as CD-ROM drives and SCSI cards, MS put alot of effort in Win95 to get the old DOS drivers to run under 95. (And yes, you can try to run the Novell DOS stuff, although it's troublesome.) The fact that you might want run those old drivers was the primary rational for MS developing Win95 instead of just dropping DOS/Win and just going with NT a long time ago.
    --

  • Yeah, that's why Win3.1 had no mouse or video card support.
    --

  • From what I heard, the problems with NT/9x apps on W2K are primarly due to the fact that they're ignorant of security and try to do things like installing their DLLs in the system directory.

    NT4 got around this by shipping with pretty loose security (especially on parts of the registry). MS got smart and realized that if they are ever going to make an omelette they're going to have to break some eggs.

    For what it's worth, Win2000 is going to ship with a bunch of scripts for the obvious problems (Office 95,97!, etc.), and a tool to switch to box into low security mode.
    --

  • Well, if you don't like notepad, you can run vi.
    --
  • 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.
    --

  • 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?
    --

  • 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.
    --

  • MS SQL 7, MS Exchange, MS SMS, COM, DCOM, ActiveDirectory, ADO, CDO, IIS, MFC, WDM, DirectX, etc.

    Despite this /. thread, the *only* thing Microsoft has going is 95% backwards compatibility. Furthermore, they've got where they are despite never producing a particularly scalable or reliable product. Why would they throw out 8 years of legacy intefaces rather than just trying get what they got to be stable and reliable.

    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?
    --
  • If you really want to find fragmentation on Windows, you don't have to look far:
    • It's in DLL conflicts and VB runtime version mismatches...and the fact that IE 3 and IE 4 can't coexist in the same Windows installation...
    • It's in the fact that certain of the MS products require a particular version of IE...
    • It's in the reality that Outlook and Outlook express are two entirely different beasts, sharing only a name; and that (when IE4 was originally released) you couldn't send email messages between them...
    • It's in the fact that I have copies of MSIE 3 that swear blind that they are actually copies of MSIE 4 (this when queried via Javascript under oath).

    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.

Do you suffer painful illumination? -- Isaac Newton, "Optics"

Working...