How to uninstall a dual configuration with Windows2000pro

[John John]

Re: Don Phillipson - where are you? Why don't you respond? (Win98is built atop MS-DOS)

> 98 Guy wrote:

> | Back in 1995, I bet that Micro$oft certainly believed that their
> | support phones would ring off the hook unless Windows 95 was
> | compatible with DOS applications, so in their mind yes, Windows 95
> | certainly needed to emulate some DOS function calls.

> PCR wrote:
> I believe that. In their effort to be compatible, how much of Real DOS
> has survived that is important to the functioning of Windows?

Windows 95 System programming SECRETS by MATT PIETREK
http://cs.mipt.ru/docs/comp/eng/os/win32/win95_sys_progr_secr/main.pdf

Big PDF, over 4MB. Read chapters 1 & 2 (about 80 pages). Don't worry,
you don't need to know anything about programming to read these 2
chapters. It will answer a few questions. I might add that the NT and
W9x Win32 API are *not* the same and that despite Microsoft's best
effort to make users believe otherwise, for certain functions
Kernel32.dll *does* thunk down to the 16-bit KRNL386.EXE! Reading these
chapters should put a few myths to rest.

John

 

[PCR]

Re: Don Phillipson - where are you? Why don't you respond? (Win98 is built atop MS-DOS)

John John wrote:
|> 98 Guy wrote:
|
|> | Back in 1995, I bet that Micro$oft certainly believed that their
|> | support phones would ring off the hook unless Windows 95 was
|> | compatible with DOS applications, so in their mind yes, Windows 95
|> | certainly needed to emulate some DOS function calls.
|
|> PCR wrote:
|> I believe that. In their effort to be compatible, how much of Real
|> DOS has survived that is important to the functioning of Windows?
|
| Windows 95 System programming SECRETS by MATT PIETREK
| http://cs.mipt.ru/docs/comp/eng/os/win32/win95_sys_progr_secr/main.pdf
|
| Big PDF, over 4MB. Read chapters 1 & 2 (about 80 pages). Don't
| worry, you don't need to know anything about programming to read
| these 2 chapters. It will answer a few questions. I might add that
| the NT and W9x Win32 API are *not* the same and that despite
| Microsoft's best effort to make users believe otherwise, for certain
| functions Kernel32.dll *does* thunk down to the 16-bit KRNL386.EXE!
| Reading these chapters should put a few myths to rest.

OK, thanks. I'm taking the download now. But I still have MEB's
mega-post to read! Seriously, are you saying that KRNL386.EXE is/uses
DOS, & that, if Windows thunks down to it often enough, then Windows can
be said to be "built upon DOS"? QuickView does reveal a plethora of
"functions" to be located inside KRNL386.EXE.

| John

--
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

 

[John John]

Re: Don Phillipson - where are you? Why don't you respond? (Win98is built atop MS-DOS)

PCR wrote:
> John John wrote:
> |> 98 Guy wrote:
> |
> |> | Back in 1995, I bet that Micro$oft certainly believed that their
> |> | support phones would ring off the hook unless Windows 95 was
> |> | compatible with DOS applications, so in their mind yes, Windows 95
> |> | certainly needed to emulate some DOS function calls.
> |
> |> PCR wrote:
> |> I believe that. In their effort to be compatible, how much of Real
> |> DOS has survived that is important to the functioning of Windows?
> |
> | Windows 95 System programming SECRETS by MATT PIETREK
> | http://cs.mipt.ru/docs/comp/eng/os/win32/win95_sys_progr_secr/main.pdf
> |
> | Big PDF, over 4MB. Read chapters 1 & 2 (about 80 pages). Don't
> | worry, you don't need to know anything about programming to read
> | these 2 chapters. It will answer a few questions. I might add that
> | the NT and W9x Win32 API are *not* the same and that despite
> | Microsoft's best effort to make users believe otherwise, for certain
> | functions Kernel32.dll *does* thunk down to the 16-bit KRNL386.EXE!
> | Reading these chapters should put a few myths to rest.
>
> OK, thanks. I'm taking the download now. But I still have MEB's
> mega-post to read! Seriously, are you saying that KRNL386.EXE is/uses
> DOS, & that, if Windows thunks down to it often enough, then Windows can
> be said to be "built upon DOS"? QuickView does reveal a plethora of
> "functions" to be located inside KRNL386.EXE.

