Post by Michael D. OberNot a myth. Windows 1.0 was written in Pascal. At the time, MS didn't have
a decent C compiler but did have one of the best rated Pascal compilers.
At
Post by Michael D. Obersome point, I don't know when, but I suspect it was Windows 386 (written for
Compaq), Windows was completely rewritten in C. However, to maintain
backwards compatibility, all the 16-bit stuff still used the Pascal calling
conventions.
Mike Ober.
Post by RalphPost by Tony ProctorActually Ralph, some of worst misconceptions and unjustified diatribes
about
Post by Tony ProctorVB that I've seen were from C/C++ programmers. Some of these actually
suggested that VB6 was interpreted at source level. Obviously they had
no
Post by RalphPost by Tony Proctorreal experience or knowledge to back this up, and were simply spouting
second-hand mythology, as you suggested earlier.
Tony Proctor
My favorite "Windows Myth".
Years ago, I was once was confronted by my Unix buddies that Windows was
actually written in Pascal. When I laughed I was immediately shown the SDK
manual which did in fact clearly declare all functions as "FAR PASCAL".
<g>
Post by RalphIt still shows up occasionally.
-ralph
[Way, way, off topic.]
[My apologies to the rest of the group, but I find this difficult to ignore.
Perhaps related to early Germanic elimination training. <g>]
It is a myth. It is interesting to see it is still alive and well.
Like all myths this one also relies on interesting extraneous "facts" but
draws the wrong conclusion.
It is true that MS didn't have a 'decent' compiler until at least version
5.0. (some would argue they still don't <g>) But MS hasn't "eaten their own
dog food" until recently (and AFAIK, they still don't). There has been a lot
of speculation about what compiler they did use. Best evidence is it was an
IBM/Intel compiler, internally modified and optimized. A great deal is also
written in ASM.
[There is also some confusion as Gates launched into a Ms-Unix product
(XENIX) around this time which caused the need for a new "Unix-based"
compiler. Earlier versions of the MS C compiler were predominately pure
"PC-based" (Lattice-C) with lots of vendor-extensions. There is no doubt
that MS-C 5.1 was the result of this effort. It is quite possible that Ms
didn't have "A" c-compiler, but likely used many different ones for separate
pieces/products.]
So yes, Windows was not written with their published C-Compiler products.
"Windows" development actually goes back a lot farther than published
products would indicate. Back then (early 80's) the major thrust for system
developers everywhere was the creation of a Multi-tasking application and
'extended' memory managers. (What good was it to be able to run multiple
tasks, if each task only got a piece of 640k - a quickly diminishing
resource.) The most popular was DESQview and QEMM (Quarterdeck). The earlier
windows products were merely Ms's versions of these types of products.
(Albeit, DESQview was character-based and Windows was Graphical-based). The
Pascal languages available at that time were remarkably useless for
developing these types of utilities, but quite useful for creating
applications that ran in this new environment. Memory Management and graphic
environments were for the most part were written in ASM.
At the time the most common "Graphics Library" for a PC was Turbo-Pascal. As
the Ms compiler had a limited clunky graphics package - it was easy for
outsiders to assume they were looking at a Borland product. I believe that
has given some strength to the myth.
Windows 286/386 were not particularly successful and not near the quality of
QEMM and BlueMax. But everyone needed/wanted a memory manager. [Next to
MS-DOS itself, memory mangers were the second most pirated software. I am
the only person I know that actually bought a copy of Windows 386.] Many
vendors started shipping QEMM et al, with their shiny new 386 boxes. This
annoyed Ms to no end. <g> So Ms bundled the product with their MS-DOS
licensing and forced many OEMs to ship it and not someone else's. That is
where the rumor about Windows 386 being "written" for certain vendors comes
from. The fact that memory managers often needed to be tweaked for some
hardware added to the confusion. That's where the "Compaq" part of the myth
comes from.
However, the myth often skips the fact that about this same time Ms was in
league with IBM in creating OS/2. I can assure you no part of OS/2 was
written in Pascal. However, along with explanations of the Presentation
Manager in the various publications at the time (byte, Dr. Dobbs, ...) you
will also find programs written in Pascal to utilize this new environment.
Why? Turbo-Pascal was the most popular programming tool around at the time.
While naturally incorporating similar memory management and multi-tasking
abilities found in Windows 286/386, later Windows were a different very
expanded product. I guess that is where the myth that Window was
're-written' comes from.
As for why the "Pascal" convention, (there have been and still are various
different conventions that a C compiler can employ. _pascal was also know
as _fortran), became the "standard windows" convention, is based merely on
the nature of the convention itself and the unsuitability of _cdecl for
managing shared libraries (dynamically linked). It has nothing to do with
the Pascal language.
The major feature of the _pascal (_fortran) convention is that it requires
the caller to setup a stack frame before calling the function and to
dismantle it afterwards. When the compiler compiled a Windows application it
inserted a prolog and epilog to this stack framing. These segments contained
nop instructions. At runtime Windows then used these 'empty' instructions to
insert mappings to the dlls from the application's address space.
(thunking). You can't use _cdecl in this case, because with it the callee
controlled the stack and if you fiddled with the address space of a shared
component during runtime - copy on write would create multiple different
instances of paragraphs and segments of the library - a couple of extra ones
for each application using its services, and what would be the point in
that?
While, how all that "thunking" is done did changed with the migration to
32-bit, the _pascal convention was not kept to be backward-compatible - it
was kept because it is still needed to managed shared libraries. There are
other issues as well, but this is the main one.
I suppose Ms could have come up with their own unique directive, but it is
important to note, that _pascal, __pascal, PASCAL, _Pascal, etc. were
already a commonly known directive and supported by all mainstream C
compilers. (Many compilers that also supported _fortran treated the case of
the exported names somewhat differently - most supported _pascal very
consistently across the board) Ms would have annoyed quite a few software
vendors and independent programmers if they would suddenly have required
everyone to add a new define to their code or require a Ms compiler. Of
course now most compilers do support "windows extensions" and it is a mute
point.
hope this helps to clear up the myth.
-ralph