Interesting read about upcoming K9 processors

In comp.arch Yousuf Khan wrote:
kal wrote:
On Fri, 06 Aug 2004 16:46:51 GMT, "Yousuf Khan"
wrote:

as a result of some dufusy arbitrary decisions that MS made. For
example, they decided not support 16-bit protected mode apps in
Win64, even though the AMD64 architecture has no problems running
either 16-bit or 32-bit protected-mode apps in compatibility mode.

I am not sure this is accurate. The issue with win16 is that some of
it still depends on the DOS (for file system etc.) so it needs the
virtual x86 mode too which is not supported in AMD64. So it is really
a technical issue which may also have been solved but that's another
topic.

I don't think that's been the case since Windows 3.1. That's the version of
Windows that brought the "32-bit file system", which replaced all calls to
DOS and BIOS with protected mode Windows ones. Even if the app made a direct
call to DOS or BIOS, the 32-bit FS would handle the call.

It was slightly more complex given that you could have "16 bit disk drivers"
so the call might still make it back to some non-32bit gunk after the FS.


Yousuf Khan



--
Sander

+++ Out of cheese error +++

"Sander Vesik" wrote in message
...
I don't think that's been the case since Windows 3.1. That's the version
of
Windows that brought the "32-bit file system", which replaced all calls
to
DOS and BIOS with protected mode Windows ones. Even if the app made a
direct
call to DOS or BIOS, the 32-bit FS would handle the call.

It was slightly more complex given that you could have "16 bit disk
drivers"
so the call might still make it back to some non-32bit gunk after the FS.

I doubt that. Even if they were 16-bit disk drivers, they were *protected
mode* 16-bit disk drivers, so there was no need to transition through a
Virtual-8086 task gate.

The call to V86 was the real killer of performance. An OS call would result
in going to Ring 0 protected mode kernel and drivers, but then that driver
would really be a wrapper of a DOS or BIOS function, and that would result
in executing code in Ring 3 with continuous back and forth monitoring by the
Ring 0 code.

Yousuf Khan

In comp.arch Douglas Siebert wrote:
(Patrick Schaaf) writes:

Casper H.S. Dik writes:

"Stephen Sprunk" writes:

AMD64 is just another platform, and the third (or higher) platform supported
is of marginal cost compared to the second. The free software world has had
to contend with dozens of platforms for over two decades, and so the fact
Linux (and all the common apps) ported over cleanly is hardly surprising.

It's not really all that simple: while you can run a pure 64 bit OS on
AMD64, there are many Linux applications only available as "32-bit, IA32"
binaries.

I don't see many of them on the ~1000 Linux systems I've got at work.
There are bound to be some commercial apps where that's the case,
but I'm sure Stephen was thinking about the ease for _open_source_software_
to be ported over.


Do the AMD64 versions of Redhat and SuSE recompile everything? It seems
kind to silly to have a 64 bit /bin/ls, for instance. They always left
most stuff for which performance didn't matter compiled as i386, and for
stuff where performance mattered (the kernel, openssl libraries, etc.)
there were i686 versions. I would assume it is the same way for AMD64
stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have
to do a lot more versions if they bugfix /bin/ls and have to compile a
64 bit version to go along with the i386 version!


It really depends on if AMD64 is being treated as an extension of
x86 or no. decising that no, you are just going to treat it as a
64 pltaform where the native ABI is x86-64 and that is what userland
uses by default is a valid decision. Especially if you dont plan on
running anything legacy.

--
Sander

+++ Out of cheese error +++

Sander Vesik wrote:
In comp.arch Yousuf Khan wrote:
The move from 16-bit to 32-bit Windows was doubly difficult, because
of the need to replace segment-based addressing with linear
addressing. That is not an issue with the 32-bit to 64-bit port. I
think people are justifiably disappointed in MS, because this one
should've been smooth as silk. Their kernel was ported quickly, but
nothing else is being ported quickly.