I am not saying that Windows 9x is built directly upon or that it uses
DOS, but the links or roots are quite obvious. What I am saying is that
Windows 9x uses a lot of 16-bit components and that many of the 16-bit
functions bear close resemblance to their DOS counterparts, as shown by
Matt in his book, there are remnants of real mode DOS code that are
still being used in Windows 9x. Furthermore, Microsoft has always been
quite adamant about the 32-bit KERNEL32.DLL not thunking down to the
16-bit KRNL386.EXE. According to Microsoft (or according to the
marketing department at least) it didn't happen, however, as pointed out
by Matt, "Andrew Schulman proved conclusively in "Unauthorized Windows
95" that KERNEL32 does in fact call down to KRNL386.EXE."

Regards

John

 

[98 Guy]

Re: Don Phillipson - where are you? Why don't you respond? (Win98isbuilt atop MS-DOS)

John John wrote:

> > Seriously, are you saying that KRNL386.EXE is/uses DOS, & that,
> > if Windows thunks down to it often enough, then Windows can
> > be said to be "built upon DOS"? QuickView does reveal a
> > plethora of "functions" to be located inside KRNL386.EXE.
>
> I am not saying that Windows 9x is built directly upon or that
> it uses DOS, but the links or roots are quite obvious.

The roots are that Windows 1, 2, and Windows/286 were based on DOS, in
so far that they were either a GUI running as a layer above a lower
DOS layer, or simply a platform to run concurrent virtual DOS
machines. The reason being that most (or all) apps were still DOS
apps at the time.

In Windows 3.11, Windows could finally stop relying on DOS for file
system operations.

Windows 95 went further, with a 100% 32-bit, protected mode file and
disk management that did not even rely on the motherboard's BIOS for
disk I/O.

> What I am saying is that Windows 9x uses a lot of 16-bit components
> and that many of the 16-bit functions bear close resemblance to
> their DOS counterparts,

DOS has very few functions when compared to win-9x, so saying that
they have a "lot" of functions in common is idiotic.

If Win-9x has a lot of 16-bit functions, it's because of the need to
support older win/286/3.x software.

> there are remnants of real mode DOS code that are still being
> used in Windows 9x.

Used by the Kernel? Used by the VMM? Used by the API?

Or used by old legacy apps?

Big difference between those two groups.

In any case, if you want to say that Win-9x has some inherent 16-bit
functionality (Win16 code), I'll agree that it probably does (and I
bet that NT did too).

But I'll bet that that 16-bit code has absolutely no DOS history or
DOS equivalence. When Win-9x is running a DOS app, it creates a
virtual DOS environment complete with real DOS system files to service
the app.

Is Win-9x "derived from" Win-3.x? Yes.

Is Win-3.x "built atop" MS-DOS? Not an easy question to answer - it
depends greatly on what "x" is.

Is Win-9x "built atop", or derived, or based on MS-DOS? No, at least
not any more than NT 3.x/4 was.

 

[LACV]

Jeff, Philo, Dan

Thanks for your insights.
I never thought mu question will generate such a discussion, which by the
way was almost a lecture.

Jeff
Yes I set the drive up so I can dual boot, that is choose between W2k or
W98 at start up. Do you have any recommendation where to consult the
documentation for the boot manager to see what the uninstall process is?
Answering your other question, YES I installed W98 first and then added W2k
as a second, alternative system,(but by mistake as I was trying to update
from W98 to W2K).
And my last question, how do I know I have erased all the W2K files?
Perhaps it may be easier as you said, reinstall everyhting from zero.

Thanks in advanced


PCR, 98Guy, Bill in Co and MEB

Thanks a lot for the discussion, it was a very good lesson for me

 

[John John]

Re: Don Phillipson - where are you? Why don't you respond? (Win98isbuilt atop MS-DOS)

