Microsoft Windows

[Robbert]

Does any one knows in what kind of language the OS of microsoft is written?

I know it was based on DOS bt now it is a stand alone and Dos needs MS Windows to stay running

Windows XP doesn't has dos mode any more, quite enoying. :-\

But does eny one knows in what kind of language Windows is written, assemble or C ? ???

[frank]

I'm sure it has some assembly in it.
No OS can function without it..
(well.. you could ofcourse put machine language in it..)

As far as I know Win 9x was written in C
win 2000 / XP were written in C++

[Robbert]

??? but why does every body, linux and all the other concurrents, want to know the MS source ? if it is written in C++ and a bit assemble I think they would know enough then if they are good ??? :-\

[frank]

I have not heard of anyone of the linux community that wants the windows source.
Besides, people like linus thorvalds are to busy with their own things.

[Schol-R-LEA]

The main reasons to want the Windows source code are a) if you are writing low-level utilities for Windows, and need to know what a given part of the system actually does (rather than what MS says it does), or b) to laugh at how poorly it is written.

[Pype.Clicker]

i even heard of people praying for Windows code *not* to be released because

it would corrupt the open-source community with rotten stuff that will contaminate other tools and lead to complete chaos

-- of course i do not caution those words myself ... Even if it was released, would it be useful, considering the large amount of code it would represent and the thin community (?) of people that would know what thing does ?? It would take ages to dive into it and find out what does what, no ?

[Tim]

From what I've heard, the Windows source code is:

a) huge
b) full of compatibility hacks to keep old applications running on new Windows versions

[Pype.Clicker]

@tim: nothing really surprising at this ;-p

btw, Microsoft is known to love 'proprietary-extensions' to standard. The source will certainly implement those extensions, but you'll have no (or few) documentation of them in the code ...

[Perica]

..

[Solar]

Copy that. Extensions are necessary, and downward compatibility is necessary. You better cater for both. Microsoft simply didn't learn the lessons from their many, many architectural changes - their system still handles both issues like there is no tomorrow (and differently from last version, mind you).

[Candy]

Microsoft simply didn't learn the lessons from their many, many architectural changes

It's not only microsoft that is to blame. I've read one or two articles on the subject of keeping everything running, and there are loads of applications that simply don't comply to the windows API but hack in memory, do things that are defined to be impossible and if those memory layouts or those functions are later defined, it crashes big time. As for microsoft, kicking 50% of the applications because they're crap is not like their ideal, compatibility is. That's why they made at least one hack to keep the memory layout the same (doubling the actual layout to the old one) and another to keep that application from doing what was impossible.

Keep the applications at bay with your API and you're in a better position to discuss than microsoft. If they CAN break it, they WILL.

[Pype.Clicker]

imho, one thing that could help to address this issue is to allow several "execution environments" to co-exists. The program announce which API version-evolution-release it wish to use and if there have been significant changes, a "compatibility environment" is presented to the application ... That "compatibity environment" will fake the old systemcall in the new kernel.

Imho, enforcing test on parameters given to system calls could also prevent the user from "hacking around" the documentations ...
I cannot stop thinking that MS developer themselves hack around the API or use undocumented APIs to make better/faster products, but they know how to hack correctly and so their software works ... while other softwares discovered undocumented API by reverse-engineering or something and thus have less clue about what shouldn't be done with it ...

[Solar]

Amiga, actually, faced the same problem. So many applications hacked their way around AmigaOS 1.x to access the hardware directly, that by the time they considered moving from 1.3 to 1.4, things were FUBAR.

What they did was, they released a v2.0 that broke a great many things for the v1.x applications. Bang. In your face.

Developers were so scared that they - or at least most of them - adhered to the API from there on.

The transition from 2.1 to 3.0 was pretty smooth then.

[Tim]

b) full of compatibility hacks to keep old applications running on new Windows versions

This is a result of bad design decisions, one of the things I hate about Windows. The system should've been designed in such a way that extensions to parts of the standard could be made without effecting currently written applications; therefore eliminating the need for hacks to the source code.

No, it's the result of badly written applications.

Large application vendor writes an application which cuts a few corners in the source code but which basically works on the systems they test it on. Millions of people worldwide buy the application and begin to depend on it to run their businesses.

Microsoft develops a new version of Windows, and tests this big application on it. They see that it crashes, because some assumption the original programmers incorrectly made no longer applies on this new version. Microsoft realise that the businesses who depend on this application will not upgrade their Windows because they will no longer be able to run their application. The original application vendor has gone out of business, has stopped supporting this application, or just don't care; either way, they're not prepared to put out a patch.

So Microsoft must either put a workaround in their source code, or patch the application at runtime. If you're using Windows 2000 or XP, you can see these patches in the %SystemRoot%\AppPatch directory.

[Schol-R-LEA]

IIRC, the same thing occurred in the Mac, in the first several revisions (esp. System 7.1, where they switched to 32-bit clean code, IIRC; the previous version, 6.8, was the MacOS equivalent of DOS 3.3, in that it was a very stable version that lingered for years until a drastic upgrade forced everyone's hand), with the result that after revision 7.5, misbehaved apps were rare, and the OS needed very little in the way of special-purpose backwards compatibility support (mostly related to emulating legacy 68k code on the PPC). The transitions from 8 to 9, and from 9 to X, were surprisingly smooth considering the radical changes made at those points. Or so I understand.