Re: Don Phillipson - where are you? Why don't you respond? (Win98 is built atop MS-DOS)
Re: Don Phillipson - where are you? Why don't you respond? (Win98 is built atop MS-DOS)
MEB wrote:
| "PCR" <pcrrcp@netzero.net> wrote in message
| news:u5UGy7h$HHA.464@TK2MSFTNGP02.phx.gbl...
|| Bill in Co. wrote:
|| | So what's the upshot of all of this? That it is incorrect to say
|| | that Win98 is "built on top of DOS"? Or that it is only
|| | partially correct (and ONLY for some backwards compatibility
|| | applications)? Or is not even true, at all?
||
|| | Or can we say that Win98 is its own operating system that can run
|| | without any DOS program code whatsoever (as long as one doesn't try
|| | to run some older app?)
||
|| Whether Win98 is "built on top of DOS" depends upon whether Win98 to
|| some important degree needs Real DOS code to function &/or whether
|| Real DOS code has been incorporated into Win98 code. If either of
|| those is true, then Win98 is built upon DOS-- because it uses DOS to
|| do the things it does. I assign you &/or Phillipson to pore through
|| Win98's two million lines of code for the evidence! I think you will
|| not find it!
||
|| I believe Real DOS is loaded & may remain functional even after
|| Win98 is loaded. Then, if some TSR (Terminate & Stay Resident
|| application) needs to use it, it can. However, that only would prove
|| Win98 is DOS-tolerant!
|
| Cute, seems semantics are again being used in a discussion, why
| doesn't this surprise me.
That isn't semantics. It's asking whether Windows does things with new
code or with code that is now or once was Real DOS code-- & outside of
Windows DOS (in a box), which obviously is much the same as True DOS.
I've flipped in my leanings on the issue. I'm leaning toward your side,
now, MEB, that Windows, itself, makes use of what is or was once DOS
code to run (not just to load). But where is the proof?
| DOS - disk operating system
|
| MSDOS - Microsoft's disk operating system
|
| Windows - GUI aspects designed around Microsoft's disk operating
| system
|
| Evidence of MSDOS - windows\command\xcopy.exe and xcopy32.exe - both
| are stubs calling the same xcopy32.mod - Explorer handles xcopy
| within the GUI.
The Windows GUI (Graphical User Interface) includes the ability to run
Windows DOS (in a box)-- which is DOS 7.10 in Win98. Although I do
believe DOS 7.10 is obviously built upon the lower DOS versions-- I'm
ruling that out as proof that Windows, itself, is built upon DOS. It
only proves Windows can provide DOS. Therefore, I am ruling out that
XCopy32.exe & XCopy.exe are proof that Windows is "built on top of DOS".
What I need to know is... When a file is copied, for instance, in
Windows (but outside a DOS box)-- is a call made to DOS code to do the
work? Or, was DOS code copied to an important degree into Windows code
to do it? Only if Windows does such things with importantly original
lines of code can it be said Windows is NOT "built upon DOS".
NOW, I have found another page/two to quote from "Windows 98 Secrets"
(Livingston & Straub). Here are bits of pages 1053 & 1054...!...
"DOS lives on as a vestige -- still useful, but only a small part of
Windows 95 and 98. In this chapter, we first look at DOS as that thing
that starts up before Windows 98 takes command."
"Andrew Schulman argued in his book, 'Unauthorized Windows 95', that
with the advent of Windows/386 2.x in 1988, Windows became a real
operating system. Windows is an operating system because it handles the
requests that programs make of the computer. When necessary, it hands
those requests to DOS to let it do some of the work. Since the advent of
Windows for Workgroups 3.11, and especially the 32-bit file access that
came with it, DOS has handled even less of the grunt work to do."
"Schulman states early in his book:
'If I had to explain how Windows 95 relates to DOS in 25
words or less, I'd say this: Windows 95 relates to DOS in
the same that WFW 3.11 does. Windows provides 32BFA
[32-bit file access]. For non-file calls, it calls (in V86 mode)
the real-mode DOS code in Winboot.sys [called IO.sys since
the released version of Windows 95]. Windows 95 is a
genuine operating system; so were WFD 3.1, Windows 3.1
Enhanced mode, and Windows 3.0 Enhanced mode.'"
Although it seems to be more than 25 words, it DOES confirm that Windows
DOES use DOS code (I believe those guys)-- which it says is IO.sys (at
least in part). SO... I do lean toward the belief that Windows is "built
on top" of DOS-- which is a flip-flop from my initial leaning!
But the answer STILL is a matter of how extensively Window's does use
DOS code-- whether of IO.sys or other DOS stuff, such as possibly the
thunking down to KRNL386.EXE that John John brought up. Does Windows do
these things only when confronted with a program that must be
DOS-complient-- or does Windows do it in its own normal workings? I
still don't know!
| Evidence of 32 protected mode MSDOS [MSDOS 7 and 8] - shown when
| Windows crashes and runs scandisk, then IMMEDIATELY loads Windows
| WITHOUT error. Were there no MSDOS running [in memory] the programs
| would have no command interpreter to use OR device and disk access.
| Moreover, only one version of scandisk would be needed if Windows was
| actually already running.
After a crash, there is a reboot before a DOS Scandisk is run.
Therefore, there was a chance for DOS to load again, which I believe it
did do. BUT -- yea -- that is true that DOS is still present after
Windows loads-- IO.sys does not go away. And Windows will use it on
occasion, except for file access. But, to what extent does Windows
continue to use Real DOS after it has loaded?
| Some claim IO.SYS defines the issue,
IO.sys is likely a big part of it! Probably, Command.com & other DOS
programs will link to DOS code in IO.sys. But how extensively will
Windows do that?
| clearly those people that do,
| fail to take under consideration the actual coding and history of
| Microsoft's products.
| So let's actually view the supposed important coding of IO.SYS
| {98SE} - [Rather than relying upon misinformation, guess what, you
| actually have the code available to look at. Why not do so. Don't
| make me post ALL 9X file coding to expose the DOS aspects.]
There will be complaints, if you do! I may lodge one, myself! I'm
snipping most of your dump of IO.sys...!...
....snip
| FAT12
| FAT16
| FAT32
FAT32! By cquirke's word, that will prove you've got the right version
of DOS in your machine, if IO.sys mentions FAT32. You have version
7.10...!...
........Quote cquirke..........
Post-Win95 MS-DOS versions are notional, given that DOS is no longer
marketed as a stand-alone product. However, they remain relevant in
that these are the versions returned to DOS version queries:
Win95, Win95 SP1 - DOS 7
Win95 SR2, Win98, Win98 SE - DOS 7.1
WinME - not really applicable, may be DOS 7.2 or 8 ?
The difference between (MS-)DOS 7 and 7.1 is that 7.1 includes support
for FAT32. As WinME has no native HD-based DOS mode, and as the
diskette DOS is functionally generally worse than Win98 SE, I've not
bothered much with it. Note that other software vendors have DOS 7
products that are unrelated to MS's DOS versioning; typically these
will be alterntives to MS-DOS 6.22 that lack LFN or FAT32 support.
.........EOQ.......................
....snip of more of the IO.sys dump...
| Insert diskette for drive
| and press any key when ready
I think that error message in IO.sys proves it does handle file access
for DOS programs still, though Livingston/Straub have sworn Windows
itself won't use it for that.
....snip of more of IO.sys...
| This version of Windows requires a 386 or better processor.
| A20 hardware error. Contact technical support to identify the
| problem. Starting Windows 98...
| Windows 98 is now starting your MS-DOS-based program.
| Windows 98 is now restarting...
| Press Esc now to cancel MS-DOS mode and restart Windows 98...$
Those messages inside IO.sys do appear to prove that IO.sys is present
after Windows starts-- because it is used by Windows to start an
"MS-DOS-based program". Also, IO.sys seems to be ready to accept a
Restart in MS-DOS Mode & will hand the computer back to Windows after an
EXIT from that.
| There is an unrecognized command in your CONFIG.SYS file.
| The following command in your CONFIG.SYS file is incorrect:
That proves it is IO.sys that processes Config.sys. I know it also will
process MSDOS.sys.
| The sector size specified in this file is too large: $
That settles it-- IO.sys does do file access for DOS!
....snip
| There is an invalid country code or code page in your CONFIG.SYS file.
| There is an error in the COUNTRY command in your CONFIG.SYS file.
IO.sys does process Autoexec.bat too, during a normal boot, if it does
exist.
| Windows will prompt you to confirm each startup command.
....snip of a bit more...
| Process the system registry [Enter=Y,Esc=N]?$
That shows it is IO.sys that does the "interactive boot" from the
Startup Menu, & that it is involved with the Registry when a full boot
to Windows is done.
| Create a startup log file (BOOTLOG.TXT) [Enter=Y,Esc=N]?$
And IO.sys determines whether Bootlog.txt will be written, when this is
chosen from the Startup Menu or during an interactive boot.
| Normal
| Logged (\BOOTLOG.TXT)
| Safe mode
| Safe mode with network support
| Step-by-step confirmation
| Command prompt only
| Safe mode command prompt only
| Previous version of MS-DOS
Ah! There are the possible items of the Startup Menu! I know I don't get
the last one on that list, & I'm fairly sure I don't get the "network
support" offering, either.
....snip of more of IO.sys....
| Enter your choice:
| Windows cannot determine what configuration your computer is in.
| Select one of the following:
| Original Configuration
| Undocked
I wonder what that is about! Glad I've never seen it happen!
....snip of more of IO.sys.....
| Software\Microsoft\Windows\CurrentVersion
| Software\Microsoft\Windows\CurrentVersion\Setup
| System\CurrentControlSet\Control\WinBoot
| System\CurrentControlSet\Control\FileSystem
| Software\Microsoft\Windows\CurrentVersion\Network\Real Mode Net
| Software\Microsoft\Windows\CurrentVersion\Network
| SystemRoot
Those appear to be Registry keys that IO.sys will get involved with.
....snip of more of it...
| Software\Microsoft\Windows\CurrentVersion\RunOnce
There's another Registry key!
....snip of more of IO.sys, including a few more Registry keys...
|
| From the above we can glean that IO.SYS first checks and sets a
| number of potential variables including the registry. then
| command.com IS used prior to win.com.
I agree. It sets up DOS, itself -- it may BE DOS to a large extent--, &
it preps the Registry, if a boot to Windows is opted. Yep.
| Moreover, we also see that a
| number of other DOS functions are called and USED prior to starting
| the GUI called *Windows*. Only AFTER all base DOS aspects are called
| and used, is authority passed to the GUI environment which win.com
| then starts loading..
That is true. But, once loaded, to what extent will IO.sys or DOS still
be used by Windows itself?
| win.com contains:
That's what starts Windows.
| WININIT.EXE
| WININIT.INI
| COMMAND.COM
| DOSSTART.BAT
| win.com
| PATHsystem\vmm32.vxd
| windir=
| SMARTDRV.EXE
| FUTURE DOMAIN CORP. (C) 1986-1990 1800-V2USER.DAT
| SYSTEM.DAT
| . . .
| -----------
| Note the first command.com called by IO.SYS is in the root, then the
| Windows folder version is used. win.com uses the Windows folder
| version. Those familiar with DOS will recognize the distinctively
| visual display of the old *shell*like command formerly used in
| config.sys to assign alternate or primary command.com and variables
| in IO.SYS. Those familiar with DOS will also recognize the FCBS, and
| other aspects called/assigned within IO.SYS, which would previously
| have been included within config.sys or autoexec.bat. However, we
| also see that IO.SYS takes in to consideration the presence of
| config.sys and autoexec.bat, and some other potential files that
| might indicate what needs run or otherwise consulted.
Config.sys & Autoexec.bat are part of DOS, & they are processed by
IO.sys & can alter the default DOS environment that IO.sys sets up.
Command.com is a non-graphical interface to DOS that probably relies to
a large extent on code in IO.sys. Also, the DOS commands in
C:\Windows\Command are DOS & may themselves rely on some of the code in
IO.sys as well as supply some of their own.
All of what you have shown does indeed prove DOS is used to load & even
prep Windows. Also, Windows will run DOS in a box. The book I've quoted
even states that Windows will hand "requests that programs make of the
computer (when necessary) to DOS to let it do some of the work".
I think we are close to proving that Windows is "built upon DOS". I'm
just not sure whether Windows itself must do that, for instance in
Explorer-- or whether it basically only will do it when some 3rd party
application or pre-Windows application requires it to be done. But, at
this point, especially with the additional point John John brought up--
off hand, I'm more willing to agree with you, Phillipson & Colorado now,
that Windows is "built upon DOS".
| Reviewing bootlog.txt indicates essential elements:
....snip of quote of Bootlog.txt....
| Here the display shows the first DOS aspects, then necessary virtual
| memory [vmm]
| environment setup, then *drivers* being setup within the virtual
| environment for the OS PRIOR to the actual GUI OS.
That's right. And DOS is still there, even after Windows is fully
loaded.
| Windows 9X IS built upon DOS.
I lean that way, but do not believe it is proven in Bootlog.txt. It is
certainly proven that DOS loads Windows & that DOS still is there after
Windows is loaded. Zabcar showed that last point much earlier!
| Moreover, though the original meaning
| was "disk operating system" today it should be referred to as *device
| operating system*, we've come a long way from $10.000 10 meg hard
| drives and the PC speaker for sound..
DOS, of course, always could handle the keyboard & probably the printer
& video display. And DOS apps, sure, were added to handle other devices.
| First MS GUI - DOS Shell - enhanced by Microsoft with the
| acquisitions of various other companies and eventually implementing
| those codings into Windows 95. Some of that former third party
| programming coding contains 16 and/or 32bit native non-Microsoft DOS
| code {and GUI enhancements - like Software Tool Works [found in
| Windows 3.1 and 3.11] and other GUI programs which worked IN and ON
| plain DOS or MSDOS]. MSDOS also steals, er, modifies coding [check
| some of the earliest court matters regarding Microsoft/Bill Gates]
| segments from UNIX INCLUDING aspects of disk operation, and, IBM chip
| access routines. {You may find some of that interesting as Bill
| thought that code was or should be "public" in contrast with
| Microsoft's present attitude.}
|
| Does this indicate Windows is based upon DOS, built on top of DOS,
| or any other claim one wishes to make therein related - YES. Windows
| history and coding DOES contain MSDOS [and other disk operating
| systems] in 8, 16 and 32 bit, and several hundred other acquisitions
| by Microsoft which also implemented both 8, 16, and 32bit DOS coding.
It does seem sensible that the coding that is DOS would be copied to
Windows coding, if it could still work there. Why re-invent the wheel?
| Windows *claim to fame* is its graphical interface to DOS
| {disk/device operating system} activities. Does changing device
| control from the old DOS direct chip access to its present form make
| 9X non-DOS? Hardly, massive amounts of coding are supplying those
| same functions. The GUI enables more graphic aspects related to those
| DOS functions. When you right click CUT and then PASTE, is that
| different than MOVE. When you open Explorer and click a directory,
| how is that different than typing DIR /p. The difference lay in THE
| DISPLAY, the GUI, and the extra inclusions when that DIR is performed
| like also displaying attributes [attrib]. If you used the old DOS
| SHELL, some of those same functions were found there. If you used one
| of the old DOS or FILE managers, many of those functions were found
| there as well.
That sounds sensible to me, but an examination of the actual lines of
code is warranted.
| Does this also mean 9X Windows is its own unique environment - Yes
| and NO. Though MSDOS was no longer [supposedly] the primary STARTING
| code [though actually it is, just look at the code], the basic coding
| within the now GUI environment finds its roots in MSDOS. It does NOT
| matter that VXDs, and other aspects now handle the formerly real DOS
| {8bit and 16bit} aspects within the GUI, they are merely placed
| within a different memory environment and handled somewhat
| differently within that operating environment. Microsoft sales
| gimmicks [and many of its KBs] were [are] always designed around
| making people believe its products are entirely new and unique, which
| is generally sufficient to cause the uninformed to purchase them [and
| courts and the Patent Office to scratch their heads].
I can't deny none of that ever happens. MS, like Commodore before them,
always will want to sell "new" stuff. I think I can agree with that, & I
did resist Commodore beyond the Amiga 1000 (I think-- or was it the
3000?). I WAS just about to go higher-- when suddenly they were gone!
| Windows uniqueness is the manner in which this disk and device
| activity is accomplished, and the fact that its cost was
| comparatively cheap for a commercially produced product.. However,
| here some aspects were also *borrowed* from other operating systems,
| including SUN's. Again, one need merely review the early court cases
| against Microsoft/Bill Gates.
I guess, if you say so-- but I'm sure this is off-topic! Don't get me
assassinated!
| What matters is that the coding used therein {GUI Windows} [Delphi,
| C, FoxPro, Basic, VB, etc.], which does find its roots in that same
| code [assembly/chip calls] included within the chipsets and processor
| that was and is called and used by plain old real DOS regardless of
| whether it was Microsoft's or not [hence we find the venerable X86
| coding and/or support still continued within Intel chips and
| processors], and STILL necessary to be called and used, just in a
| different way. So does that make it new or something different than
| DOS, hahahah, no, its still using chip calls and coding. Windows ADDS
| [manipulates] basic chip functions/coding
I lean strongly to that belief now, yea, but I'm not sure to what
extent.
| Windows versions starting with 95 and NT began to implement virtual
| mode, which is the only really important enhancement [beyond the
| supposed enhanced disk access of NT]. This allows essentially
| fictitious environmental aspects within the system, evidenced for
| instance, by virtual memory which was previously handled via TSR
| versions using below 1024 and/or base 640 k memory. Increasing the
| memory addressing available, thereby increased the ability to run
| multiple programs, while still keeping essential system files active.
| Once again though, Microsoft was late to the game as much of this had
| already occurred using third party programs such as QEMM. Leaving us
| with just the GUI as Microsoft's *advanced feature*. But even there
| Microsoft was behind the game, Apple had already produced a much more
| workable, and user friendly GUI environment. Side by side Apple's GUI
| blasted Microsoft's. The problem: Apple's need for specific support,
| and lack of manufacturer compliance/support {Steve Jobs just couldn't
| get the same agreements rolling}.
|
| How did Microsoft garner more of the market - the key to Microsoft's
| early success was fomented by providing FREE access to the base code
| to programmers and beta testers, low cost versions, and commercial
| agreements made with chip producers.
| During the *early days* one needed to merely contact the Microsoft
| BBS and download any of its "new" code. Apple provided no such
| access, moreover, its code was chip specific. That left the *geeks*
| with only Microsoft's coding [until IBM opened their's], or their
| own, or Unix [which had already produced some of its children, such
| as Xenix, etc.] and a few other DOSs [such as CP/M].
| Some of those surpassed Microsoft's, such as:
| TSX operating system - multi task, network support /dos [Microsoft
| was still basically single task and little network support];
| or enhancement's such as;
| DOSNIX - provided many of the features which UNIX users took for
| granted along with some features not even found on UNIX systems,
| providing vastly superior tools.
|
| So, were it me, I would carefully think about what has actually
| occurred in the history of Microsoft before I would claim 9X is NOT
| MSDOS.
I lean this way now, MEB, yea. HOWEVER, I do disavow any matter above
that could lead to an assassination!
....snip
| --
| MEB
|
http://peoplescounsel.orgfree.com
| ________
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net