98 Guy wrote:

> Windows 95 went further, with a 100% 32-bit, protected mode file and
> disk management that did not even rely on the motherboard's BIOS for
> disk I/O.

Sheshhh. Read the frigging information from the guys who know more than
you. Matt Pietrek and Andrew Shulman are highly respected experts in
their fields, both have shown and proven conclusively that Windows 9x is
*NOT* a 100% 32-bit operating system. How can you be too thick to get
that in your head? How can you refute the Microsoft articles that I
pointed you to earlier? How can you refute the information in those
articles that clearly state that Windows 9x thunks down to 16-bit? How
can you refute that (as stated by Microsoft) even when running 32-bit
applications the User32 and GDI32 dll's and certain other functions
thunk down to 16-bit?

By continuing your uninformed argument on the subject you are not
arguing with me, I am simply posting information presented by computer
engineers, people who hold degrees in computer science and who are
experts in Windows operating systems. What you are saying in fact is
that the information presented by folks like Matt Pietrek and Andrew
Shulman is incorrect and that you know better than these guys.



> DOS has very few functions when compared to win-9x, so saying that
> they have a "lot" of functions in common is idiotic.

The only idiotic thing in this whole conversation is your insistence
that Windows 9x is a 100% 32-bit operating system that has no DOS code
in it. That has been conclusively proven to be false!



> If Win-9x has a lot of 16-bit functions, it's because of the need to
> support older win/286/3.x software.

First you say that Windows 9x is 100% 32-bit now you claim that it has
16-bit functions because it needs to support older software, make up
your mind!


>>there are remnants of real mode DOS code that are still being
>>used in Windows 9x.
>
>
> Used by the Kernel? Used by the VMM? Used by the API?

It's used by the Kernel and the API! Once again read the information
provided by those in the know.



> In any case, if you want to say that Win-9x has some inherent 16-bit
> functionality (Win16 code), I'll agree that it probably does (and I
> bet that NT did too).

Once again, you have absolutely no clue! If you want to argue about NT
architecture and DOS roots then take this discussion to one of the
active newsgroups that deal with that class of operating systems and
state your claim and information. If you take a few minutes and do a
search on "Dave Cutler"+N-ten you might get a clue as to where NT came
from and how it was designed. For your information, NT class operating
systems can also run 16-bit applications, providing that the
applications do not need direct access to the hardware. NT class
operating systems have a few 16-bit applications (not functions) on
board to permit 16-bit applications to run. NT operating systems *do
not* thunk down to 16-bit, it thunks 16-bit code *up* to 32-bit, NT is a
100% 32-bit operating system, Windows 9x isn't. But, once again,
instead of doing solid research you are simply trying to pass your
"notions" as fact!


> But I'll bet that that 16-bit code has absolutely no DOS history or
> DOS equivalence. When Win-9x is running a DOS app, it creates a
> virtual DOS environment complete with real DOS system files to service
> the app.

Again, more absolute bunk! Read chapters 1 and 2 from Matt's book. If
after reading the information provided by Matt you still wish to argue
you will have to state your credentials! Matt Pietrek is a respected
computer engineer with a proven record. Matt is currently employed by
Microsoft and continues to write about Windows operating systems on his
MSDN blog space.

Under The Hood - Matt Pietrek
http://blogs.msdn.com/matt_pietrek/

http://en.wikipedia.org/wiki/Matt_Pietrek


> Is Win-9x "built atop", or derived, or based on MS-DOS? No, at least
> not any more than NT 3.x/4 was.

Again, more silliness! Trying skirt facts by diverting the discussion
towards NT shows an incredible lack of knowledge on your part between
these two classes of operating systems. Quite frankly the only thing
that comes to mind now is that you are the kind who would deny the
"Elephant in the Room"!

John

 

[98 Guy]

Re: Don Phillipson - where are you? Why don't you respond? (Win98 isbuilt atop MS-DOS)

John John wrote:

> How can you refute the information in those articles that
> clearly state that Windows 9x thunks down to 16-bit?

