Re: Native Code vs PCode OT

So was that a 'yes' or a 'no' Ralph? :-))

Tony Proctor

"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:tPidnRuJRqGGR4DeRVn-uQ@xxxxxxxxxxxxxxx
>
> "Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
> news:u5QSe.6361$Wd7.344@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Not 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
> > some 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.
> >
> > "Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
> > news:TPWdncIXmbyc7obeRVn-2w@xxxxxxxxxxxxxxx
> > >
> > > "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> > message
> > > news:O9Nq$eXsFHA.2520@xxxxxxxxxxxxxxxxxxxxxxx
> > > > Actually Ralph, some of worst misconceptions and unjustified
diatribes
> > > about
> > > > VB 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
> > > > real 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>
> > >
> > > It 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
>
>
>


.

Relevant Pages

  • Re: hmm..interesting
    ... you've got a discussion of ARM vs Intel architecture here: ... And ARM is rapidly running away from RISC. ... mainstream (many netbooks and smartphones run Linux instead of Windows ... And hardly any C compiler does. ...
    (comp.sys.acorn.hardware)
  • Re: Native Code vs PCode OT
    ... Windows 1.0 was written in Pascal. ... >> a decent C compiler but did have one of the best rated Pascal compilers. ... > It is a myth. ... The fact that memory managers often needed to be tweaked for some ...
    (microsoft.public.vb.general.discussion)
  • Re: Stalin ported to Windows.
    ... Therefore, the compiler ... Stalin from Scheme sources; it took six hours to generate the C ...   Junia and Reane  got a working Windows port from the C ...
    (comp.lang.scheme)
  • Re: hmm..interesting
    ... work out at more power per Watt than x86. ... mainstream (many netbooks and smartphones run Linux instead of Windows ... the fact that Visual Studio allows you to get away with fairly sloppy ... difficult to find a C compiler that *doesn't* have vendor-specific ...
    (comp.sys.acorn.hardware)
  • Re: C++ programming migration from DOS to Windows
    ... compiler, so the current compiler is quite competitive WRT to ... There are a couple of ports of gcc to Windows. ... Comeau is more or less unique: the best language conformance you can ... IDEs: Microsoft and Borland have both produced decent IDEs in the past, ...
    (comp.lang.cpp)
Loading