How to uninstall a dual configuration with Windows2000pro

September 23, 2007

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)

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!

|

| Or - maybe the expression "built on top of", is just too ambiguous?

| Unlike, perhaps, the case of Windows 3.1.

....snip

September 24, 2007

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

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

To correct myself...

98 Guy wrote:

> There is a condundrum here, in that at the time that win-9x/

> win-98/se was introduced, the "boot from CD" option in the

> system BIOS was not a common option (if at all)

The 1998 - 1999 time frame corresponds with the introduction of the P2

and P3 cpu's, which probably had boot-from-CD as a bios option (it's

been a while since I've laid eyes on a P2 or P3 bios setup screen).

Maybe 486-based motherboards didn't have boot-from-CD as a bios

option?

> hence there never was a bootable win-9x installation CD.

Some web resources say that all the various versions of win-98 CD's

were not bootable, but some on-line step-by-step win-98 installation

guides say otherwise.

In any case, regardless of how a system is booted (from a setup floppy

or a win-98 CD) the fact remains that win-98 can be "built" onto

(into?) an empty hard drive - which would mean that win-98 is not

"built on-top of DOS".

PCR wrote:

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

As I mentioned in a previous post, Microsoft says that Win-98 makes

the following list of DOS functions available for apps that need them:

Create Program Segment Prefix (function 55h)

- no MS or other relavent web resourse found

- no win32 API equivalent?

Get MS-DOS Version (function 30h)

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/win9x/msdos_5ir7.asp

- no win32 API equivalent?

Create Temp File (function 5Ah)

http://support.microsoft.com/kb/49849

- win32 API functional equivalent is

"Create Unique File" GetTempFileName

International (function 65h)

http://www.uni-giessen.de/faq/archiv/i18n-faq/msg00000.html

- "This interrupt returns extended country information."

- Windows uses GetProfileString API function.

Dup File Handle (function 45h)

http://www.faqs.org/faqs/assembly-language/x86/general/part2/section-6.html

- no win32 API equivalent?

Set/Get Drive (functions 0Eh and 19h)

- no MS or other relavent web resourse found

- win32 API functional equivalent is

"Select Disk" - SetCurrentDirectory

"Get Current Disk" - GetCurrentDirectory

Exit (function 4Ch)

http://support.microsoft.com/kb/114588

- seems to be a pure DOS function that win-9x

would not rely on for normal operation)

- no win32 API equivalent?

Set/Get Program Segment Prefix (functions 50h and 51h)

- no MS or other relavent web resourse found

- no win32 API equivalent?

Get Date/Time (functions 2Ah and 2Ch)

http://www.patentstorm.us/patents/5918039-description.html

- says that functions 2A and 2C are located in IO.SYS

- win32 API functional equivalent is

"Get Date" - GetDateAndTime

"Get Time" - GetDateAndTime

NetWare Get Station Num (function DCh)

- no MS or other relavent web resourse found

This is a link pertaining to "Porting MS-DOS System Calls":

http://msdn2.microsoft.com/en-us/library/aa984837(vs.71).aspx

It is a list of DOS int21h function calls and their Win32 API

equivalent and is the source for some of the above information.

> ... If either of those is true, then Win98 is built upon DOS--

> because it uses DOS to do the things it does.

Again, quoting directly from Microsoft:

"Some functions, however, are handled by MS-DOS code, although

the code itself is running in virtual 8086 mode, not real mode.

Functions implemented in this manner ensure backward

compatibility with existing real-mode software, such as the

Novell NetWare client."

Those functions (which I detailed above) are hardly what you would

call a "foundation-set" that you would base an OS like Win-9x on, so

it makes no sense to say that Win-9x is "built upon" them (or in

general, to be "built upon" DOS).

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

Any DOS code that was integrated into a Win32 program module would

render it no longer DOS.

> I believe Real DOS is loaded & may remain functional even

> after Win98 is loaded.

Again, read the Microsoft quote (above). I think that IO.SYS is one

of those DOS components that is indeed running in a virtual 8086

environment, but only to provide a handful of functions for legacy

apps.

> However, that only would prove Win98 is DOS-tolerant!

Or more correctly - DOS (and Novell) friendly.

The NT product line (including XP and Vista) probably also includes

some similar set of DOS support functions. I have a data acquisition

and graphing program (written and compiled in PowerBasic) that

functions just fine in XP and Vista.

September 24, 2007

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)

98 Guy wrote:

| To correct myself...

|

| 98 Guy wrote:

|

|> There is a condundrum here, in that at the time that win-9x/

|> win-98/se was introduced, the "boot from CD" option in the

|> system BIOS was not a common option (if at all)

|

| The 1998 - 1999 time frame corresponds with the introduction of the P2

| and P3 cpu's, which probably had boot-from-CD as a bios option (it's

| been a while since I've laid eyes on a P2 or P3 bios setup screen).

| Maybe 486-based motherboards didn't have boot-from-CD as a bios

| option?

|

|> hence there never was a bootable win-9x installation CD.

|

| Some web resources say that all the various versions of win-98 CD's

| were not bootable, but some on-line step-by-step win-98 installation

| guides say otherwise.

|

| In any case, regardless of how a system is booted (from a setup floppy

| or a win-98 CD) the fact remains that win-98 can be "built" onto

| (into?) an empty hard drive - which would mean that win-98 is not

| "built on-top of DOS".

I disagree with that statement. IF an important amount of Win98 code is

actually copied over from DOS code, I think it could be said Win98 is

"built on top of DOS". I doubt it-- BUT my mind is open, pending

Colorado & Phillipson have scoured Win98's two million lines of code for

evidence! I think I owe them that much!

| PCR wrote:

|

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

|

| As I mentioned in a previous post, Microsoft says that Win-98 makes

| the following list of DOS functions available for apps that need them:

|

| Create Program Segment Prefix (function 55h)

| - no MS or other relavent web resourse found

| - no win32 API equivalent?

|

| Get MS-DOS Version (function 30h)

|

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/win9x/msdos_5ir7.asp

| - no win32 API equivalent?

|

| Create Temp File (function 5Ah)

| http://support.microsoft.com/kb/49849

| - win32 API functional equivalent is

| "Create Unique File" GetTempFileName

|

| International (function 65h)