You spawn a 16-bit thread when you thunk to 16-bits when you call a
16-bit function. The entire OS does not "thunk down".

> even when running 32-bit applications the User32 and GDI32 dll's
> and certain other functions thunk down to 16-bit?

Thunking happens when a 16-bit function is called. If no 16-bit
functions are called, then no thunking happens.

> > DOS has very few functions when compared to win-9x, so saying
> > that they have a "lot" of functions in common is idiotic.
>
> The only idiotic thing in this whole conversation is your
> insistence that Windows 9x is a 100% 32-bit operating system
> that has no DOS code in it.

In my previous comment, I said that Win-9x had completely replaced all
disk I/O and file management routines with 32-bit equivalent that
didn't even rely on the motherboard BIOS.

Win-9x has DOS code just like NT, 2k, XP and Vista has "DOS code" for
backward compatibility. If by DOS-code you mean the ability to
provide DOS function-call services that is. Since DOS has no GUI or
(significant) API, you can't say that the Win-9x Kernel or GUI or API
borrowed any code from DOS beyond what it needed to provide the
ability to run DOS code.

> NT operating systems *do not* thunk down to 16-bit, it thunks
> 16-bit code *up* to 32-bit, NT is a 100% 32-bit operating system,
> Windows 9x isn't.

How many functions in the Win-9x API and GDI are exclusively (only)
16-bit (ie no 32-bit counterpart)???

The fact that win-9x can thunk in both directions (while NT can't)
doesn't prove anything (certainly not the question - is Win-9x
DOS-based).

This same thread was hashed out in comp.os.linux.advocacy back in
1998. The crux of the argument:

--------------
The subject is "Windows95 is DOS based. MS says so!". To me "DOS
based" means "Windows 95 needs parts of DOS, so parts of DOS are still
part of the product". Others may have different definitions.

I had asked for details of what parts of DOS were used, and I
complained that no one had posted any facts on that subject. The reply
came back that it used GetPSP and the date functions. I then replied
that if all that was left of DOS was GetPSP, then it was a real
stretch to say that the difference between Windows 95 and Windows 3.1
is just a matter of degree. Next, someone replied that all Windows 95
programs have a PSP. A reply to that was "how do these programs run on
NT?" You then asked, "what does this have to do with anything?"

What it means is that "these programs" may be given a "DOS PSP" by
Windows 95, but they don't use it. If they used it, the wouldn't run
on Windows NT (which does not give out DOS PSPs?) or under Linux
(which I assume does not give out DOS PSPs).

The fact that some modern programs don't use PSPs suggests that
Windows 95 doesn't need PSPs for those programs. To the extent that
there are few programs which need PSPs, then Windows 95 must be
playing with PSPs either for itself or for some other programs.

I believe the truth is the latter. The PSPs are there for
compatibility with DOS programs and some 16-bit Windows 3.x programs.
Windows 95 only "uses" them to set them up for the programs which
"need" them.

This would not make Windows 95 "DOS based".
---------------------

There was talk about a court case between Caldera and Microsoft, the
issue being was win-95 based on DOS. Supposedly Caldera was going to
disclose how much "DOS" was used by Win-95. Anyone got any info about
that case? Supposedly, Micro$oft somehow tied Windows (9x?) to DOS,
hence the Caldera DR-DOS law suit:

-----------------
Caldera claims to have a small 600 byte TSR that sits on DR DOS and
allows Win95 to run on top of DR DOS and it also monitors the DOS
calls Win95 makes as it runs. A second claim is that Win95 runs
faster (not much) on DR DOS than on MS DOS 7.0. They are suing over
their inability to offer such a product due to MS's illegal product
tie-in with MS-DOS and Win95.
------------------

> Matt Pietrek and Andrew Shulman are highly respected experts
> in their fields, both have shown and proven conclusively that
> Windows 9x is *NOT* a 100% 32-bit operating system.

Andrew Shulman writes a book called "Unauthorized Windows 95". It was
published in Jan 1995. There was only one edition. Windows 95 was
released in August, 1995. How much did Shulman really know about
win-95 8+ months prior to it's release? What has Shulman said about
the Win32 state of Win-98 or Win-98se ??

