[solved] There is any really WORK way to forbid 98SE installer write to MBR boot area?

[MERCURY127 8]

I use PART boot manager, which all fit to first sector and give me capability to select any primary partition from up to 4 on disk, to corrent boot by one key.
ie, i can select boot to dos & 98, xp, 7 or linux by one key.

but always after reinstall 98se its stupid installer rewrite MBR to standard MS code, as with fdisk /mbr...
as i can forbid do it?

i already try:
setup /ir switch,
setup /nltdr switch with C:\NTLDR file,
msbatch options
System
CCP
CleanBoot
with all values...

all it is helpless versus stupid power w98setup.bin/suwin.dll/setupx.dll.
there is any really work way?
or only patch for these binaries can help?

[jumper 72]

You're doing it backwards. Install 98se first, then PART. (If this doesn't work, then PART is the "stupid" one.)

[MERCURY127 8]

1 hour ago, jumper said:

Install 98se first, then PART

yes, sure, its obviously. until if u not reinstall 9x approx 17 times at one day...
me not need reinstall PART, as i can just restore MBR manually.
but i just want solve this stupid problem...
it is possble use 95 installer files for 98se distros?

Edited September 30 by MERCURY127

[jaclaz 1,057]

4 hours ago, MERCURY127 said:

yes, sure, its obviously. until if u not reinstall 9x approx 17 times at one day...

That is the worst case of installitis I ever heard .

Anyway, it takes literally a fraction of a second to restore the MBR, and you can well make such restore automated.

Alternatively, hunt for the MBR code in the Windows Setup or OS files (it must be copied from *somewhere*) and replace it with your PART code (and yes this is anyway a "binary patch").

But - come on - this is not a "problem".

jaclaz

[MERCURY127 8]

1 hour ago, jaclaz said:

That is the worst case of installitis I ever heard .

heh :)
No, you misunderstood.
I did not say that all 17 re-installations were unsuccessful.
in fact, I did not even wait until they ran out, I just rebooted the computer when I saw that there was no success.
why? I bought a wireless kit recently, and now I'm trying modify usb.inf from NUSB to get 98 to install usbccgp.sys during the installation so that the system does not lose control when legacy is no longer working, but the HID does not work yet, because the Composite USB device does not work, because the usbccgp.sys was not copied.

[MERCURY127 8]

2 hours ago, jaclaz said:

But - come on - this is not a "problem". 

it is PROBLEM, if u need 98 only for sporadic experiments...
for sample, after her MBR intrusion was not load Win7, even if 7 installed on other physical disk.

[jaclaz 1,057]

5 minutes ago, MERCURY127 said:

it is PROBLEM, if u need 98 only for sporadic experiments...
for sample, after her MBR intrusion was not load Win7, even if 7 installed on other physical disk.

Ok, then it is a problem, but still an easily solvable one (by restoring the MBR).

Your actual problem is having the stupid install take care of usbccgp.sys

jaclaz

[MERCURY127 8]

6 minutes ago, jaclaz said:

but still an easily solvable one (by restoring the MBR).

once - easily.
three times - a little annoying.
seventeen times - would kill...

[rloew 121]

It can be a nuisance. Between this and other problems I have had with SETUP, I no longer use it for normal Installations.

When I do a long run of experiments with SETUP, I don't bother to restore my MBR until I have completed the entire set.

[MrMateczko 30]

On 9/30/2018 at 4:55 PM, jaclaz said:

That is the worst case of installitis I ever heard .

Nah, I'm pretty sure I had days when I've installed 98SE more than 17 times   That's how I've memorized the full 98SE OEM CD-Key by now, very useful skill.

As for the problem, I know why MERCURY127 is annoyed, in fact, all Windows versions really like to completely overwrite MBR and cause annoyance.

Would be interesting to know at what EXACT point does Setup program modify the MBR in the first part of the install.

Making a backup and restoring it whenever you need a fresh start is easiest workaround, since 98SE really doesn't care about anything else than the registry (system/user.dat), the DOS environment (io.sys/command.com), the MBR, and the OS files itself. All those things, except the MBR, are very easy to backup/restore, best time to do a backup is right after the first part of install, since no PC specific stuff has been done by then (hardware detection and user settings).

Something like a restore.bat file that reverts everything at command in pure DOS is something I would have done in your case.

That's just my few cents/rubles

 

Edited October 1 by MrMateczko

[MERCURY127 8]

1 hour ago, MrMateczko said:

Something like a restore.bat file that reverts everything at command in pure DOS is something I would have done in your case.

no problems...

MBR.zip

[MrMateczko 30]

I was talking about reverting the Windows 98 OS files, not the MBR.

[MERCURY127 8]

yes, i think about this... many times. but these three files is 16 bit NE files (win3x binaries). it is very hard to patch...
many code segments. many data segments. far calls. also in win3x world is usual thing - do DOS calls for disk operations.
its real hacker's nighmare...

[jaclaz 1,057]

What happens (or should happen) *sometimes* during the setup is that a command (not entirely unlike dd) is used to overwrite the first 440 bytes of the MBR (i.e. first absolute sector or sector LBA0) and possibly the magic bytes 55AA.

To be copied these 440 bytes must exist *somewhere* (possibly also with an ending 55AA) most probably embedded in this (or that) file.

The file in question (again very likely) is connected with partitioning, and as a first attempt I would look inside FDISK.EXE...

...  hey, wait, it is there and it is actually documented by The Starman:

https://thestarman.pcministry.com/asm/mbr/FDISK.htm

https://thestarman.pcministry.com/asm/mbr/95BMEMBR.htm#CHS

the issue is that it is "interspersed" with some unknown bytes and there is a "hole" for the error messages (that can still be found in FDISK, but at another address) and another "hole" for the partition data (just before the ending 55AA), and there are the mistery 00 bytes:

https://thestarman.pcministry.com/asm/mbr/mystery.htm

In a nutshell, and if you have - besides the time - the guts for it, you could test if:

1) your current MBR code is compatible (or can be made compatible) with the "segmentation" with which the original MBR is stored inside FDISK
2) if yes, if when you change ALL instances of the MBR code inside FDISK (and probably you will also need to modify the "error messages") FDISK (from a boot floppy or however from a pure DOS) does actually manage to write your modified MBR code (or throws a checksum error or whatever
3) if the above works, try if setup actually uses the data strored inside FDISK or gets the bytes from somewhere else, and if this latter is the case, look for the file that contains it (maybe a .dll?), rinse and repeat.

jaclaz

 

[MERCURY127 8]

I not think that installer use fdisk for write mbr...