| http://www.uni-giessen.de/faq/archiv/i18n-faq/msg00000.html

| - "This interrupt returns extended country information."

| - Windows uses GetProfileString API function.

|

| Dup File Handle (function 45h)

|

http://www.faqs.org/faqs/assembly-language/x86/general/part2/section-6.html

| - no win32 API equivalent?

|

| Set/Get Drive (functions 0Eh and 19h)

| - no MS or other relavent web resourse found

| - win32 API functional equivalent is

| "Select Disk" - SetCurrentDirectory

| "Get Current Disk" - GetCurrentDirectory

|

| Exit (function 4Ch)

| http://support.microsoft.com/kb/114588

| - seems to be a pure DOS function that win-9x

| would not rely on for normal operation)

| - no win32 API equivalent?

|

| Set/Get Program Segment Prefix (functions 50h and 51h)

| - no MS or other relavent web resourse found

| - no win32 API equivalent?

|

| Get Date/Time (functions 2Ah and 2Ch)

| http://www.patentstorm.us/patents/5918039-description.html

| - says that functions 2A and 2C are located in IO.SYS

| - win32 API functional equivalent is

| "Get Date" - GetDateAndTime

| "Get Time" - GetDateAndTime

|

| NetWare Get Station Num (function DCh)

| - no MS or other relavent web resourse found

|

| This is a link pertaining to "Porting MS-DOS System Calls":

|

| http://msdn2.microsoft.com/en-us/library/aa984837(vs.71).aspx

|

| It is a list of DOS int21h function calls and their Win32 API

| equivalent and is the source for some of the above information.

Well, let us say Real DOS is loaded & available for use to the user of

Win98 through functions that are a part of Win98. It still wouldn't

prove Win98 itself is dependent on DOS-- but only that Win98 can command

it!

|> ... If either of those is true, then Win98 is built upon DOS--

|> because it uses DOS to do the things it does.

|

| Again, quoting directly from Microsoft:

|

| "Some functions, however, are handled by MS-DOS code, although

| the code itself is running in virtual 8086 mode, not real mode.

| Functions implemented in this manner ensure backward

| compatibility with existing real-mode software, such as the

| Novell NetWare client."

|

| Those functions (which I detailed above) are hardly what you would

| call a "foundation-set" that you would base an OS like Win-9x on, so

| it makes no sense to say that Win-9x is "built upon" them (or in

| general, to be "built upon" DOS).

If these "functions" are actual DOS code that Win98 on its own must use

to work, then I would have to lean the other way in this argument. Is

that the complete list? Even as small as that, some of them sound

important, such as...

Set/Get Drive (functions 0Eh and 19h)

Set/Get Program Segment Prefix (functions 50h and 51h).

I would think those need to be done a lot! But I see you have found a

win32 API functional equivalent for one of those. But does that API call

or incorporate the DOS code? Can Phillipson have been right?

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

|

| Any DOS code that was integrated into a Win32 program module would

| render it no longer DOS.

True-- but Win98 could be said to be "built upon DOS". Maybe, though, in

a lesser sense than if calls were made to actual DOS code.

|> I believe Real DOS is loaded & may remain functional even

|> after Win98 is loaded.

|

| Again, read the Microsoft quote (above). I think that IO.SYS is one

| of those DOS components that is indeed running in a virtual 8086

| environment, but only to provide a handful of functions for legacy

| apps.

IO.sys is the first program loaded during boot (it is mentioned in the

Partition Boot Record), & it is loaded before Win98 is started. I don't

think a virtual machine can exist until then. Also, didn't Zabcar say...

news:pi54f3hg610sa1nj0svaa0dtsgqvc2n7a2@4ax.com

.... he could go from IO.sys to Real DOS, load Windows with WIN, & have

Real DOS available after Windows was closed? Therefore, I lean toward

the belief Real DOS code is always present & available. It's just a

matter as to whether Win98 actually requires it to be present to

function.

|> However, that only would prove Win98 is DOS-tolerant!

|

| Or more correctly - DOS (and Novell) friendly.

|

| The NT product line (including XP and Vista) probably also includes

| some similar set of DOS support functions. I have a data acquisition

| and graphing program (written and compiled in PowerBasic) that

| functions just fine in XP and Vista.

That would prove XP & Vista can emulate DOS while emitting their

irradiation rays. They can do two things at once, then!

--

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

September 25, 2007

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)

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

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.

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.

Some claim IO.SYS defines the issue, 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.]

CLOCK$ j

CONFIG$

PQRU3

COMPu

COMPuB&

PVWUS

FAT12

FAT16

FAT32

NO NAME