Umm... Note that WinNT was never 16 bit and that parts of code were
AFAICT always shared with Win9x.

The move from 16-bit to 32-bit Windows didn't happen with Windows NT, it
happened during the time of Windows 3.x. Windows 3.x was the bridge between
16-bit and 32-bit. The Windows 9X/ME series was a continuation of that
bridging system.

Windows NT was supposed to be what those operating systems bridged
themselves to. As it turned out, that is exactly what happened, but it
didn't happen right away. The bridging OSes survived for a long, long time,
and Windows NT evolved into Windows 2000 and finally XP, before the
transition was finally complete.

Yousuf Khan

On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan wrote:

The move from 16-bit to 32-bit Windows didn't happen with Windows NT,
it happened during the time of Windows 3.x. Windows 3.x was the
bridge between 16-bit and 32-bit. The Windows 9X/ME series was a
continuation of that bridging system.

I don't think that's strictly correct. My memory is that Windows 95
was itself the first Windows which supported 32-bit code, when it was
launched (in 1995 ;-) The immediately prior version of Windows was
3.11, which was 16-bit only (and ran on top of MS-DOS).

Microsoft was banking on most customers immediately switching to
Windows 95. However, a lot of people (including corporate customers)
did not do this, so demand for a way to run Win32 programs under
Windows 3.1x built, and Microsoft quite quickly brought out the
Win32s API (which thunks the 32-bit calls to 16-bit ones).

Windows NT was supposed to be what those operating systems bridged
themselves to. As it turned out, that is exactly what happened, but
it didn't happen right away. The bridging OSes survived for a long,
long time, and Windows NT evolved into Windows 2000 and finally XP,
before the transition was finally complete.

I think that's about right, but greatly shortens a very long and
convoluted story. Apparently the NT project actually began in the
late 1980s, and the theme of the ensuing saga seems to be that
Microsoft were permanently struggling to find a place for NT in
their marketing strategies (and failing, until XP).

However, my comments are of a punter, and not vaguely authoritative.

--
Nick Roberts

"Nick Roberts" wrote in message
newspscxkxrx5p4pfvb@bram-2...
On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan wrote:

I don't think that's strictly correct. My memory is that Windows 95
was itself the first Windows which supported 32-bit code, when it was
launched (in 1995 ;-) The immediately prior version of Windows was
3.11, which was 16-bit only (and ran on top of MS-DOS).

Microsoft was banking on most customers immediately switching to
Windows 95. However, a lot of people (including corporate customers)
did not do this, so demand for a way to run Win32 programs under
Windows 3.1x built, and Microsoft quite quickly brought out the
Win32s API (which thunks the 32-bit calls to 16-bit ones).

I seem to recall that Win32S was made available prior to Win95, but I may be
mistaken. It seemed to be a 'transition' tool so that developers could
start writing '32 bit' code that would run under Win95 when it arrived (and
perhaps WinNT).


I think that's about right, but greatly shortens a very long and
convoluted story. Apparently the NT project actually began in the
late 1980s, and the theme of the ensuing saga seems to be that
Microsoft were permanently struggling to find a place for NT in
their marketing strategies (and failing, until XP).

I seem to recall that the WinNT effort followed the failed OS/2 partnership
with IBM. I think it was specifically meant to replace OS/2 1.1 (or 1.2,
whichever was the last MS release). This brings me back to my original
assertion - WinNT was not written to be portable, nor to be upgradable. It
was written to be 32-bit. I find it difficult to believe that in their
haste to come out with WinNT that the MS developers took into consideration
the chance that they might have to run on different platforms. If there
was one code base, I think there would not be the 'problem' of supporting
multiple platforms. Consider DB2, which *was* written with portability in
mind. It took several weeks (or perhaps several days) to port it to x86-64,
and it runs on virtually every platform imaginable specifically because of
this.


However, my comments are of a punter, and not vaguely authoritative.

Ditto...

Regards,
Dean