> Windows 9x is *NOT* a 100% 32-bit operating system.

Win 9x is a 100% 32-bit OS if it's running all 32-bit apps.

But regardless, it certainly isin't DOS-based.

 

[John John]

Re: Don Phillipson - where are you? Why don't you respond? (Win98is built atop MS-DOS)

98 Guy wrote:

> John John wrote:
>
>
>>How can you refute the information in those articles that
>>clearly state that Windows 9x thunks down to 16-bit?
>
>
> You spawn a 16-bit thread when you thunk to 16-bits when you call a
> 16-bit function. The entire OS does not "thunk down".

I never said that the "entire OS" thunks down, I said, and maintain,
that certain significant parts of it do.



> Thunking happens when a 16-bit function is called. If no 16-bit
> functions are called, then no thunking happens.

The point is that there is a lot of calls to 16-bit functions even when
you run 32-bit applications and thunking down is very real on Windows 9x.



> How many functions in the Win-9x API and GDI are exclusively (only)
> 16-bit (ie no 32-bit counterpart)???

Well, isn't that at the crux of the argument here? Do you think that I
can answer that? Can you answer that? That is in large part a secret
that Microsoft has tried to closely guard. I simply don't have the
expertise required to answer that question but the fellows that I
mentioned in my earlier posts and the material that they have published
might shed a bit of light on the subject.



> Linux stuff snipped, who cares...

> Andrew Shulman writes a book called "Unauthorized Windows 95". It was
> published in Jan 1995. There was only one edition. Windows 95 was
> released in August, 1995. How much did Shulman really know about
> win-95 8+ months prior to it's release? What has Shulman said about
> the Win32 state of Win-98 or Win-98se ??

Now you try to discredit an expert in his field. I suppose you never
heard of "Chicago" beta releases. It is also plainly obvious that you
have read none of the material presented or that you have done no
research at all on the subject, Andrew Shulman's findings have been
corroborated by others long after Windows 95 was released. In fact,
Matt Pietrek shows how Microsoft, in an effort to hide Andrew's
findings, tried to make some some of the kernel functions unavailable to
programmers in the second release of Windows 95, they tried to hide it.



> Win 9x is a 100% 32-bit OS if it's running all 32-bit apps.

No it isn't! In http://support.microsoft.com/kb/125867 Microsoft
clearly states:

"Because *many* Win32 API functions are thunked to 16-bit Windows API
functions, there is now a possibility for the 16-bit Windows components
to be reentered. Since the 16-bit Windows components are largely the
same as in Windows 3.x, they need to be protected from being reentered."

Even if you never installed a single 16-bit application and are running
32-bit applications exclusively Windows 9x still uses and thunks down to
many 16-bit functions! Yet more irrefutable proof of that is shown by
the information in this article: http://support.microsoft.com/kb/165719
Anyone who has ever tried to run certain high end CAD-CAM or graphic
software and high end printers is fully aware of the Windows 9x 16-bit
GDI even when running 32-bit software. Many printer and software
vendors instruct users to use NT class operating systems to overcome
these limitations and obtain full potential from their products.

Once again, reading the information here will explain some of these
32-bit API's and 16-bit thunking:
http://www.windowsitlibrary.com/Content/356/03/1.html As can be
gathered from the information there the 16-bit thunking is not solely
limited to the GDI component.



> But regardless, it certainly isin't DOS-based.

As I said earlier, my posts were made mainly to show that Windows 9x
operating systems have more 16-bit code than many would expect and that
the operating system relies on many 16-bit functions even when no 16-bit
applications are running. I believe that with the information and
support sources that I have presented that I have made a compelling
case. The more research I do on the matter the more it becomes clear
and obvious to me that the 16/32 bit hybrid nature of Windows 9x is
undeniable, it is not a true 100% 32-bit operating system, not even when
it is exclusively running 32-bit applications. If you chose to read
none of the supporting information that I have presented then that is
fine by me. If you have read the supporting information and still
insist that Microsoft and the other expert sources are wrong and that
you are right that is also fine by me. Others can take up the DOS based
part of the debate and make their case, they may quickly find out that
the elephant is not only in the room, it is sitting on you yet you still
deny that it is there!