!8!`@aAbBfFgGhHI

u&<Ft=<Gt9.

C:\SYSTEM.DAT

C:\WINBOOT.INI

&YXtJS

tBw*RQSPU

NO NAME

C:\BOOTLOG.TXT

C:\BOOTLOG.PRV

MDF??(Logo disabled)

_fZYrJ

0123456789ABCDEFS

Insert diskette for drive

and press any key when ready

Your program caused a divide overflow error.

If the problem persists, contact your program vendor.

Windows has disabled direct disk access to protect your long filenames.

To override this protection, see the LOCK /? command for more information.

The system has been halted. Press Ctrl+Alt+Del to restart your computer.

You started your computer with a version of MS-DOS incompatible with this

version of Windows. Insert a Startup diskette matching this version of

Windows and then restart.

IOSYSMSGX

MPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPAD

MPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPAD

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

NO NAME

FAT12

dVDISK V3.3

VDISK3.3

DBLSPACEINI

ONOFF

<ArN<ZwJ

<[t(<Ot]<EtY<At

\CONFIG.SYS

A:\COUNTRY.SYS

COUNTRY

CONFIG=

COMMON

ACCDATEa

BREAKC

BUFFERSB

BUFFERSHIGHb

COMMENTY

COUNTRYQ

DEVICED

DEVICEHIGHU

DRIVPARMP

FCBSHIGHx

FILESF FILESHIGHf

INCLUDEJ

INSTALLI

INSTALLHIGHW LASTDRIVEL

LASTDRIVEHIGHl

LOGOq

SUBMENUO MENUCOLORR

MENUDEFAULTA

MENUITEME

MULTITRACKM

NUMLOCKN

SHELLS

STACKSK

STACKSHIGHk

SWITCHES1

ARVFHSTDICN

:\WINDOWS

\COMMAND

TMP=TEMP=\TEMPPROMPT=$p$g

winbootdir=PATH= /K NETSTART

/D /K AUTOEXEC

COMSPEC=\WNBOOTNG.STS

\HIMEM.SYS

/TESTMEM:ON

\ASPI2DOS.SYS

\ASPI2HLP.SYS

\DBLBUFF.SYS

\IFSHLP.SYS

\SETVER.EXE

EMMXXXX0

IFS$HLP$

SETVERXX

\AUTOEXEC.BAT

IO DOS

MSDOS DOSIBMBIO COMIBMDOS COMIO.DOS

IBMBIO.COM

W40DOSWOSAPP

CONFIG.APP

CONFIG.WOS

C:\MSDOSSYS.STS

IO.SYS

MSDOS.SYS

C:\MSDOS.SYS

COMMAND.COM

CONFIG.SYS

AUTOEXEC.BAT

DBLSPACE.BIN

DRVSPACE.BIN

IO.W40

JO.SYS

MSDOS.W40

WINBOOT.INI

\COMMAND.COM

\WIN.COM

(Safe boot)

IBM ThinkPad 510

b[PATHS]

e[OPTIONS]

eWINDIR

]dWINBOOTDIR

vdHOSTWINBOOTDRV

dUNINSTALLDIR

dLOGO

DBLSPACE

DRVSPACE

BOOTKEYS

BOOTDELAY

dBOOTWIN

BOOTGUI

BOOTWARN

BOOTMULTI

DOUBLEBUFFER

BOOTMENUDEFAULT

LBOOTMENUDELAY

LBOOTMENU

LBOOTSAFE

LNETWORK

!LLOADTOP

BOOTCONFIG

dDISABLELOG

dSYSTEMREG

AUTOSCAN

dWINVER

<:u<ar<<zw8$

< t6< t2<,t1< u

UsHIGH

NOUMB

NOAUTO

SINGLE

PROTMAN$ATiVideoQEMM386$QLODR$10?STAC-CDProT

IO SYS

SCSIMGR$

MBRINT13SYS

UqHttHtjHt`HtVHt

t4</t0<,u!

QEMM386.SYS

\DRVSPACE.BIN

C:\DRVSPACE.INI

C:\DBLSPACE.BIN

\STACKER.BIN

DBLSBIN$

\LOGO.SYS

Loading Device = LoadFailed = LoadSuccess =

C:\IO.SYS

C:\JO.SYS

<DWCMu;9L

}RSWuI&

}TAPuA

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

There is an unrecognized command in your CONFIG.SYS file.

The following command in your CONFIG.SYS file is incorrect:

The sector size specified in this file is too large: $

The following file is missing or corrupted: $

WIN.COM

COMMAND.COM

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.

There is not enough memory for the COUNTRY.SYS file.

Remove some drivers from your CONFIG.SYS file, and then try again.

The configuration specified in your CONFIG.SYS file is too large for memory.

Remove some drivers, and then try again.

You have too many block devices specified in your CONFIG.SYS file.

Remove some disk drivers from your CONFIG.SYS file, and then try again.

The STACKS setting(s) in your CONFIG.SYS file are incorrect.

Default stack settings will be used instead.

There is an error in your CONFIG.SYS file on line $

Warning: Logical drives past Z exist and will be ignored.

Microsoft Windows 98 Startup Menu

Enter a choice: $

F5=Safe mode Shift+F5=Command prompt Shift+F8=Step-by-step confirmation

[ ]$

[Enter=Y,Esc=N]?$

YNAyna

Time remaining: $

Type the name of the Command Interpreter (e.g., C:\WINDOWS\COMMAND.COM)

Press any key to continue . . .

Windows is bypassing your startup files.

Minimal network support will be loaded if available.

Windows is starting the command prompt only.

Windows will prompt you to confirm each startup command.

Load DoubleSpace driver [Enter=Y,Esc=N]?$

Load DriveSpace driver [Enter=Y,Esc=N]?$

The compression driver cannot be set up correctly.

Get a version from your vendor that is compatible with this version of

Windows.

Process the system registry [Enter=Y,Esc=N]?$

Create a startup log file (BOOTLOG.TXT) [Enter=Y,Esc=N]?$

Process your startup device drivers (CONFIG.SYS) [Enter=Y,Esc=N]?$

Process your startup command file (AUTOEXEC.BAT) [Enter=Y,Esc=N]?$

Load the Windows graphical user interface [Enter=Y,Esc=N]?$

Warning: Windows has detected a registry/configuration error.

Choose, Command prompt only, and run SCANREG.

Warning: Windows has detected a compressed drive access error.

Choose Safe mode command prompt only, to help you identify the problem.

Warning: Windows did not finish loading on the previous attempt.

Choose Safe mode, to start Windows with a minimal set of drivers.

Warning: Windows multi-boot may not function correctly.

Check for system files in your root directory with conflicting extensions.

Warning: the system configuration manager failed to run.

Some of your real-mode device drivers may not initialize properly.

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

The BUFFERS setting(s) in your CONFIG.SYS file are too large.

Default buffer settings will be used instead.

A memory allocation error occurred during startup.

Restart your computer and select Interactive Start to identify the problem.

Warning: the high memory area (HMA) is not available.

Additional low memory (below 640K) will be used instead.

There is not enough memory for Windows.

Remove some drivers from your CONFIG.SYS file, and then try again.

Your previous MS-DOS files were not found. $

Your previous MS-DOS version is not supported. $

MS-DOS startup failed.

Now loading your previous version of MS-DOS, please wait.

Invalid setting in the MSDOS.SYS file: $

An internal stack overflow has caused this session to be halted.

Change the STACKS setting in your CONFIG.SYS file, and then try again.

IOSYSMSG

MPADMP [dozens of this line padding removed]

ADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPAD

gJ_@gEg$g%`

F|OqO5P7P

FJgOg^_2_

OVW;g6g*P I&IFIWI

P3AeP

KGjii

UWVRQSP

UWVRQSP&

RIt6ItLIt4It<IuC

@M;S<>==?KRRAAS[

T\j;ThuT;\juO

fYfHf;

fXfZfYfBf@fIu

fXfZfY

..memTkfk

FAT3u

"vHY^X[s

| PIPEu

&fZY[fX_f^

fPfSfQfRfZfYf[fX[`

