Disable F8 Win98 Boot Disk Startup Menu

[dencorso]

[...]

The only thing he did I wouldn't have done is to post on three different forums the same question.

jaclaz

And you certainly would've posted the solution, once you found it, I'm sure!

Well, now I'm already past rant mode, but I think I ought to tell what doesn't make sense to me, anyway, so let's see:

1) The *ONLY* reason I can think of for posting the same problem in 3 forums is sheer desperation.

Then again, one who is able to reverse-engeneer IO.SYS in two days had no reason to be so desperate...

2) Why reverse IO.SYS, which is system-critical and 222670 bytes long, when doing so to JO.SYS, which is not system-critical and is just 2048 bytes long ought to accomplish the desired result?

[jaclaz]

A reply with the solution was made here :

http://www.boot-land.net/forums/index.php?...=4754&st=10

(though I don't seem to find the address in order to try and replicate it)

jaclaz

[dencorso]

Well, I guess this thread really became tridimensional, stretched over three different forums...

Turns out that scrumpyjack used the original Win 98 FE IO.SYS 222390 05/11/1998 21:01, which is the only one to have 01 at offset 84DB...

Now, there are 4 Win 98 IO.SYSs:

Win 98 FE IO.SYS 222390 05/11/1998 21:01 (Win 98FE original)

Win 98 FE IO.SYS 222670 11/30/2001 15:31 (Win 98FE Q311561)

Win 98 SE IO.SYS 222390 04/23/1999 22:22 (Win 98SE original)

Win 98 SE IO.SYS 222670 12/01/2001 09:37 (Win 98SE Q311561)

In all four, just search for the hexadecimal string 3E 01 B4 01 CD 16 75 and change only the 01 marked in red to 00. It should work. I do, however, strongly advise the use of the Q311561 versions. It's still available from Microsoft (link), and Petr (link) localized it to lots of languages, including Italian, because, you see, Microsoft put the English version, by mistake, in most of the localized versions they offer. BTW, Petr remarks that both Q311561 versions are binarily identical.

I've tested it. That patch presents problems:

1) If, after selecting "boot from floppy disk", you don't press any key IO.SYS will wait forever for any key...

That is due to having substituted INT 16 service 01 for service 00 (it effectively consumes any keystroke, but will wait forever for a keystoke if there isn't any in the buffer). This is easy to solve: instead of scrumpyjack's patch, do patch the red bytes in 3E 01 B4 01 CD 16 75 XX to be 3E 01 B4 01 CD 16 90 90, and the wait is removed.

2) In the original patch, if, after selecting "boot from floppy disk", one presses and holds <Ctrl> until "Starting Windows ...", then press any key, IO.SYS will go straight to the boot menu. My proposed patch eliminates the need to press any key, but doesn't prevent IO.SYS from going to the boot menu when one holds <Ctrl>. And then there is also <Shift> to consider, which I did not test...

Edited June 6, 2008 by dencorso

[scrumpyjack]

Hello,

I didn't realise it was such a small world between the 3 forums as the net is a vast place. I also did that to test the knowledge of the forums. Apologies for that. It seems there's few DOS forums these days. I had failed to find any, seems they all died out. When you mention DOS they think of CMD box in XP! It nice to read the interesting comments as i didn't expect too much response especially after the first negative comment the mods deleted. I tried another forum trying to find users who have decent knowledge. I guess my impatience and asking a far out question and getting questions on why do that instead of help i decided to study and go it alone. Yes i should of waited longer for a response but i was uncovering more at the same time and i was trying to grasp assembler. As IO.SYS is DOS related i posted on Computing.net as i was hoping for DOS diehards such as Secret Doom, Laurence types of old with the tricks, knowledge would know but seems less frequent in these times. In the end my desperation helped me push forward and discover more. Rest assured i wont post on forums like that and i didn't post on anymore than what you know about.

Thank you all for helping and for dencorso's informative entertaining comments and Hello to Jaclaz here too .

@dencorso

thank you for your help. yes the patch is not satisfactory and as i said on Jaclaz forum i need to improve, but just 1 byte disables all the main keys apart from the shift and needs to be held down. I scraped that. I will have a better solution. Your patch goes to the boot menu in essence making Jo.Sys still work which is what i what i accomplished with the patch i did. You say it will wait forever, yet if the key is pressed 2x or held down it works but is not ideal. I guess this is flooding the buffer is it not. If the menu in IO.SYS was really seen as disabled by IO.SYS, Jo.sys would not work which comes into effect when MSDOS.SYS is modified with BootKeys=0.

Edited May 27, 2008 by scrumpyjack

[dencorso]

scrumpyjack, you are quite welcome here! And you're evidently quite talented if this was your first foray with assembly language. To tackle IO.SYS and get something working out of it is no easy feat. So please do hang around, for you're certainly the type of member we need most: one with disposition to confront the problems and come out of it with solutions. Do however check my previous post, I've updated it with more info and think your patch still needs some perfecting. Good luck!

@scrumpyjack: I said your patch will wait forever, unless any one key is ever pressed.

The alternative patch that I proposed does the same as yours, but does not wait for any key.

Here's the original code:

B4 01		mov	ah, 1
 CD 16		int	16h	
 75 XX		jnz	somewhere

