Techinical reasons Windows is bad

[bwkaz]

Actually, supposedly XP was changed to use the "StrCmpLogicalW" API to compare strings when doing sorting in the shell; the "Logical" part means that 10 is supposed to come after 9, not after 1. You must be using 2000 or older.

(And Linux sorts "normally" too, by default, I am pretty sure (where "normally" means "1 10 2 3 4 5"). But I think there's a way to get ls to sort the other way; it's been forever since I looked it up, though. It had something to do with version-sorting, IIRC. But my point is, there's no way to get XP to sort "normally", if you do want 10 to come right after 1 for whatever reason. At least ls can be changed.)

[happybunny]

All excellent posts, exactly what i was looking for.

Thanks to everyone who's thrown in so far, but keep 'em coming.

I thought this post http://justlinux.com/forum/showthrea...204#post867204
also illustrates a technical argument for linux.

[teeitup]

All the talk about drive letters. UNC paths were allowed and used on servers. 2003 quit support for UNC paths making old software unable to migrate without considerable expense. As far as I know you can't use a drive letter unless your logged in. At least UNC gave you a choice. A big problem for server environment.

They want to play in the enterprise. XP, Vista, and any of the server versions still cannot perform a secure file transfer or a secure remote terminal connection without a third party addon. Sad.

My company has a standing change control to reboot every Windows server weekly. It may be over kill but it's the excepted practice. Were talking 100's of servers.

[wh666-666]

Yea i was going to say that happybunny. Partly by design and partly because windows is so mainstream there are reportedly over 60,000 bits of wild malware for windows in comparison to around 40 or so for linux

[klackenfus]

2003 quit support for UNC paths

I use UNC for my Server 2003 boxes everyday. UNC still works. Here's an example to my NAS, which is 2003:

\\nas1-dc-aus

[frimann]

2 days ago a friend of mine had problems with her laptop, suddenly there was no sound and it frose solid as soon as wxp started up.
I took it home and did all the virus spyware adware scans but nothing but adware came up.
So i googled the error message that windows shoved at every boot up, and the answer to the problem was that the latest windows security update had clashed with the realtec driver for the hd audio and there was a hotfix out from windows.

It is funny that a security update can make windows unusable, though this may be realtec´s foult. And most likely a lot of people had to take there computers in to bee fixed and payed a lot of money

Can anything like this happen in Linux?


This is one of 2 error messages:

"cpl.exe - Illegal System DLL Relocation
The system DLL user32.dll was relocated in memory. The application will not run properly. The relocation occurred because the DLL C:\Windows\System32\Hhctrl.ocx occupied an address range reserved for Windows system DLLs. The vendor supplying the DLL should be contacted for a new DLL. "

[wh666-666]

Lol thats another reason. Crap MS updates. Hell, its made me a few pretty pennies in home IT support in my area at least. Im aware of a sound problem just like you described. There are other problems with MS updates like the office update. During the past 6 months ive met so many people with that problem, incorrectly written code in an office update slowing the PC down making it unusable.

Best way to stop those problems is remove automatic updates and update yourself by choosing the updates you want. The above problem can be resolved by reinstalling the sound driver. Also check which adware programs she's using. Some really suck, especially the microsoft ones.

That sounds like im an ms hater but im not. They just cant code as well as a 12 yr old in his room despite being overpaid.

[klackenfus]

There are two words that MS has never heard: regression testing.

[bwkaz]

It is funny that a security update can make windows unusable, though this may be realtec´s foult.

Well, it's sorta kinda Realtek's fault. They got hit by it because their program loads hhctrl.ocx (the "HTML Help ActiveX", like that's a good idea...) before they load the "normal" user32.dll. And the recent (rushed-out-the-door) patch to fix the ANI-file problems made user32 and hhctrl conflict (they both specify the same base address).

If user32 is loaded first (like almost every program does), then when hhctrl is loaded, it sees that its requested base address is used, and relocates to another base address (just like all the shared libraries on a Linux system would normally do).

But if hhctrl is loaded first, then when user32 loads, it tries to relocate, but it thinks this relocation shouldn't be allowed for some reason (and no, I have no idea how they do it, unless the DLL-loader has special-case code for user32, or there's some field in the PE file format that says "don't ever relocate this DLL"). (The reason that user32 acts like this may be because of win16 stuff, or because of broken programs that load it and try to call directly into it without going through GetProcAddress. Or it may call into itself in some strange way that doesn't work with relocation. I'm not sure.) Anyway, when user32 tries to relocate but fails, you get that message.

The real problem is that the ANI file patch "rebased" user32.dll to an address that was already "taken" by hhctrl. Normally user32 is loaded first, so normally this isn't a problem. (But you might well ask why they bother rebasing a critical DLL like user32 in a security patch. I would ask the same question. Sigh.) But if you have any programs that load hhctrl first, you see this error, and of course the program won't run.

The bug is certainly Microsoft's, but Realtek can work around it by loading the files in the opposite order. Microsoft has a patch to fix the issue, but I see they still haven't released it to WU or Microsoft Update or WSUS (you have to visit the KB article). And I see they didn't rebase user32 back to where it was originally, either; they just changed hhctrl instead. (Sigh.)

See also their KB article: http://support.microsoft.com/kb/935448/

Can anything like this happen in Linux?

No, unless you use the (old, probably-unsupported) objprelink compiler setup, which only really helps if your program is loading tons of shared libraries, and starts up lots but doesn't run very often.

Normal prelinking (not objprelink) works like the non-user32 DLLs on Windows work: they specify a preferred base address, but if that address is taken, they relocate without any issues. (Even core system libs do this. The one exception is the pseudo-library linux-gate.so.1, which can't be moved -- but that's provided by the kernel, so it always gets first pick of addresses, so it never has to move.) And of course if you don't do either prelinking or objprelinking, then your shared libraries are perfectly relocatable too.

But the only thing that prelinking helps with is startup time (when the relocations are being applied). If your program starts up infrequently, then it's probably not worth it (unless users will notice), and if your program runs for a long time, it's also probably not worth it (because the startup time is dwarfed by the running time).

[frimann]

bwkaz

Thank you!