fBfIt

OfRfQf

fYfZr<f

fBfIu

f[fYfQfSf

fZf[fY

fZf[fYrp&

f[fYr f

fYfXf+

IfPRQ

=RRaAu2f

rrAau'

fZ[Y_fXr

EEEIII

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`ABCDEFGHIJKL

MNOPQRSTUVWXYZ{|}~

CUEAAAACEEEIIIAAEAAOOOUUYOU$$$$$AIOUNN

NO NAME

\COUNTRY.SYS

M/d/yy dddd,MMMMdd,yyyy

e8m1E

6tAas

FYoSw

sY21X

wnxM~I,w

tAtgvQ

itTLx

yf8;1P

NDa3d $C

#Kqq>iA

Yqg}LD0

>U-DJLk

98ap`iH

@EJLld

2ejUI

Ap:xvq(

:~DiNJg

IK/F10

~None of the above

Enter your choice:

Windows cannot determine what configuration your computer is in.

Select one of the following:

Original Configuration

Undocked

MPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPADMPAD

MPADMPADMPADMPADMPAD

<st'<ntQ<pt`<Et

FCCA9N

<RGDBu

C:\WINDOWS

ASD_Wizard

ASD.EXE /w

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

BootCount

LASTDRIVE

DoubleBuffer

Win31FileSystem

SetupN

INSTALLED

GetDevParmsIoctl

Software\Microsoft\Windows\CurrentVersion\RunOnce

0123456789ABCDEF

ASD.dat

System\CurrentControlSet\Control\ASD\Prob

CONFIG$

FriendlyName

System\CurrentControlSet\Control\IDConfigDB

COMPAQ

TOSHIBA

SOFTWARE\CLASSES

..DEFAULT

_C_FILE_INFO=

- stack overflow

- integer divide by 0

- not enough space for environment

run-time error

- floating-point support not loaded

- null pointer assignment

!Packed file is corrupt

y8y4y0y,y(y$y y

4W=EDcD

-----------------------

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

win.com contains:

WININIT.EXE

WININIT.INI

COMMAND.COM

DOSSTART.BAT

win.com

PATHsystem\vmm32.vxd

windir=

SMARTDRV.EXE

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.

Reviewing bootlog.txt indicates essential elements:

[0001680A] Loading Device = C:\WINDOWS\HIMEM.SYS

(Logo disabled)

[0001680A] LoadSuccess = C:\WINDOWS\HIMEM.SYS

[0001680A] Loading Device = C:\WINDOWS\DBLBUFF.SYS

[0001680B] LoadSuccess = C:\WINDOWS\DBLBUFF.SYS

[0001680B] Loading Device = C:\WINDOWS\IFSHLP.SYS

[0001680B] LoadSuccess = C:\WINDOWS\IFSHLP.SYS

[0001680E] C:\WINDOWS\ASP4DOS.COM[0001680F] starting

[00016814] C:\PROGRA~1\GRISOFT\AVG7\BOOTUP.EXE[00016814] starting

[000169A6] Loading Vxd = VMM

[000169A6] LoadSuccess = VMM

[000169A6] Loading Vxd = C:\WINDOWS\SMARTDRV.EXE

[000169A7] LoadSuccess = C:\WINDOWS\SMARTDRV.EXE

[000169A7] Loading Vxd = vnetsup.vxd

[000169A7] LoadSuccess = vnetsup.vxd

[000169A7] Loading Vxd = ndis.vxd

[000169A8] LoadSuccess = ndis.vxd

[000169A8] Loading Vxd = ndis2sup.vxd

[000169A8] LoadFailed = ndis2sup.vxd

[000169A8] Loading Vxd = JAVASUP.VXD

[000169A8] LoadSuccess = JAVASUP.VXD

[000169A8] Loading Vxd = CONFIGMG

[000169A8] LoadSuccess = CONFIGMG

[000169A8] Loading Vxd = NTKERN

[000169A9] LoadSuccess = NTKERN

[000169A9] Loading Vxd = VWIN32

[000169A9] LoadSuccess = VWIN32

[000169A9] Loading Vxd = VFBACKUP

[000169A9] LoadSuccess = VFBACKUP

[000169A9] Loading Vxd = VCOMM

[000169A9] LoadSuccess = VCOMM

[000169A9] Loading Vxd = COMBUFF

[000169A9] LoadSuccess = COMBUFF

[000169A9] Loading Vxd = C:\WINDOWS\system\VMM32\IFSMGR.VXD

[000169A9] LoadSuccess = C:\WINDOWS\system\VMM32\IFSMGR.VXD

[000169A9] Loading Vxd = C:\WINDOWS\system\VMM32\IOS.VXD

[000169AB] LoadSuccess = C:\WINDOWS\system\VMM32\IOS.VXD

.. . .

-----------

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.

Windows 9X IS built upon DOS. 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..

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.

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.

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

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.

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

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.

Of course, all this is just my opinion, but I happen to be one of those

people who DID contact the BBS and followed Microsoft basicly from its

beginnings.

|

| |

| | Or - maybe the expression "built on top of", is just too ambiguous?

| | Unlike, perhaps, the case of Windows 3.1.

|

| ...snip

|

--

MEB

http://peoplescounsel.orgfree.com

________

September 25, 2007

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

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

PCR wrote:

> | the fact remains that win-98 can be "built" onto (into?) an

> | empty hard drive - which would mean that win-98 is not

> | "built on-top of DOS".

>

> I disagree with that statement.

How so?

> IF an important amount of Win98 code is actually copied over

> from DOS code,

That statement that you disagree with doesn't talk about code history

or code integration.

> IF an important amount of Win98 code is actually copied over

> from DOS code,

Do you even know what DOS is?

Win-98 is many mega-bytes of 32-bit protected-mode code. DOS is (at

best) several hundred kbytes of 16-bit real-mode code.

> I think it could be said Win98 is "built on top of DOS".

Saying that is as farcical as saying that iPhone is "built on top of"

the iPod.

> I doubt it-- BUT my mind is open, pending Colorado & Phillipson

> have scoured Win98's two million lines of code for evidence!

> I think I owe them that much!

So basically you're saying that it would take an examination of win-9x

source code to convince you that win-9x is NOT "based" or "built" upon

DOS, and further that you expect such an examination to be performed

by someone that is conspiciously absent from this thread?

(I can't tell if you're serious, or not).

> | Again, read the Microsoft quote (above). I think that IO.SYS

> | is one of those DOS components that is indeed running in a

> | virtual 8086 environment, but only to provide a handful of

> | functions for legacy apps.

>

> IO.sys is the first program loaded during boot (it is mentioned

> in the Partition Boot Record), & it is loaded before Win98 is

> started. I don't think a virtual machine can exist until then.

IO.sys may be fully loaded prior to win.com being executed - but it is

then most certainly nuked as the CPU is transitioned from real to

protected mode. The only function of IO.SYS is as a boot loader.

Windows 9x uses (a new version of) IO.SYS, which replaces the MS-DOS

system files (IO.SYS and MSDOS.SYS). The actual underlying core of

win-9x is the virtual machine manager (vmm32.vxd). Most likely, the

DOS functions mentioned previously are handled by DOSMGR.VXD (the

MS-DOS Emulation Manager) and V86MMGR.VXD (the MS-DOS Memory Manager).

> Also, didn't Zabcar say...

> ... he could go from IO.sys to Real DOS, load Windows with

> WIN, & have Real DOS available after Windows was closed?

No - all he said was that he could force win-98 to NOT load with the

appropriate .ini file setting.

> Therefore, I lean toward the belief Real DOS code is always

> present & available.

What do you mean by "DOS code" ???

Are you aware that "real DOS code" can only run in a virtual x86

environment - an environment that is set up and controlled by Windows?

> It's just a matter as to whether Win98 actually requires it

> to be present to function.

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.

September 25, 2007

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

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

MEB wrote:

> Windows 9X IS built upon DOS.

How can a 32-bit, protected-mode, multi-tasking operating system be

"built upon" a 16-bit, real-mode, single-tasking operating system?

> Does this indicate Windows is based upon DOS, built on top of DOS,

> or any other claim one wishes to make therein related - YES.

Are you saying that Win-9x is a GUI that runs "on top of" DOS?

Windows 9X is built upon, or based, on the virtual machine manager.

Yes, some aspects of DOS functionality is necessary during the boot

process in order to get the machine to the point where the VMM has

switched the processor into protected mode and the system virtual

machine has been created. But I differentiate the boot process with

the end result - the end result being something VERY DIFFERENT and NOT

BASED or BUILT on DOS.

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

So then by that reasoning, one could say that Vista is also built upon

DOS?

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

You're bringing politics into what is a technical issue.

The question here is not asking if Windows-X is unique or has borrowed

concepts and functions from other companies or products. The question

is "how much does Win-9x rely directly on DOS for it's design or

functionality". Because it does far more than DOS ever did from a

service-provision point of view, and because it does it in a vastly

different CPU operating mode (one that is completely foreign to DOS),

the answer is that Win-9x could not have been based (or built) on

DOS.

That is not the same as saying that Win-9x must be "aware" or

"compatible" with DOS application programs. Win-9x can (and must) run

important DOS applications. But that design goal does not mean that

Win-9x must be based on or "built on" DOS.

Lastly, I raise again the idea that just because DOS and Win-9x are

aware of the same File Allocation structure (FAT-32) - that doesn't

make them related or make Win-9x a derivative of DOS.

September 25, 2007

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)

"98 Guy" <98@Guy.com> wrote in message news:46F87F2C.F47E56B1@Guy.com...

| MEB wrote:

|

| > Windows 9X IS built upon DOS.

|

| How can a 32-bit, protected-mode, multi-tasking operating system be

| "built upon" a 16-bit, real-mode, single-tasking operating system?

Because those aspects had already been implemented prior to Microsoft's

Windows 95 by third parties and within Intel and AMD processors. The

problem: Microsoft DOS was incapable of using that processing environment

prior to Win95 [and NT]. Not that it couldn't have, just that it wasn't in

Microsoft's plans.

|

| > Does this indicate Windows is based upon DOS, built on top of DOS,

| > or any other claim one wishes to make therein related - YES.

|

| Are you saying that Win-9x is a GUI that runs "on top of" DOS?

You can play this little word game all you wish, Windows is a graphical

user interface FOR DOS.

|

| Windows 9X is built upon, or based, on the virtual machine manager.

| Yes, some aspects of DOS functionality is necessary during the boot

| process in order to get the machine to the point where the VMM has

| switched the processor into protected mode and the system virtual

| machine has been created. But I differentiate the boot process with

| the end result - the end result being something VERY DIFFERENT and NOT

| BASED or BUILT on DOS.

Phht... yeah right, the end results is you have a graphical environment so

the non-geeks/non-savvy could use a computer.

EVERYTHING done in Windows could be done from DOS, meaning the command

prompt or a DOS application running WITHOUT the bloat of Windows GUI.

Moreover, apparently the device operating system, let's call it THE

FUNCTION to perhaps clarify, somehow has escaped your thought process. So

VMM is loaded, ah okay so what is accomplished. You have taken memory,

increased its addressing space, crammed some programs/devices into it, and

done what? Oh wait, you've created the ability to run more than one DOS

program at a time... combined a few commands into one, put some buttons and

menus on a tool bar which call those commands, and created a interface so

you can watch, that's Windows... and that ah, "virtual machine" runs where

and on what .... is it floating out in space somewhere, or running in some

fifth dimension I haven't heard about yet ...

|

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

|

| So then by that reasoning, one could say that Vista is also built upon

| DOS?

One could, except for the fact it is entirely different coding specific to

the NT environment, NOT based upon Microsoft DOS [the commercial MSDOS].

None the less, it IS a DOS [device operating system] so yeah, its a DOS,

just not what most would consider as DOS, e.g. command line DOS. Heck we can

even make that more plain: the new chipsets have no [or little] prior DOS

support and require NT's HAL layer and other aspects to function. As the old

were designed for DOS, the new are designed for NT.

|

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

|

| You're bringing politics into what is a technical issue.

No I'm not, I'm bringing technical facts, and proper issues. Not so

strangely I even produced the CODE. You present opinion and what ...

Microsoft hasn't really created much on its own, or at least in the early

days. Most of Windows 3.* and 9X/ME was acquired from other companies or

used

under license agreement. Just as a large part of its fat and other that it

now holds patent for could reasonably be traced to other contributors or

acquisitions, or at times, questionable activities.

|

| The question here is not asking if Windows-X is unique or has borrowed

| concepts and functions from other companies or products. The question

| is "how much does Win-9x rely directly on DOS for it's design or

| functionality". Because it does far more than DOS ever did from a

| service-provision point of view, and because it does it in a vastly

| different CPU operating mode (one that is completely foreign to DOS),

| the answer is that Win-9x could not have been based (or built) on

| DOS.

Which DOS are you referring too,, Microsoft? then you're somewhat right,

Windows GUI far exceeds Microsoft's prior plain MSDOS activities. As for the

*vastly different CPU operating mode* guess what, that was also already

available WAAAAAAAAAY before Microsoft implemented it and Intel provided

support... for instance, SUN had done that already using its own processors

and OS..

As for "could not have been based (or built) on DOS", gees what about all

those DOS extenders . . . and other OSs which had already provided such from

their version of DOS..... Is it that you think Windows manages to control

and use the functions of the chips WITHOUT accessing them or something? Gee,

what are you smoking?

If ALL you're referring to is commercially available MSDOS and ONLY

Microsoft's offered tools:

Once support from Intel was provided for this activity chipwise, there were

other OSs implementing this ability [regretfully most ever made it beyond

those whom had stumbled upon them on some BBS or heard about them on FIDO].

They lacked, however, the financial backing and media adverti$ing that

Microsoft has used so successfully.

And we should address UNIX had accomplished the same years before, though

using multiple processors, again before Microsoft even thought about it.

Plus that kinda overlooks all those third party cards and progs that

provided extended/expanded memory WAAAYYY back in the 086 days [like BOCA]

before Microsoft even questioned how to exceed chip limitations.

Microsoft has yet to be *cutting edge*, though maybe with the soon to be

super chips it has the chance to be in the lead for once, though if

Microsoft screws up as badly as it did with VISTA ....

Moreover, the users of MSDOS knew Microsoft could have offered this in

plain MSDOS, they also realized Microsoft wouldn't as it wanted its flagship

GUI for the mass market, that's where the money was... 6.22 was the end of

the command prompt [there were a lot of Microsoft betas being offered before

Win95 was sent to market, something virtual without the full GUI, a better

DOS SHELL...]

MSDOS could easily have been modified to support Intel's new code, but it

wasn't *WINDOWS*, which was Microsoft's GUI OS for that millennium. Windows,

the OS that anyone could use without the need to know WHY or HOW it worked.

Oh the magic of it all.

We can't overlook the fact that third parties DID supply programs that used

that new Intel code ability, nor can we overlook the fact that 32bit DOS is

still being worked on, the stumbling block being Microsoft's patents and

Intel's privacy agreement's with Microsoft [and competition with AMD].

|

| That is not the same as saying that Win-9x must be "aware" or

| "compatible" with DOS application programs. Win-9x can (and must) run

| important DOS applications. But that design goal does not mean that

| Win-9x must be based on or "built on" DOS.

So what the heck is it based on,, let me guess, thin air, or mystical

qualities taken from old texts from the ancient alchemists.... yeah right,

it pulls the same assembly [chip] code from the chips as MSDOS did. So now

you have several billion lines of code and a couple hundred DLLs, taking the

place of a couple dozen lines, yep, that's advancement alright.

Open a command prompt in Windows and type * set *. Hmm, seems command.com

is "comspec", look it up if you don't know what that means..

So what's the major usage by the common user of VISTA: cruising the

Internet, downloading programs, and playing music, games, or videos. Yep,

billions of lines of code, massive memory consumption and hard drive space,

and the necessary fast processor; so they can multi-task *downloading* while

*chatting* online.

|

| Lastly, I raise again the idea that just because DOS and Win-9x are

| aware of the same File Allocation structure (FAT-32) - that doesn't

| make them related or make Win-9x a derivative of DOS.

So basically what your saying is this whole supposed "discussion" is just

so you can pass some time, right... sorry, got other things to do, I did my

part, if you're not going to address the code then this is just ramblings.

--

MEB

http://peoplescounsel.orgfree.com

________

September 25, 2007

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

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

98 Guy wrote:

> How can a 32-bit, protected-mode, multi-tasking operating system be

> "built upon" a 16-bit, real-mode, single-tasking operating system?

I stand to be corrected but I do believe that the Window 9x Win32 API is

mostly thunked down to 16-bit, that means that KERNEL32, USER32 and

GDI32 are thunked down to their 16-bit counterparts, respectively those

are thunked down to KRNL386, USER.EXE and GDI.EXE. In essence these

core Windows 9x components are 16-bit code wrapped in 32-bit code, they

aren't pure 32-bit like that of the NT family.

I do know that to be true of Windows 95 and I don't think that the Win32

API was reinvented with Windows 98, but I could be wrong...

John

September 25, 2007

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

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

98 Guy wrote:

> How can a 32-bit, protected-mode, multi-tasking operating system be

> "built upon" a 16-bit, real-mode, single-tasking operating system?

To further my other post, it uses Win16Mutex.

John

September 25, 2007

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

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

John John wrote:

> 98 Guy wrote:

>

>> How can a 32-bit, protected-mode, multi-tasking operating system be

>> "built upon" a 16-bit, real-mode, single-tasking operating system?

>

> To further my other post, it uses Win16Mutex.

And to yet further my post again, the information in my other posts can

be verified here:

http://www.windowsitlibrary.com/Content/356/03/1.html

http://www.windowsitlibrary.com/Content/356/03/2.html

http://homepages.tesco.net/~J.deBoynePollard/FGA/dos-windows-boot-process.html

John

September 25, 2007

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

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

John John wrote:

> I stand to be corrected but I do believe that the Window 9x Win32

> API is mostly thunked down to 16-bit, that means that KERNEL32,

> USER32 and GDI32 are thunked down to their 16-bit counterparts,

> respectively those are thunked down to KRNL386, USER.EXE and

> GDI.EXE. In essence these core Windows 9x components are 16-bit

> code wrapped in 32-bit code, they aren't pure 32-bit like that

> of the NT family.

According to this:

http://www.microsoft.com/technet/archive/win98/reskit/part5/wrkc26.mspx?mfr=true

"The Windows 98 architecture includes performance improvements

over earlier versions of Windows. The changes, which strongly

impact most areas of system performance, are as follows:

- 32-bit device drivers for all system components, ensuring

better performance and better resource management.

Also, this link:

http://www.microsoft.com/technet/archive/win98/reskit/part5/wrkc26.mspx?mfr=true

Chapter 28 - Windows 98 Architecture

Says this:

"Microsoft Windows 98 is a 32-bit operating system that

provides built-in Internet connectivity, Plug and Play

hardware support, high performance, robustness, and backward

compatibility with Windows 95. Windows 98 enhancements to

Windows 95 include more sophisticated power management,

multiple video display support, and integrated support for

the latest hardware. Also included is support for the new

Win32 Driver Model (WDM), allowing a WDM device to run under

both Windows 98 and future versions of Windows NT using the

same driver."

And importantly, it goes on to say this:

-------------

Like Windows 95, Windows 98 is derived from the Windows 3.1

platform and includes the following features:

- A complete 32-bit kernel, including memory management,

and preemptive multitasking and multithreading support.

- A fully integrated 32-bit, protected-mode file system,

which eliminates the need to rely on a separate copy of

MS-DOS once the system boots up.

- 32-bit installable file system drivers supporting FAT,

FAT32, ISO 9660 (CD-ROM), ISO 13346 (Universal Disk Format

/Digital Video Disc [uDF/DVD]), network redirection, and

high performance. These file system drivers also support

the use of long file names and an open, modular architecture

to handle future expansion.

- WDM support, which allows a WDM-supported device to run

under both Windows 98 and future versions of Windows NT

using the same driver.

--------------

Note the second point in the above list.

> I do know that to be true of Windows 95 and I don't think that

> the Win32 API was reinvented with Windows 98, but I could be

> wrong...

If you could identify an information source, preferrably from

Micro$oft, where they state that some (or any) of the win-9x API or

Kernel is thunked 16-bit code, then please do.

It's highly likely that very eary versions of windows (windows 1 or 2,

maybe 3.0) had significant amounts of 16-bit code, but that seems to

have been completely changed to 32-bit code with windows 95.

A more detailed analysis of Win-95 is probably necessary to help

answer this 32-bit/16-bit issue.

This link:

http://www.microsoft.com/technet/archive/win98/reskit/part5/wrkc26.mspx?mfr=true

Says this:

---------------

Windows 95, Windows 95 OSR 2, and Windows NT Workstation 4.0 are

all 32-bit operating systems that use the same Win32 API.

Although the API has changed and expanded to encompass new

features, programs will, in most cases, work without modification

on all three operating systems.

----------------

The first sentence in the above is very key to this discussion.

So it appears that you are wrong when you say this:

> I do believe that the Window 9x Win32 API is mostly thunked down

> to 16-bit, that means that KERNEL32, USER32 and GDI32 are thunked

> down to their 16-bit counterparts, respectively those are thunked

> down to KRNL386, USER.EXE and GDI.EXE. In essence these core

> Windows 9x components are 16-bit code wrapped in 32-bit code,

> they aren't pure 32-bit like that of the NT family.

September 25, 2007

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

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

98 Guy wrote:

>>I do believe that the Window 9x Win32 API is mostly thunked down

>>to 16-bit, that means that KERNEL32, USER32 and GDI32 are thunked

>>down to their 16-bit counterparts, respectively those are thunked

>>down to KRNL386, USER.EXE and GDI.EXE. In essence these core

>>Windows 9x components are 16-bit code wrapped in 32-bit code,

>>they aren't pure 32-bit like that of the NT family.

I did say that I stood to be corrected but I was not completely wrong

with my post. From further findings and reading it appears that

Kernel32 doesn't thunk down unless it is running or spawns 16-bit

applications but Microsoft states that User32 and GDI32 are mostly

thunked down on W9x system. NT does not thunk down to 16-bit to run

these or to run 32-bit appliactions.

Understanding Win16Mutex

http://support.microsoft.com/kb/125867

Thunking on Windows 9x is more prevalent than you might think, other

examples shown here:

http://support.microsoft.com/kb/137813

http://support.microsoft.com/kb/137176

John

September 25, 2007

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

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

98 Guy wrote:

> Chapter 28 - Windows 98 Architecture

>

> Says this:

>

> "Microsoft Windows 98 is a 32-bit operating system that

> provides built-in Internet connectivity, Plug and Play

> hardware support, high performance, robustness, and backward

> compatibility with Windows 95. Windows 98 enhancements to

> Windows 95 include more sophisticated power management,

> multiple video display support, and integrated support for

> the latest hardware. Also included is support for the new

> Win32 Driver Model (WDM), allowing a WDM device to run under

> both Windows 98 and future versions of Windows NT using the

> same driver."

• Windows NT is a true 32-bit operating system, whereas Windows 9x

contains a considerable amount of 16-bit code that has been ported from

Windows 3.1.

http://www.microsoft.com/technet/archive/ntwrkstn/evaluate/featfunc/winarch.mspx?mfr=true

> And importantly, it goes on to say this:

>

> -------------

> Like Windows 95, Windows 98 is derived from the Windows 3.1...

Of course it is, it's half full of 16-bit code, and half the time it

runs on 16-bit components!

Now let us know where Windows 3.1 is derived from...

John

September 25, 2007

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

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

John John wrote:

> 98 Guy wrote:

>

>> How can a 32-bit, protected-mode, multi-tasking operating system be

>> "built upon" a 16-bit, real-mode, single-tasking operating system?

>

> To further my other post, it uses Win16Mutex.

And yet more information about thunking and those famous win16mutex

http://www.radsoft.net/resources/rants/20000321,00.shtml

John

September 26, 2007

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)

98 Guy wrote:

| PCR wrote:

|

|> | the fact remains that win-98 can be "built" onto (into?) an

|> | empty hard drive - which would mean that win-98 is not

|> | "built on-top of DOS".

|>

|> I disagree with that statement.

|

| How so?

|

|> IF an important amount of Win98 code is actually copied over

|> from DOS code,

|

| That statement that you disagree with doesn't talk about code history

| or code integration.

I'm just saying an examination of the lines of code that make up Win98

is warranted. If there are important similarities to DOS code (meaning

the actual machine instructions that do the work), then it can be said

Win98 is "built upon DOS". Soon, I will closely examine MEB's monster

post to see whether he has proven it!

|> IF an important amount of Win98 code is actually copied over

|> from DOS code,

|

| Do you even know what DOS is?

In the end, all programming languages are a series of machine

instructions thrown at the CPU (Central Processing Unit).

| Win-98 is many mega-bytes of 32-bit protected-mode code. DOS is (at

| best) several hundred kbytes of 16-bit real-mode code.

For the purpose of determining whether Windows is built upon DOS, the

processing mode doesn't matter all that much. New instructions must be

added to set up a virtual environment. But, when it comes to reading &

writing files within a virtual machine, for instance,-- are the

instruction sequences put into the CPU to an important degree the same?

There is thunking down that John John brought up to be considered too.

|> I think it could be said Win98 is "built on top of DOS".

|

| Saying that is as farcical as saying that iPhone is "built on top of"

| the iPod.

I know nothing of iPod & iPhone.

|> I doubt it-- BUT my mind is open, pending Colorado & Phillipson

|> have scoured Win98's two million lines of code for evidence!

|> I think I owe them that much!

|

| So basically you're saying that it would take an examination of win-9x

| source code to convince you that win-9x is NOT "based" or "built" upon

| DOS, and further that you expect such an examination to be performed

| by someone that is conspiciously absent from this thread?

It looks like MEB has taken up the gauntlet! It's a matter of whether

DOS code is called by Windows &/or whether the code has been

incorporated into Windows code. If either is true to an important

degree, then Windows can be said to be "built upon DOS". It may take 30

days to read through MEB's post, though, for the final answer! I see you

have begun!

| (I can't tell if you're serious, or not).

I'm always at least 37% serious & at least 13% comic!

|> | Again, read the Microsoft quote (above). I think that IO.SYS

|> | is one of those DOS components that is indeed running in a

|> | virtual 8086 environment, but only to provide a handful of

|> | functions for legacy apps.

|>

|> IO.sys is the first program loaded during boot (it is mentioned

|> in the Partition Boot Record), & it is loaded before Win98 is

|> started. I don't think a virtual machine can exist until then.

|

| IO.sys may be fully loaded prior to win.com being executed - but it is

| then most certainly nuked as the CPU is transitioned from real to

| protected mode. The only function of IO.SYS is as a boot loader.

IO.sys is DOS code that sets up the DOS environment by issuing a series

of commands that can be modified by entries in Config.sys &

Autoexec.bat. OI.sys will process those files & even the Registry during

boot. It has a lasting effect to Windows DOS (in a box). Also, remember

what Zabcar proved-- Windows can be loaded from Real DOS, & Real DOS

STILL is there after Windows is shut down!

I believe it is IO.sys that carries out the interactive startup, if

chosen from the boot menu. See p.103 of Windows 98 Secrets (Livingston &

Straub) for more. Well, here is something from p.104...

"(IFSHLP.sys) is the helper file for the installable file system. This

is needed for the Virtual File Allocation Table (VFAT) file system that

Windows 98 uses to imitate the standard DOS and Windows FAT file system

and still store long filenames."

Just how much "imitation" is done? If it is an overly significant

amount-- then it could be said Win98 is "built upon DOS".

| Windows 9x uses (a new version of) IO.SYS, which replaces the MS-DOS

| system files (IO.SYS and MSDOS.SYS).

What page of what fat book says that?

| The actual underlying core of

| win-9x is the virtual machine manager (vmm32.vxd). Most likely, the

| DOS functions mentioned previously are handled by DOSMGR.VXD (the

| MS-DOS Emulation Manager) and V86MMGR.VXD (the MS-DOS Memory Manager).

I'm sure all of that is a significant addition to DOS, but how much DOS

code was incorporated into it, if any? Could be some of the answer is in

MEB's post. I'll be back in 32 days after reading it!

|

|> Also, didn't Zabcar say...

|> ... he could go from IO.sys to Real DOS, load Windows with

|> WIN, & have Real DOS available after Windows was closed?

|

| No - all he said was that he could force win-98 to NOT load with the

| appropriate .ini file setting.

He forced it not to load automatically in MSDOS.sys. Then, he put the

WIN command into Autoexec.bat, which did load Windows. After Windows was

shut down-- DOS was still there waiting for additional commands!

|> Therefore, I lean toward the belief Real DOS code is always

|> present & available.

|

| What do you mean by "DOS code" ???

I mean the machine language code that DOS is translated into. All

programming languages ultimately must become machine language code fed

to the CPU one instruction at a time.

| Are you aware that "real DOS code" can only run in a virtual x86

| environment - an environment that is set up and controlled by Windows?

Once a virtual envirronment is established, you have kind of multiple

machines all sharing the single CPU. Is the code running in one of the

machines to some important extent dependent on DOS or even just copied

over from DOS? That is the question!

|> It's just a matter as to whether Win98 actually requires it

|> to be present to function.

|

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

I believe that. In their effort to be compatible, how much of Real DOS

has survived that is important to the functioning of Windows?

--

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

September 27, 2007

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

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

September 27, 2007

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)

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

September 27, 2007

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

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

September 28, 2007

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

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.

September 28, 2007

Re: How to uninstall a dual configuration with Windows2000pro

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

September 28, 2007

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

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%5Fpietrek/

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

September 28, 2007

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

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.

September 28, 2007

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

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

September 28, 2007

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)

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

________

September 29, 2007

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

| 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

Sign In

How to uninstall a dual configuration with Windows2000pro

Recommended Posts

Guest PCR

Popular Days

Popular Days

Guest 98 Guy

Guest PCR

Guest MEB

Guest 98 Guy

Guest 98 Guy

Guest MEB

Guest John John

Guest John John

Guest John John

Guest 98 Guy

Guest John John

Guest John John

Guest John John

Guest PCR

Guest John John

Guest PCR

Guest John John

Guest 98 Guy

Guest LACV

Guest John John

Guest 98 Guy

Guest John John

Guest MEB

Guest PCR

Browse

Activity

Site Info