John

 

[MEB]

Re: Don Phillipson - where are you? Why don't you respond? (Win98 is built atop MS-DOS)

If you're going to have this discussion, why not deal with the actual
aspects which YOU can obtain.

This isn't 1995 or even 1998, you presently have the tools available
publicly and free which can be used in the GUI [and outside] to actually
monitor what occurs.

Filemon, Regmon, several resource "hackers", FileAlyzer, Dependency Walker,
etc. can answer your supposed questions quite easily, and they can easily
support or refute based upon the actual inner workings, data/code, etc..
With these tools you can access and watch what does actually occur, pick
apart the OS and its files, review the resources used, memory areas, and
just about anything else you might wish to do. And since you are now able to
use one of the major search engines to find them, I question why this hasn't
been done.
Granted it takes some time, but at least you're no longer limited to debug,
porting to text, and some of the old techniques previously used or required.
I'm NOT stating others got it entirely wrong, I'm indicating you no longer
need to rely upon their information save perhaps for reference.

IF this is an actual discussion on technical aspects [and I use that term
loosely as I previously attempted to bring technical details elsewhere] of
the 9X OS [rather than opinion based upon other's research or
presentations], why not bring your OWN actual findings. You MAY be surprised
at what YOU find verses some of the older technical breakdowns or
publications and I include Que's and Microsoft's therein, moreover by doing
so, you certainly will have a deeper understanding of the OSs and be able to
speak with your own authority based upon your personal findings.

http://peoplescounsel.orgfree.com/ref/gen/sys_diagnos.htm
http://peoplescounsel.orgfree.com/ref/gen/sys_diag2.htm


--
MEB
http://peoplescounsel.orgfree.com
________

 

[PCR]

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

 

[PCR]

LACV wrote:
| Jeff, Philo, Dan
|
| Thanks for your insights.
| I never thought mu question will generate such a discussion, which by
| the way was almost a lecture.
|
| Jeff
| Yes I set the drive up so I can dual boot, that is choose between
| W2k or W98 at start up. Do you have any recommendation where to
| consult the documentation for the boot manager to see what the
| uninstall process is? Answering your other question, YES I installed
| W98 first and then added W2k as a second, alternative system,(but by
| mistake as I was trying to update from W98 to W2K).
| And my last question, how do I know I have erased all the W2K files?
| Perhaps it may be easier as you said, reinstall everyhting from zero.
|
| Thanks in advanced
|
|
| PCR, 98Guy, Bill in Co and MEB
|
| Thanks a lot for the discussion, it was a very good lesson for me

You are welcome. And I hope your Win2K removal goes smoothly. (I've
never done that, myself.)

 

[PCR]

Re: Don Phillipson - where are you? Why don't you respond? (Win98 is built atop MS-DOS)

