Forum - DLL-files.com

On Thu, 30 Sep 2010 21:26:45 -0300, John John <audetweld@nbnot.nb.ca>
wrote:

>The Sys command will restore the Windows 98 boot sector and you will be
>able to boot to Windows 98 but you will no longer be able to boot to
>Windows XP, that is no big deal, the Fixboot command will restore the NT
>boot sector and allow you to boot Windows XP again. After you boot to
>the Windows 98 installation you can use the ancient debug command to
>recreate the BOOTSECT.DOS file then you can use the Fixboot command to
>rewrite the NT boot sector and return the boot process to ntldr.
>
>To use the DEBUG command to create the bootsect.dos file, from Windows
>98 start an MS-DOS Prompt and navigate to the root of the System drive.
> To start the Debug console type debug and press <Enter> then enter
>the following commands, (pressing <Enter> after each):
>
>L 100 2 0 1
>N C:\BOOTSECT.DOS
>R BX
>0
>R CX
>200
>W
>Q
>
>If you want you can copy and paste the above commands to a Notepad file
>then save the file as READ.SCR in the root folder, then once in the
>debug console you can just type READ.SCR and press <Enter> to run the
>commands automatically. Remember to navigate to the root folder (cd\)
>before you launch Debug.
>
>Note that the second number in the in the L line (L 100 # 0 1) indicates
>the drive letter of the Windows 98 partition (2 = C, 3 = D, 4 = E, and
>so on).
>
>L 100 2 0 1

I've been reading and reading to understand all this, and this line
still confuses me. If the address of the MBR is 0000 on the C/D hard
disk and its 512 bytes long, how come the line just above isn't
L 200 2 0 1 ?

Between 0000 and 0100 are only 256 bytes. Doesn't there need to be
room for 512?
>
>assumes that Windows 98 is on C:.
>
>After you create the Bootsect.DOS file use the Recovery Console's
>Fixboot command to rewrite the NT boot sector to the partition and
>return the boot to the NT boot manager (ntldr), you should then be able
>to boot both operating systems. The boot.ini file contains the entries
>for both operating systems, typically:
>
>[boot loader]
>timeout=15
>default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
>[operating systems]
>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows XP" /fastdetect
>C:\="Microsoft Windows 98"
>
>John

mm wrote:
> On Thu, 30 Sep 2010 21:26:45 -0300, John John <audetweld@nbnot.nb.ca>
> wrote:
>
>> The Sys command will restore the Windows 98 boot sector and you will be
>> able to boot to Windows 98 but you will no longer be able to boot to
>> Windows XP, that is no big deal, the Fixboot command will restore the NT
>> boot sector and allow you to boot Windows XP again. After you boot to
>> the Windows 98 installation you can use the ancient debug command to
>> recreate the BOOTSECT.DOS file then you can use the Fixboot command to
>> rewrite the NT boot sector and return the boot process to ntldr.
>>
>> To use the DEBUG command to create the bootsect.dos file, from Windows
>> 98 start an MS-DOS Prompt and navigate to the root of the System drive.
>> To start the Debug console type debug and press <Enter> then enter
>> the following commands, (pressing <Enter> after each):
>>
>> L 100 2 0 1
>> N C:\BOOTSECT.DOS
>> R BX
>> 0
>> R CX
>> 200
>> W
>> Q
>>
>> If you want you can copy and paste the above commands to a Notepad file
>> then save the file as READ.SCR in the root folder, then once in the
>> debug console you can just type READ.SCR and press <Enter> to run the
>> commands automatically. Remember to navigate to the root folder (cd\)
>> before you launch Debug.
>>
>> Note that the second number in the in the L line (L 100 # 0 1) indicates
>> the drive letter of the Windows 98 partition (2 = C, 3 = D, 4 = E, and
>> so on).
>>
>> L 100 2 0 1
>
> I've been reading and reading to understand all this, and this line
> still confuses me. If the address of the MBR is 0000 on the C/D hard
> disk and its 512 bytes long, how come the line just above isn't
> L 200 2 0 1 ?

I seem to recall that when you use Debug to load, it defaults to an IP
address offset of 0100 hex. The segmented address offset for instruction
pointer IP is being preset to 0100 hex, which was standard policy, but I
can't recall why now. (The full Intel segmented address being specified in
the CS:IP registers or memory)

> Between 0000 and 0100 are only 256 bytes. Doesn't there need to be
> room for 512?

The length doesn't get specified when you use the L (load) Debug command.
Debug loads it into memory until it reaches the end byte (some EOF marker).

You can read up on the DEBUG command (via google).

Bill in Co wrote:
> mm wrote:
>> On Thu, 30 Sep 2010 21:26:45 -0300, John John <audetweld@nbnot.nb.ca>
>> wrote:
>>
>>> The Sys command will restore the Windows 98 boot sector and you will be
>>> able to boot to Windows 98 but you will no longer be able to boot to
>>> Windows XP, that is no big deal, the Fixboot command will restore the NT
>>> boot sector and allow you to boot Windows XP again. After you boot to
>>> the Windows 98 installation you can use the ancient debug command to
>>> recreate the BOOTSECT.DOS file then you can use the Fixboot command to
>>> rewrite the NT boot sector and return the boot process to ntldr.
>>>
>>> To use the DEBUG command to create the bootsect.dos file, from Windows
>>> 98 start an MS-DOS Prompt and navigate to the root of the System drive.
>>> To start the Debug console type debug and press <Enter> then enter
>>> the following commands, (pressing <Enter> after each):
>>>
>>> L 100 2 0 1
>>> N C:\BOOTSECT.DOS
>>> R BX
>>> 0
>>> R CX
>>> 200
>>> W
>>> Q
>>>
>>> If you want you can copy and paste the above commands to a Notepad file
>>> then save the file as READ.SCR in the root folder, then once in the
>>> debug console you can just type READ.SCR and press <Enter> to run the
>>> commands automatically. Remember to navigate to the root folder (cd\)
>>> before you launch Debug.
>>>
>>> Note that the second number in the in the L line (L 100 # 0 1) indicates
>>> the drive letter of the Windows 98 partition (2 = C, 3 = D, 4 = E, and
>>> so on).
>>>
>>> L 100 2 0 1
>> I've been reading and reading to understand all this, and this line
>> still confuses me. If the address of the MBR is 0000 on the C/D hard
>> disk and its 512 bytes long, how come the line just above isn't
>> L 200 2 0 1 ?
>
> I seem to recall that when you use Debug to load, it defaults to an IP
> address offset of 0100 hex. The segmented address offset for instruction
> pointer IP is being preset to 0100 hex, which was standard policy, but I
> can't recall why now.

The reasons are legacy ones, coming together with .com files from CP/M
through DOS. The first 256 bytes were execution vectors (system calls) and
system data, and the program started at $100. I still have the CP/M docs in a
box somewhere.

--
You'd be crazy to e-mail me with the crazy. But leave the div alone.
--
Whoever bans a book, shall be banished. Whoever burns a book, shall burn.

Patok wrote:
> Bill in Co wrote:
>> mm wrote:
>>> On Thu, 30 Sep 2010 21:26:45 -0300, John John <audetweld@nbnot.nb.ca>
>>> wrote:
>>>
>>>> The Sys command will restore the Windows 98 boot sector and you will be
>>>> able to boot to Windows 98 but you will no longer be able to boot to
>>>> Windows XP, that is no big deal, the Fixboot command will restore the
>>>> NT
>>>> boot sector and allow you to boot Windows XP again. After you boot to
>>>> the Windows 98 installation you can use the ancient debug command to
>>>> recreate the BOOTSECT.DOS file then you can use the Fixboot command to
>>>> rewrite the NT boot sector and return the boot process to ntldr.
>>>>
>>>> To use the DEBUG command to create the bootsect.dos file, from Windows
>>>> 98 start an MS-DOS Prompt and navigate to the root of the System drive.
>>>> To start the Debug console type debug and press <Enter> then enter
>>>> the following commands, (pressing <Enter> after each):
>>>>
>>>> L 100 2 0 1
>>>> N C:\BOOTSECT.DOS
>>>> R BX
>>>> 0
>>>> R CX
>>>> 200
>>>> W
>>>> Q
>>>>
>>>> If you want you can copy and paste the above commands to a Notepad file
>>>> then save the file as READ.SCR in the root folder, then once in the
>>>> debug console you can just type READ.SCR and press <Enter> to run the
>>>> commands automatically. Remember to navigate to the root folder (cd\)
>>>> before you launch Debug.
>>>>
>>>> Note that the second number in the in the L line (L 100 # 0 1)
>>>> indicates
>>>> the drive letter of the Windows 98 partition (2 = C, 3 = D, 4 = E, and
>>>> so on).
>>>>
>>>> L 100 2 0 1
>>> I've been reading and reading to understand all this, and this line
>>> still confuses me. If the address of the MBR is 0000 on the C/D hard
>>> disk and its 512 bytes long, how come the line just above isn't
>>> L 200 2 0 1 ?
>>
>> I seem to recall that when you use Debug to load, it defaults to an IP
>> address offset of 0100 hex. The segmented address offset for
>> instruction
>> pointer IP is being preset to 0100 hex, which was standard policy, but I
>> can't recall why now.
>
> The reasons are legacy ones, coming together with .com files from CP/M
> through DOS. The first 256 bytes were execution vectors (system calls) and
> system data, and the program started at $100. I still have the CP/M docs
> in a
> box somewhere.

I'm surprised they could fit that all into 256 bytes. I presume they then
used JMP instructions (probably just relative jumps) to jump outside of that
limited area for the actual system call code.

I assume they reserved the *first* 256 bytes (0000-00FF), because that way
that space would be guaranteed to be available, and as a bonus, it wouldn't
matter how large the theoretical address range actually was (16 bit or
whatever), as it would always be the lowest address range.

Another alternative would have been to reserve and use the last upper byte
range (FF00-FFFF for a 16 bit word), but I think that area was reserved for
(and used by) the stack.

Bill in Co wrote:
> Patok wrote:
>> Bill in Co wrote:
>
>>> I seem to recall that when you use Debug to load, it defaults to an IP
>>> address offset of 0100 hex. The segmented address offset for
>>> instruction
>>> pointer IP is being preset to 0100 hex, which was standard policy, but I
>>> can't recall why now.
>> The reasons are legacy ones, coming together with .com files from CP/M
>> through DOS. The first 256 bytes were execution vectors (system calls) and
>> system data, and the program started at $100. I still have the CP/M docs
>> in a
>> box somewhere.
>
> I'm surprised they could fit that all into 256 bytes. I presume they then
> used JMP instructions (probably just relative jumps) to jump outside of that
> limited area for the actual system call code.

Yes, obviously. It was just for the addresses of the interrupt vectors and
the system calls. Plus the File Control Block was there. Turns out the manual is
actually available online, here is the section with the memory map:

http://www.iso.port.ac.uk/~mike/interes ... l/ch5.html

But the jumps were, of course, absolute.


> I assume they reserved the *first* 256 bytes (0000-00FF), because that way
> that space would be guaranteed to be available, and as a bonus, it wouldn't
> matter how large the theoretical address range actually was (16 bit or
> whatever), as it would always be the lowest address range.

Actually that was the place that the hardware interrupts and breaks went to.
It was the supposed mechanism for 8080 systems to use for calling the OS, but
they didn't quite use it in CP/M. DOS made a better use of the mechanism, until
Windows reneged again.

--
You'd be crazy to e-mail me with the crazy. But leave the div alone.
--
Whoever bans a book, shall be banished. Whoever burns a book, shall burn.

Patok wrote:
> Bill in Co wrote:
>> Patok wrote:
>>> Bill in Co wrote:
>>
>>>> I seem to recall that when you use Debug to load, it defaults to an IP
>>>> address offset of 0100 hex. The segmented address offset for
>>>> instruction
>>>> pointer IP is being preset to 0100 hex, which was standard policy, but
>>>> I
>>>> can't recall why now.
>>> The reasons are legacy ones, coming together with .com files from CP/M
>>> through DOS. The first 256 bytes were execution vectors (system calls)
>>> and
>>> system data, and the program started at $100. I still have the CP/M docs
>>> in a box somewhere.
>>
>> I'm surprised they could fit that all into 256 bytes. I presume they
>> then
>> used JMP instructions (probably just relative jumps) to jump outside of
>> that
>> limited area for the actual system call code.
>
> Yes, obviously. It was just for the addresses of the interrupt vectors
> and
> the system calls. Plus the File Control Block was there. Turns out the
> manual
> is actually available online, here is the section with the memory map:
>
> http://www.iso.port.ac.uk/~mike/interes ... l/ch5.html
>
> But the jumps were, of course, absolute.

Ooops, my bad.
In retrospect, I think the relative jumps were limited to only half a byte
distance, i.e. +/-127 so that wouldn't help very much.

>> I assume they reserved the *first* 256 bytes (0000-00FF), because that
>> way
>> that space would be guaranteed to be available, and as a bonus, it
>> wouldn't
>> matter how large the theoretical address range actually was (16 bit or
>> whatever), as it would always be the lowest address range.
>
> Actually that was the place that the hardware interrupts and breaks went
> to.

(ok, now some of this is starting to come back to me

> It was the supposed mechanism for 8080 systems to use for calling the OS,
> but
> they didn't quite use it in CP/M. DOS made a better use of the mechanism,
> until Windows reneged again.

Thanks for refreshing my memory banks a tad. Hardware and software
interrupts - geesh, it's been a long time since I've visited this.

Bill in Co wrote:
> Patok wrote:
>> Bill in Co wrote:
>>> Patok wrote:
>>>> Bill in Co wrote:
>>>>> I seem to recall that when you use Debug to load, it defaults to an
>>>>> IP address offset of 0100 hex. The segmented address offset for
>>>>> instruction pointer IP is being preset to 0100 hex, which was
>>>>> standard policy, but I can't recall why now.
>>>> The reasons are legacy ones, coming together with .com files from CP/M
>>>> through DOS. The first 256 bytes were execution vectors (system calls)
>>>> and system data, and the program started at $100. I still have the
>>>> CP/M docs in a box somewhere.
>>> I'm surprised they could fit that all into 256 bytes. I presume they
>>> then used JMP instructions (probably just relative jumps) to jump outside
>>> of that limited area for the actual system call code.
>> Yes, obviously. It was just for the addresses of the interrupt vectors and
>> the system calls. Plus the File Control Block was there. Turns out the
>> manual is actually available online, here is the section with the memory
>> map:
>>
>> http://www.iso.port.ac.uk/~mike/interes ... l/ch5.html
>>
>> But the jumps were, of course, absolute.
>
> Ooops, my bad. In retrospect, I think the relative jumps were limited to only
> half a byte distance, i.e. +/-127 so that wouldn't help very much.

Your bad, indeed. The 8080 had /no/ relative jumps; they were introduced
in the Z80.
All addressing was absolute, and the locator had to fill in the final
absolute addresses. If you remember, the ISIS on the Intellec had to do 4 passes
before producing an executable - 2 pass assembler, the linker, and finally the
locator. I'm not sure, but I think the CP/M native setup was similar. On the
Apple ][ Softcard CP/M, which I was using, we had the improved Microsoft linker
L80, which combined linking and locating into one, and output the executable
..com file directly.

--
You'd be crazy to e-mail me with the crazy. But leave the div alone.
--
Whoever bans a book, shall be banished. Whoever burns a book, shall burn.

On Sun, 3 Oct 2010 21:54:42 -0600, "Bill in Co"
<surly_curmudgeon@earthlink.net> wrote:

>mm wrote:
>> On Thu, 30 Sep 2010 21:26:45 -0300, John John <audetweld@nbnot.nb.ca>
>> wrote:
>>
>>> The Sys command will restore the Windows 98 boot sector and you will be
>>> able to boot to Windows 98 but you will no longer be able to boot to
>>> Windows XP, that is no big deal, the Fixboot command will restore the NT
>>> boot sector and allow you to boot Windows XP again. After you boot to
>>> the Windows 98 installation you can use the ancient debug command to
>>> recreate the BOOTSECT.DOS file then you can use the Fixboot command to
>>> rewrite the NT boot sector and return the boot process to ntldr.
>>>
>>> To use the DEBUG command to create the bootsect.dos file, from Windows
>>> 98 start an MS-DOS Prompt and navigate to the root of the System drive.
>>> To start the Debug console type debug and press <Enter> then enter
>>> the following commands, (pressing <Enter> after each):
>>>
>>> L 100 2 0 1
>>> N C:\BOOTSECT.DOS
>>> R BX
>>> 0
>>> R CX
>>> 200
>>> W
>>> Q
>>>
>>> If you want you can copy and paste the above commands to a Notepad file
>>> then save the file as READ.SCR in the root folder, then once in the
>>> debug console you can just type READ.SCR and press <Enter> to run the
>>> commands automatically. Remember to navigate to the root folder (cd\)
>>> before you launch Debug.
>>>
>>> Note that the second number in the in the L line (L 100 # 0 1) indicates
>>> the drive letter of the Windows 98 partition (2 = C, 3 = D, 4 = E, and
>>> so on).
>>>
>>> L 100 2 0 1
>>
>> I've been reading and reading to understand all this, and this line
>> still confuses me. If the address of the MBR is 0000 on the C/D hard
>> disk and its 512 bytes long, how come the line just above isn't
>> L 200 2 0 1 ?
>
>I seem to recall that when you use Debug to load, it defaults to an IP
>address offset of 0100 hex. The segmented address offset for instruction
>pointer IP is being preset to 0100 hex, which was standard policy, but I
>can't recall why now. (The full Intel segmented address being specified in
>the CS:IP registers or memory)

Aha. Thanks a lot.

And I enjoyed reading about the legacy reason.
>
>> Between 0000 and 0100 are only 256 bytes. Doesn't there need to be
>> room for 512?
>
>The length doesn't get specified when you use the L (load) Debug command.
>Debug loads it into memory until it reaches the end byte (some EOF marker).
>
>You can read up on the DEBUG command (via google).

Well, like I say, I have been reading a lot of pages. I even dl'd a
tutorial and read it again, but they all start at the beginining and I
havent' found something long and detailed enough to have covered this
question.

Patok wrote:
> Bill in Co wrote:
>> Patok wrote:
>>> Bill in Co wrote:
>>>> Patok wrote:
>>>>> Bill in Co wrote:
>>>>>> I seem to recall that when you use Debug to load, it defaults to an
>>>>>> IP address offset of 0100 hex. The segmented address offset for
>>>>>> instruction pointer IP is being preset to 0100 hex, which was
>>>>>> standard policy, but I can't recall why now.
>>>>>
>>>>> The reasons are legacy ones, coming together with .com files from CP/M
>>>>> through DOS. The first 256 bytes were execution vectors (system calls)
>>>>> and system data, and the program started at $100. I still have the
>>>>> CP/M docs in a box somewhere.
>>>>
>>>> I'm surprised they could fit that all into 256 bytes. I presume they
>>>> then used JMP instructions (probably just relative jumps) to jump
>>>> outside
>>>> of that limited area for the actual system call code.
>>>
>>> Yes, obviously. It was just for the addresses of the interrupt vectors
>>> and
>>> the system calls. Plus the File Control Block was there. Turns out the
>>> manual is actually available online, here is the section with the memory
>>> map:
>>>
>>> http://www.iso.port.ac.uk/~mike/interes ... l/ch5.html
>>>
>>> But the jumps were, of course, absolute.
>>
>> Ooops, my bad. In retrospect, I think the relative jumps were limited to
>> only
>> half a byte distance, i.e. +/-127 so that wouldn't help very much.
>
> Your bad, indeed. The 8080 had /no/ relative jumps; they were
> introduced
> in the Z80.

Oh boy. Some Senility is evidently setting in.

I did a tad of maching code programming with the 8085, 6800, and 6502, but
it's fast fading. And I vaguely remember something about the 6502 and
"Page Zero" (6502 was used in the Apple II-E).

And also the 6800, which had no index register to use for a relative
addressing mode, which was very annoying (although I otherwise loved the
simplicity of its instruction set). I didn't have much hands-on experience
with the Z-80, but I do recall it was a *significant* step up. And as
I recall, that cheap Timex Sinclair used the Z-80, too. (That was a piece of
junk due to its membrane keyboard, although otherwise interesting)!

I also had a lot of fun with a VIC-20, both in BASIC and in some machine
language programming. ("HesMon" was an optional assembly language plug-in
card that really helped here) But no permanent storage for your programs,
though, unless you purchased an optional $$ cassette recorder for storage.
(So I just left in on for weeks at a time, until I bit the bullet, and
finally purchased that cassette recorder to store what I coded!)

> All addressing was absolute, and the locator had to fill in the final
> absolute addresses. If you remember, the ISIS on the Intellec had to do 4
> passes before producing an executable - 2 pass assembler, the linker, and
> finally the locator.

I vaguely recall something related to this. The *multistep* process, and
also getting and using a .LST file to debug the code. But I think the
assembler we used was for the newer 8085 (I was teaching an intro class on
this at a college).

> I'm not sure, but I think the CP/M native setup was
> similar. On the Apple ][ Softcard CP/M, which I was using, we had the
> improved Microsoft linker L80, which combined linking and locating into
> one,
> and output the executable .com file directly.
>
> --
> You'd be crazy to e-mail me with the crazy. But leave the div alone.
> --
> Whoever bans a book, shall be banished. Whoever burns a book, shall burn.

The Windows 98 boot sector (hidden file \bootsect.dos when dual
booting with Widows XP) contains information about the size of the
partition. So when you resized the partition, the Windows 98 boot
sector is no longer valid. Even if you are not dual booting.

I know
MiniTool Partition Wizard can support resize Windows 98
partitions. so maybe you can have a try,the site is:www.partitionwizard.com


Submitted via EggHeadCafe - Software Developer Portal of Choice
JustCode Visual Studio Development Add-In by Telerik
http://www.eggheadcafe.com/tutorials/as ... lerik.aspx

On Sun, 10 Oct 2010 01:20:30 GMT, Dragon <fishgld46@gmail.com> wrote:

>The Windows 98 boot sector (hidden file \bootsect.dos when dual
>booting with Widows XP) contains information about the size of the
>partition. So when you resized the partition, the Windows 98 boot
>sector is no longer valid. Even if you are not dual booting.

Uh huh. Thanks.

>I know

By bad experience?

>MiniTool Partition Wizard can support resize Windows 98
>partitions. so maybe you can have a try,the site is:www.partitionwizard.com

Thank you. I'm cautious now and I read the label. Like the Easeus
Partition Master that I'm 99% sure got me into this mess, this
software doesn't claim to work with win98 partitions. I"m sure it
will do fine with FAT32 etc. when the partition is empty, but it seems
that the boot sector varies with the OS, according to Partition
Manager 8 and that was written by them when I don't think there was
much competition that didn't also support win98.

Anyhow, thanks to the help I got here, I have the mbr and bootsect.dos
okay now, and I'm getting to win98 but getting a DOS-error when I'm
there. I get
> Sector not found reading drive C:
> Abort, Retry, Ignore, Fail?

when starting up the windows of win98, and if I only load DOS, I get a
similar sector error when I try to Edit many but not all editable
files in the win98 partition. Like .txt, .bat, and .ini files.

I may ask in DOS or win98, and if they don't know, I'll be back with a
new thread.

>
>Submitted via EggHeadCafe - Software Developer Portal of Choice
>JustCode Visual Studio Development Add-In by Telerik
>http://www.eggheadcafe.com/tutorials/as ... lerik.aspx