--
Nick Roberts

Dean Kent wrote:

I think that's about right, but greatly shortens a very long and
convoluted story. Apparently the NT project actually began in the
late 1980s, and the theme of the ensuing saga seems to be that
Microsoft were permanently struggling to find a place for NT in
their marketing strategies (and failing, until XP).

I seem to recall that the WinNT effort followed the failed OS/2 partnership
with IBM. I think it was specifically meant to replace OS/2 1.1 (or 1.2,
whichever was the last MS release). This brings me back to my original
assertion - WinNT was not written to be portable, nor to be upgradable. It
was written to be 32-bit. I find it difficult to believe that in their
haste to come out with WinNT that the MS developers took into consideration
the chance that they might have to run on different platforms.

WinNT did in fact run on four different Platforms:
i386, MIPS, PowerPC and Alpha. (all 32-bit little-endian, though)

Regards,

Florian

Dean Kent wrote:
"Nick Roberts" wrote in message
newspscxkxrx5p4pfvb@bram-2...

On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan wrote:

I don't think that's strictly correct. My memory is that Windows 95
was itself the first Windows which supported 32-bit code, when it was
launched (in 1995 ;-) The immediately prior version of Windows was
3.11, which was 16-bit only (and ran on top of MS-DOS).

Microsoft was banking on most customers immediately switching to
Windows 95. However, a lot of people (including corporate customers)
did not do this, so demand for a way to run Win32 programs under
Windows 3.1x built, and Microsoft quite quickly brought out the
Win32s API (which thunks the 32-bit calls to 16-bit ones).


I seem to recall that Win32S was made available prior to Win95, but I may be
mistaken. It seemed to be a 'transition' tool so that developers could
start writing '32 bit' code that would run under Win95 when it arrived (and
perhaps WinNT).

I have a slightly different recollection of Win32S.

When Win95 came out, MicroSoft told developers that if they
wanted to put the Windows logo on their packaging or to
call their software Windows compatible, then it had to be
able to run on all three platforms: 3.x, 95, and NT.
Win32S was more or less a thunking layer that let 32 bit
code made for 95 and NT run on the 16 bit Windows 3.x.

I think that's about right, but greatly shortens a very long and
convoluted story. Apparently the NT project actually began in the
late 1980s, and the theme of the ensuing saga seems to be that
Microsoft were permanently struggling to find a place for NT in
their marketing strategies (and failing, until XP).

Personally I thought W2K was a roaring success for MicroSoft.


I seem to recall that the WinNT effort followed the failed OS/2 partnership
with IBM.

In some ways it is the *cause* of that failed partnership.
MicroSoft made no secret of the fact that they were
*simultaneously* working on NT and OS/2 - which led to
a lot of acrimony between IBM and MS. IBM resented
that MS was diverting resources from the OS/2 project,
and IBM also did what they could to prevent MS from using
OS/2 ideas/techniques/code/etc in the development of NT.

Some of the many long delays for OS/2 were attributed to
the fact that the IBMers did not want to share any more
code than they had to with MS - for fear that MS would
abuse their relationship with IBM and use that code for
NT. This meant that often the MS developers working on
OS/2 were kept in the dark about things they needed to know.


As well, I have heard another side of the story about MS
"rushing" to beat OS/2. Seems that perhaps it was not
so much that MS was rushing, but that IBM was doing too
much foot dragging - which is one of the things that caused
MS to start their NT project. Apparently IBM was aiming
for cross-platform perfection while MS wanted to settle for
a "good enough" x86 version, put the OS on the market, and
start recovering some of those development costs. MicroSoft's
pockets weren't nearly as deep back then as they are today -
they were deeply in the hole over OS/2 and badly needed to start
seeing revenue from the investment they had made.

