Re: Seeing VERSIONINFO under Vista?

See below...
On Sun, 27 May 2007 20:34:08 -0700, "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote:

4GB file limit was because FAT16 could only handle that much (actually up to
2GB partition?). Therefore, it didn't make business sense to convert VFAT to
64 file pointer. At that time, maximum consumer disk drive was around 1 GB.
I bought one gig in 1995 (WD) for 300. Though capacities were growing fast,
thus FAT32 was introduced.
*****
What made no sense was retaining FAT16. Drive-spanning software already existed and you
could build virtual drives out of physical drives rather easily in MS-DOS, and it was also
available for Win9x.
*****

GDI/USER were pretty much reused from Win3.1, although expanded a little bit
with TextOutW and a few other unicode-aware text functions. All that was
connected through a great kludge of thunks. I don't remember if Win95
required FPU, probably not. NT GDI was using FP coordinate translation code,
and it was much bigger that Windows 3.1.
****
GDI did not use floating point coordinates; it still doesn't, except when transformation
matrices are used. Otherwise it uses integer values everywhere, but they are 32-bit
values. The minimum machine for running Win95 was a 386DX machine, which had an
integrated FPU.
****

As said, it's possible to make a candy from ***, but it will be a candy
made of ***. Win95 was the right solution to fill the gap. But it was a
candy made of ***. As much as IBM PC.
****
Part of the problem people have with the Intel architecture deals with segment registers.
I worked with the x86 family in MSDOS and Win16 for over a decade, and the only reason I
had to worry about segment registers was that I did a lot of close-to-the-hardware
programming like interrupt systems and device drivers; users never saw them under most
conditions. As I would tell people "It is a C execution engine. The compiler handles the
details of segment registers". For others it might be a Pascal execution engine, or a
Delphi execution engine, or a VB execution engine, or a FORTRAN execution engine, but thse
all hid the segmentation. So other than this trivial detail (and the Mac had segment
register problems on the 68000) what was wrong with the x86 chip family that was done so
much better by someone else? I remember handling interrupts on the Z80 and even the 6502,
and these chips had fascinating problems. It has been 20 years since I wrote interrupt
handlers on the 68000 but it had some interesting problems dealing with doing proper stack
switching to a kernel stack.

One thing I've learned is that details of the instruction set are largely irrelevant
details, details of the registers are largely irrelevant details, and details of pretty
much everything are largely irrelevant details, nearly all the time. I've worked close to
the hardware of more machines that I can remember, and EVERY ONE OF THEM had complete crap
at some point. The only machine I never really wrote device drivers for was the PowerPC
architecture, and after I read the hardware specs of this :"miraculously wonderful"
architecture I seriously wondered how *anyone* could have written a device driver for it
(for eample, the CPU had no real idea about the concept of "memory"; it only dealt with
the L2 cache. You don't really want to know how the PowerPC multiprocessor handled
mutexes, but it involved having very special hardware because you couldn;'t do ANYTHING
read-pause-write to MEMORY (I heard a talk on the first PowerPC multiprocessor. Ouch!)
Remember that the PowerPC was introduced in 1990 or 1991, approximately a decade after the
decision for what to use in the original IBM PC was made.

So what architecture, exactly, is so marvelously "perfect" that it should have been
chosen, in 1979, for the IBM PC? Please list all possible choices. Take into account the
stability of the company, its ability to supply parts, and whether or not the chips
actually worked. My recollection was that the only two credible players at that time were
Intel and Motorola. National Semiconductor had nothing that people really trusted, Zilog
had a barely-functional machine which had many known bugs (and used segment registers),
and most of the rest of the world was firmly rooted in 8-bit machines. AMD had the 2900
bit-slice architecture but it was not cost-effective.

Remember, this had to be an off-the-shelf chip (now we refer to these as COTS
(common-off-the-shelf) components). It had to be a chip that was being delivered, and
could be delivered in quantity by the vendor, with guaranteed reliability. National and
Zilog were still debugging their designs after release, and there was no known schedule
for when all the killer bugs might be solved.

The 8088 was the "low end" of the 16-bit 8086 family, with an 8-bit data bus. The 8-bit
data bus size mattered because it meant that only 8 memory chips were required, whereas a
16-bit memory bus would require 16 memory chips (assuming that like most chips of the day,
they were nKx1 chips); Chip count directly impacts system cost, more so in 1979 when
memory cost could dominate. But the daring choice of the IBM PC was to go for a 16-bit
processor model in a world that thought that 64K max memory on an 8-bit processor was
state-of-the-art in personal computing.

So what miraculous architecture was available?
joe
*****

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:trej531qneuiqf3rrmtltmgune1fvd8djr@xxxxxxxxxx

Under Win9x a 32-bit process uses 32-bit filehandling APIs that don't go
anywhere near the 16-bit code. 16-bit processes still call software
interrupt
21H to access the OS facilities, but the interrupt handlers are stubs that
forward to 32-bit code. There isn't really any of DOS doing anything.
****
And GDI coordinates were 16-bit; a listbox had a limit of 64K bytes of
resources to use
(including string storage space), all GDI resources were shared
system-wide, all USER
resources were shared system-wide, all kinds of controls had 16-bit limits
(e.g, a slider
control had a 16-bit range). I believe files had a 4GB limit because the
underlying file
system could not handle 64-bit file sizes (in other words, it was a
32-bit-size file
system, same as MS-DOS). This was because a lot of the original Win16
assembly code was
still being used.
\*****

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.