Your patch changed mov ah, 1 to move ah, 0 (efectively causing ZF to be always 1), so the next jnz never executes.

But service 0 of INT 16 waits for a character.

My proposal was to substitute the actual jnz XX by nop nop, so that there is no jnz to execute. The effect is exactly the same. But my proposed patch doesn't wait for a character.

BTW, IO.SYS may be getting the state of <Ctrl> and <Shift> directly from the BIOS data area at 0:0417H and/or 0:418, instead of using INT16 to do it. But I think it's not: there is a routine using service 02 of INT16 just above the one you patched...

Edited May 27, 2008 by dencorso

[scrumpyjack]

@dencurso

Thanks for the welcome and the update. This is a project that i have learned alot and has been fun and interesting. Patching that jump is better, works good and I see why thanks for the explanation.

I read your comments it coming from the BIOS about the Shift. It is harder to trace. Patching the Shift key in the same routine as the others does nothing. It seems the Shift is in a far off location to the rest of the other routines. Not to be outdone i have managed to null the Shift from acting out but it still loads 'Windows is bypassing your startup files.` This must be being programmed before.

Edited May 27, 2008 by scrumpyjack

[Drugwash]

If the call to INT16 is useless anyway, why not just jump it altogether?

Use JMP <past the JNZ> instead of MOV AH, 1. Wouldn't that be feasible?

[scrumpyjack]

@Drugwash

sure that works too at the time there were several jumps going back. changing JE to JNE or vice versa at several places has the same effect of course. instead of lots of NOPS everywhere i was trying to do a smarter patch and take out the value.

Edited May 27, 2008 by scrumpyjack

[scrumpyjack]

I initially thought using INT9 would intercept the keys. Researching IO.SYS there is snippets of IO.SYS but no full disassembly. I found alittle source code and old viruses that inserted themselves into the free space of it. Finding a dos debugger is another task but that was before i found out more.

If you want to help along, expand your knowledge, or crazy enough. here is some useful key scan codes of BIOS and DOS interrupts.

http://members.tripod.com/~Vitaly_Filatov/...sm/asm_021.html

http://www.htl-steyr.ac.at/~morg/pcinfo/ha...ts/inte1at0.htm

http://courses.ece.uiuc.edu/ece390/books/a...html#HEADING1-5

The int 16h and it's flags.

http://courses.ece.uiuc.edu/ece390/books/a...html#HEADING3-1

Edited May 27, 2008 by scrumpyjack

[jaclaz]

Well, I guess this thread really became tridimensional, stretched over three different forums...

Can I try and make it four-dimensional?

Since I see there are still men doing their bytes "the old way" :

http://tinyapps.org/weblog/misc/2007022507..._in_my_day.html

Can you check my report on this patch for "better" LBA compatibility:

http://www.msfn.org/board/Patched-IOSYS-fo...ME-t118119.html

scrumpyjack

jaclaz

[scrumpyjack]

Well, I guess this thread really became tridimensional, stretched over three different forums...

If it make you happier. you can delete my thread at your forum as we the only 2 contributing members and i stick to this one as you visit here too . The real question is how many forums are you on at anyone time lol. Is it not triacontahedromensional?

Since I see there are still men doing their bytes "the old way" :

http://tinyapps.org/weblog/misc/2007022507..._in_my_day.html

that is very eerie. i was at that comical post several days ago and only discovered it through some obscure link. very amusing.

Edited May 27, 2008 by scrumpyjack

[scrumpyjack]

Can you check my report on this patch for "better" LBA compatibility:

http://www.msfn.org/board/Patched-IOSYS-fo...ME-t118119.html

no because that hijacks the thread and has nothing to do with my topic! just kidding! i pass that question onto dencorso.

Edited May 27, 2008 by scrumpyjack

[dencorso]

I've found it!

My original sugestion was:

patch the red bytes in 3E 01 B4 01 CD 16 75 XX to be 3E 01 B4 01 CD 16 90 90

OK, now I've found a second place to patch, in addition to that one:

Search for B4 02 CD 16 A8 07 74 and patch the red 74 to EB, and that takes care of <Shift> and <Ctrl>!

@scrumpyjack: Bear in mind that I'd have taken lots more of time to find it if you hadn't described your own patch. The biggest problem always is where to start looking, and it was you the one who found it!

[scrumpyjack]

@dencorso

that's great works a treat i had to wait an hour to test it as my keyboard wouldn't work lol, it all making sense. the ah,2 is asking the state of Shift and then testing for it. it plain as day now studying, but still learning. i was too busy patching the scan code 58 for Shift F5, rereading the article i posted it makes more sense. good teamwork and thanks again. what interests me now is turning off the @ ^Z on the keys. it be int21.

http://courses.ece.uiuc.edu/ece390/books/a...html#HEADING3-1

Edited May 28, 2008 by scrumpyjack

[dencorso]

what interests me now is turning off the @ ^Z on the keys. it be int21.

Why?

Can you check my report on this patch for "better" LBA compatibility:

http://www.msfn.org/board/Patched-IOSYS-fo...ME-t118119.html

@jaclaz: I was already thinking about studying it. The way the patch on Win ME was done seems particularly intriguing. I'll keep you posted, but it may take a while before I can work on it...

Edited May 28, 2008 by dencorso