Ok i have a W98 boot disk. I need to disable the F8 startup menu. This can be done with 6.22 by editing MSDOS.SYS and putting 0 on certain Boot [Options]. This has no effect on W98 disk and actually makes it hang. I thought if i can patch IO.SYS to disable F8. It could even be command.com but i believe it be IO.SYS as that gets loaded after. I looked up the keyboard scan codes and hex 42 00 is coming up on F8. I also looked up what interrupts use the keyboard. INT9 INT21 and INT16 seem to be the ones. I went through the code and 4200 comes up a few times but too many times. Does anyone have a clue on assembler or can help me find the right opcode to patch. Thanks.

Whats the big deal disabling F8? Why do you have a 98 startup disk anyway? Why do you even have a floppy drive!!

You can use an XP or vista disk and use the recovery console on it, same thing as a 98 boot disk anyway.

As for doing what you want, i doubt anyone here knows, we all moved long gone from that OS. Is it really that important, why would you need to disable the F8 menu?

We have not moved far on. What you think is on a bootable CD-ROM disk???...DOS!

I want to disable it for security reasons.

The entry you're thinking of is in msdos.sys. This disables the boot keys when booting from the hard drive. I'm not aware of anything you can change that will prevent boot keys from being used with a boot floppy or CD other than changing the boot order in the BIOS. That's only effective if your BIOS has password protection.

I'd also suggest that you post questions regarding 98 in the Windows 95/98/98SE/ME of this forum where you'll get far more useful and civilized answers.
Rick

Topic cleaned, please keep the rules in mind.

Also topic moved to 9x Forums, good luck

I just saw your thread over in computing.net and read it: "Subject: Io.sys disable f8".

I think you might solve your problem by using BCDW 1.50Z instead of JO.SYS to get the menu you want working from the CD and disable F8 via msdos.sys. I'm not saying it's going to be easy, but I think it can be done. HTH.

Obs.: As you're new to this forum, let me point out to you that the underlined parts in this post are clickable links.

First of all, the MSDOS.SYS file in DOS 6.22 is a binary file, while in Windows 9x it's just a text file. So, editing of the DOS 6.22 MSDOS.SYS file is not a very good idea.

In case of the Windows 9x MSDOS.SYS file there are some other problems related to removable media. The boot menu is always displayed, when there are no certain Windows files on the media and the MSDOS.SYS file does not contain just the ";SYS" line. This option tells IO.SYS to not to look for the windows files, and not to check registry files on boot. Adding any other line with settings will force the registry checks, back again. (Perhaps there is some way to prevent it, but I do not know how to do it).

This msdos.sys works:


... with JO.SYS absent, of course!

for the record, scrumpyjack seems to have found a way to solve his problem by patching IO.SYS:
http://www.boot-land.net/forums/?showtopic=4754

jaclaz

I think I got lost somewhere in this thread.

Windows 98 boot DOS files are IO.SYS MSDOS.SYS and COMMAND.COM. I have not heard about JO.SYS, so far.

Without IO.SYS there is no Windows 98 boot possible, so there will be no F8 function, for sure.

So, what particular OS version are we speaking about?

JO.SYS is the file that allows for "press any key to boot from CD" (or something like that) on Windows 9x 98/Me CD's.

There is an "original" one and a "free" version by Bart Lagerwej.

Read the referenced thread on boot-land.

jaclaz

Well. Not exactly. I've just updated my knowledge in this matter.

I've been using Windows 95 boot disks mostly and I did not pay attention to the differences between Windows 95 and 98.

The Windows 95 IO.SYS does not support the JO.SYS, while the Windows 98 IO.SYS calls JO.SYS if available. Also Windows 95 always checks for registry files if the MSDOS.SYS file has some settings in it. Windows 98 acts differently in this matter.

Fixed.

jaclaz

Well, so far we have the exact same May 24 post by scrumpyjack here, at boot-land, and at computing.net (there as markreflex), by my reckoning... Where else did he post? He seemed really desperate... Then he solves the problem by himself in two days??? It really does remind me the Chewbacca Defense: it makes no sense!

Apart the Chewbacca Defense, which was a nice read , I see nothing that makes no sense :

1. A user posts a question
2. Noone is able to give him a simple and working solution
3. He finds the solution himself, the hard way (hexediting a system file)

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?

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

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

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.

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:

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

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

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?

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

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

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

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?



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

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

I've found it!
My original sugestion was:

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!

@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

Why?


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

No prob, no hurry , IO.SYS has stayed like it is for almost ten years......

jaclaz

to learn more plus i change F5 so Safe Mode is safer.

Because the Function keys routine is not held in JO.SYS.

@scrumpyjack

Floko84 has posted an interesting reply here:
http://www.boot-land.net/forums/?showtopic=4754

if it is confirmed to work with your setup, it could possibly avoid the need to hexedit IO.SYS.

jaclaz