John John wrote:
| PCR wrote:
|> John John wrote:
|> |> 98 Guy wrote:
|> |
|> |> | Back in 1995, I bet that Micro$oft certainly believed that their
|> |> | support phones would ring off the hook unless Windows 95 was
|> |> | compatible with DOS applications, so in their mind yes, Windows
|> |> | 95 certainly needed to emulate some DOS function calls.
|> |
|> |> PCR wrote:
|> |> I believe that. In their effort to be compatible, how much of Real
|> |> DOS has survived that is important to the functioning of Windows?
|> |
|> | Windows 95 System programming SECRETS by MATT PIETREK
|> |
http://cs.mipt.ru/docs/comp/eng/os/win32/win95_sys_progr_secr/main.pdf
|> |
|> | Big PDF, over 4MB. Read chapters 1 & 2 (about 80 pages). Don't
|> | worry, you don't need to know anything about programming to read
|> | these 2 chapters. It will answer a few questions. I might add
|> | that the NT and W9x Win32 API are *not* the same and that despite
|> | Microsoft's best effort to make users believe otherwise, for
|> | certain functions Kernel32.dll *does* thunk down to the 16-bit
|> | KRNL386.EXE! Reading these chapters should put a few myths to rest.
|>
|> OK, thanks. I'm taking the download now. But I still have MEB's
|> mega-post to read! Seriously, are you saying that KRNL386.EXE is/uses
|> DOS, & that, if Windows thunks down to it often enough, then Windows
|> can be said to be "built upon DOS"? QuickView does reveal a plethora
|> of "functions" to be located inside KRNL386.EXE.
|
| I am not saying that Windows 9x is built directly upon or that it uses
| DOS, but the links or roots are quite obvious. What I am saying is
| that Windows 9x uses a lot of 16-bit components and that many of the
| 16-bit functions bear close resemblance to their DOS counterparts, as
| shown by Matt in his book, there are remnants of real mode DOS code
| that are still being used in Windows 9x. Furthermore, Microsoft has
| always been quite adamant about the 32-bit KERNEL32.DLL not thunking
| down to the 16-bit KRNL386.EXE. According to Microsoft (or according
| to the marketing department at least) it didn't happen, however, as
| pointed out by Matt, "Andrew Schulman proved conclusively in
| "Unauthorized Windows 95" that KERNEL32 does in fact call down to
| KRNL386.EXE."

OK. I guess I'll have to read those chapters to see whether KRNL386.exe
& thunking relate to whether Windows is built on top of DOS. If not,
then there is a lot less to go on.

I do know "Windows 98 Secrets" (Livingston/Straub) also have quoted
Andrew Schulman on page 1054...!...

"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.'"

But, earlier, Livingston wrote:

"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."

SO... Windows does call code in IO.sys, which is DOS, for non-file
functions. (IO.sys must be sitting there even after Windows loads.) Does
it do so for itself-- or only for programs that pre-dated Windows just
to be DOS compatible? And is there any DOS code actually copied into
Windows code? And how much of all that goes on? Those are the questions
that need to be answered to know whether Windows is built atop DOS.

| Regards
|
| John

--
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

 

[Jeff Richards]

See here:
http://support.microsoft.com/kb/311578

This will enable you to operate as though there is only W98 on the machine,
while still retaining the boot loader to manage the boot process.

I suspect that, based on the procedure you used, you could simply create a
W98 startup disk, boot to it, and do a FDISK/MBR and SYS C: to restore the
default DOS boot record, which will boot you into W98. However, because
that carries a risk of completely locking you out of your system, it's not
something I would recommend without very careful investigation.

Retaining the existing boot loader and simply configuring it to go straight
into W98 is much safer.

A Windows 2000 forum may be the right place to get more informed advice,
especially about where the W2k files will be stored when you boot to W98,
and what folders can be safely deleted.. Note that if you have created a W2k
partition then it might be formatted NTFS, which means it is not visible to
W98, and you would not be able to simply delete the contents and use the
space - you would need to remove the partition and re-create it as FAT32.
That's starting to get quite complicated.

Don't be embarrassed at the way that your thread seems to have taken on a
life of its own. That is the responsibility of those who have chosen to
hijack it for their own purposes.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"LACV" <LACV@discussions.microsoft.com> wrote in message
news:84ABBBBA-37E7-491B-A5BB-96389ACA7495@microsoft.com...
> Jeff, Philo, Dan
>
> Thanks for your insights.
> I never thought mu question will generate such a discussion, which by the
> way was almost a lecture.
>
> Jeff
> Yes I set the drive up so I can dual boot, that is choose between W2k or
> W98 at start up. Do you have any recommendation where to consult the
> documentation for the boot manager to see what the uninstall process is?
> Answering your other question, YES I installed W98 first and then added
> W2k
> as a second, alternative system,(but by mistake as I was trying to update
> from W98 to W2K).
> And my last question, how do I know I have erased all the W2K files?
> Perhaps it may be easier as you said, reinstall everyhting from zero.
>
> Thanks in advanced
>
>
> PCR, 98Guy, Bill in Co and MEB
>
> Thanks a lot for the discussion, it was a very good lesson for me
>
>