I think it was specifically meant to replace OS/2 1.1 (or 1.2,
whichever was the last MS release). This brings me back to my original
assertion - WinNT was not written to be portable, nor to be upgradable. It
was written to be 32-bit. I find it difficult to believe that in their
haste to come out with WinNT that the MS developers took into consideration
the chance that they might have to run on different platforms. If there
was one code base, I think there would not be the 'problem' of supporting
multiple platforms. Consider DB2, which *was* written with portability in
mind. It took several weeks (or perhaps several days) to port it to x86-64,
and it runs on virtually every platform imaginable specifically because of
this.


However, my comments are of a punter, and not vaguely authoritative.

Mine aren't any more authorative. I was a programer back
in those days and IBM and MS were stabbing each other in
the back as they tried to lure programmers towards developing
for either OS/2 or NT. Each side spread a lot of nasty
rumours about the other side and it was pretty hard to find
a few nuggets of truth in all of that sh*t.

Nick Roberts wrote:
On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan wrote:

The move from 16-bit to 32-bit Windows didn't happen with Windows NT,
it happened during the time of Windows 3.x. Windows 3.x was the
bridge between 16-bit and 32-bit. The Windows 9X/ME series was a
continuation of that bridging system.

I don't think that's strictly correct. My memory is that Windows 95
was itself the first Windows which supported 32-bit code, when it was
launched (in 1995 ;-) The immediately prior version of Windows was
3.11, which was 16-bit only (and ran on top of MS-DOS).

Microsoft was banking on most customers immediately switching to
Windows 95. However, a lot of people (including corporate customers)
did not do this, so demand for a way to run Win32 programs under
Windows 3.1x built, and Microsoft quite quickly brought out the
Win32s API (which thunks the 32-bit calls to 16-bit ones).

No, Win32S was available long before Windows 95 ever came out (remember
Windows 95 itself was greatly delayed). It sort of served as a "preview" of
the functionality to come with Windows 95 and beyond. Not that Win32S was an
API greatly used to during its time, but it was there nonetheless. It
allowed programs to use more than 16MB of memory (i.e. the limit of 16-bit
286 Protected Mode).

Also even ignoring the Win32S API, Windows 3.1 and beyond itself had quite a
few 32-bit drivers, such as the filesystem and the disksystem. There was a
combination of 16-bit and 32-bit protected mode drivers running under
Windows 3.x already. Plus the Windows 3.x kernel itself was 32-bit in
Enhanced Mode (remember that Standard Mode vs. Enhanced Mode stuff that used
to exist back then?). In Enhanced mode, it was able make use of paging and
Virtual-8086 mode for multitasking DOS programs underneath it; both of these
Enhanced Mode features required that the OS be designed for the 386 or later
processors, it wouldn't work on earlier non-32-bit processors.

Yousuf Khan

Dean Kent wrote:
I seem to recall that Win32S was made available prior to Win95, but I
may be mistaken. It seemed to be a 'transition' tool so that
developers could start writing '32 bit' code that would run under
Win95 when it arrived (and perhaps WinNT).

Yup.

I seem to recall that the WinNT effort followed the failed OS/2
partnership with IBM. I think it was specifically meant to replace
OS/2 1.1 (or 1.2, whichever was the last MS release). This brings me
back to my original assertion - WinNT was not written to be portable,
nor to be upgradable. It was written to be 32-bit. I find it
difficult to believe that in their haste to come out with WinNT that
the MS developers took into consideration the chance that they might
have to run on different platforms.

Actually, I think it was meant to be the next generation of VMS. Remember it
was Dave Cutler who spearheaded this project after coming over from DEC to
Microsoft. At DEC he spearheaded VMS, and at Microsoft he wanted to do it
one better.

The "one better" in this case meant that he wanted NT to be more portable
than VMS was at the time (it was originally just a VAX OS, then at great
effort it was ported to become an Alpha OS, now it's been ported to
Itanium).

And yes, Microsoft's own goal was to make NT one better than OS/2 too. So
each conspirator (Cutler & Microsoft) had their own goal posts in mind.

Yousuf Khan