China DOS Union

The following is quoted from 不点's speech on 2003-11-20 16:02:38:
FAST DEFRAG, I found some software in google that can quickly defragment disks, I don't know how this one is:

http://www.techtv.com/callforhelp/freefile/story/0,24330,3425341,00.html

It is a free download. Has anyone used it?

Fast Defrag
Free up memory and optimize how your system uses RAM and the swap-file

to moderator Wengier:

I guessed from the beginning that you were abroad, hehe
The idea you mentioned is feasible, and the changes should not be too big. It is just that I am very lazy now and have no mind to modify the program. This kind of boot program is too troublesome to debug. At first I felt there was no big problem, so I did not use a virtual machine. After restarting several times,
I got really annoyed,
Later I could not stand it anymore and installed a vmware, and only then felt testing was easier.

The key is that I have not looked at the program for a long time, and I have forgotten how I wrote it. I am just afraid that once I change it, a pile of bugs will appear.
Do you know any good debugger or method for debugging boot code? I myself just use the most primitive print.

Looking forward to your recommending a good debugging method

The following is quoted from lyh728's speech on 2003-11-20 19:26:38:
to moderator Wengier:
         
   I guessed from the beginning that you were abroad, hehe

No need to guess....he is in Canada

If relying only on a software debugger, I think there should be no good way, or you can write some assembly macros similar to the print function, to simplify your print operation each time?

Sigh! Testing GRUB FOR DOS is a long-term, arduous, and complex task! Just to take good care of win98 takes a lot of time.

Below, take a look at part of my testing:

map --read-only (hd0) (hd0)

chainloader (hd0)+1

boot

The above command accesses the C: drive as read-only. 【For simplicity, from now on when we say C: drive we mean the first hard disk drive, not DOS's logical C: drive. Similarly, D: also means the second hard disk drive, not logical D: drive.】

I originally thought booting win98 this way would fail, but as a result, it actually succeeded! At the beginning of startup, two messages appeared:

write protect error writing drive C:

Abort, Retry, Fail ?

Pressing F can continue booting. After entering win98 this way, the C: drive is not write-protected and files can still be written. This was already expected. Since the C: drive does not use BIOS, the C: drive is no longer write-protected. What win98 performs on the C: drive is “protected-mode disk access”.

Look at this test again:

map --read-only --disable-chs-mode (hd0) (hd0)

chainloader (hd0)+1

boot

At this time, windows finally cannot start. After CHS is disabled, win98's startup program cannot find the C: drive. From this it can be seen that when win98 starts, it uses CHS mode to read the C: drive, not LBA mode.

Change it; this time use the D: drive, and look at this test:

map --read-only --disable-chs-mode (hd1) (hd1)

chainloader (hd0)+1

boot

This time it smoothly enters win98, and accessing the D: drive in win98 is normal. This is also expected, because what win98 performs on the D: drive is “protected-mode disk access”. So although DOS access to the D: drive may not work, it can be accessed under win98.

Look at this peculiar test again:

map (hd0) (hd1)

map (hd1) (hd0)

map (hd1,0)/dos.img (fd0)

chainloader (hd1)+1

boot

Swap the C: drive and D: drive. After entering win98, the A: drive cannot be accessed. This is because A: is still using BIOS, and in BIOS, A: is mapped to an area of (hd1). At this time, BIOS does not know that win98 has already swapped the hardware information of C drive and D drive; it still blindly goes to the original BIOS disk to look for its sectors, and of course cannot find them. At this time, if only reading the A: drive, it does not matter. However, if writing to the A: drive at this time, then it is extremely dangerous!!!! because it blindly writes to another wrong disk, and may destroy that entire disk. No matter how much is destroyed, even if only one sector is destroyed, it is wrong. We should also realize that if at this time only unimportant sectors are destroyed, then this is actually the worst, because we may not discover this is an error, and still think it is very normal!!

In short, win98's “protected-mode disk access” is a layer of disk access independent of BIOS. If not handled well, these two accesses will conflict and fight, and there is also a huge hidden danger. Therefore, all of us users must be careful, and because of this, our testing time will be dragged out very, very long. After all, safety first; better not to have this software than to have dangerous software.

There is a bit of a clue.

In c:\windows\ios.log, mbrint13.sys is listed. This shows that windows treats this emulation program as a virus (note: this point is certain), so it wants to destroy the A: drive!!!! (note: this is only a guess)

Searching for mbrint13 in google can find information in this area.

=========

Also, I found that grub_t07 and grub_t08 have a small BUG, causing the int13 extension function to cause a crash. It has been solved, but I will not release an update program now (because this BUG has little impact, so I will wait and update it together next time).

Support. I don't understand programming, so I cannot help, sorry.

Saying you do not understand programming is probably modesty. Learn a bit, and even if you cannot, you will have to. For example, I do not understand either, but a lot of materials can be found from google. In order to solve a problem, it can force you from not knowing to knowing.

This time windows treats the int13 hook program loaded before the MBR as a virus, causing many abnormal situations. Now I have found that using int13 under a DOS window is abnormal and gives wrong results. Very likely this is the final reason (I feel there is almost a 100% possibility that this is the reason). Now I have to consider debugging windows. I downloaded SoftICE, but have not installed it yet. I really hope there is a brother familiar with SoftICE to do this debugging. Sigh! SoftICE is very powerful, but I am not very familiar with it, and still do not know whether I can kill this BUG.

The following is quoted from 不点's speech on 2003-11-26 14:26:07:
Saying you do not understand programming is probably modesty. Learn a bit, and even if you cannot, you will have to. For example, I do not understand either, but a lot of materials can be found from google. In order to solve a problem, it can force you from not knowing to knowing.

This time windows treats the int13 hook program loaded before the MBR as a virus, causing many abnormal situations. Now I have found that using int13 under a DOS window is abnormal and gives wrong results, very likely this is the final reason (I feel there is almost a 100% possibility that this is the reason). Now I have to consider debugging windows. I downloaded SoftICE , but have not installed it yet. I really hope there is a brother familiar with SoftICE to do this debugging. Sigh! SoftICE is very powerful, but I am not very familiar with it, and still do not know whether I can kill this BUG.

You can try to add

mbrint13.sys

into \windows\ios.ini

under

to make Win98 think that mbrint13.sys is safe.

See if it works for you.

Thank you, Brother windrv. This has already been tried; must_chain, must_not_chain, etc. have all been tried, and none work. When using must_chain and thus using real mode mapper, win98 dies very early and cannot get in at all. windows determines this is a virus, and there is no way to load a protected-mode driver for it.

There is only one exception: OnTrack's geometry translation software can be recognized by windows, but I do not know how to make windows think the INT13 on the MBR is OnTrack's software.

The following is quoted from 不点's speech on 2003-11-26 18:36:14:
Thank you, Brother windrv. This has already been tried, must_chain, must_not_chain, etc. have all been tried, and none work, when using must_chain and thus using real mode mapper, win98 dies very early, and cannot get in at all. windows determines this is a virus, and there is no way to load a protected-mode driver for it.

There is only one exception: OnTrack's geometry translation software can be recognized by windows, but I do not know how to make windows think the INT13 on the MBR is OnTrack's software.

I am not a very technical man. But I remember one scenario when my staff developed one of our products as follows:

when we map or substitute one driver letter for another with our real-mode assembly DOS program, not using Windows' SUBST command; all drives enter into real-mode under Win98. However, when we call another DOS program doing something not essential within our DOS program before issuing win.com, after entering in Windows,Win98 can recognize all hard disk drives, using Protected Mode.

This is strange.

If we are not so busy, may be we can later learn from you what is happening.

I am not a very technical man. But I remember one scenario when my staff developed one of our products as follows:

when we map or substitute one driver letter for another with our real-mode assembly DOS program, not using Windows'''' SUBST command; all drives enter into real-mode under Win98. However, when we call another DOS program doing something not essential within our DOS program before issuing win.com,
after entering in Windows,Win98 can recognize all hard disk drives, using Protected Mode.

This is strange.

If we are not so busy, may be we can later learn from you what is happening

This line is too long and displays abnormally in my mozilla browser, so I broke it with carriage returns:

when we map or substitute one driver letter for another with our real-mode assembly DOS program,
not using Windows'''' SUBST command; all drives enter into real-mode under Win98. However, when
we call another DOS program doing something not essential within our DOS program before issuing
win.com, after entering in Windows, Win98 can recognize all hard disk drives, using Protected Mode.

＝＝＝＝＝＝＝

It is indeed strange, and I am also encountering this kind of problem for the first time. I think perhaps your technical staff can help me; after all, they have long dealt with things in this area. I feel, first, win98 may have bugs, especially the strange situation your company encountered, plus the situation we encountered here with int13, all illustrate this point. Second, there is also this possibility: win98 treats us as a virus, and it deliberately makes the system run abnormally in this environment. In a DOS BOX, I used debug to run int13 to read certain sectors. The 2n-th bytes of these sectors are all correct, while the 2n+1-th bytes are all 0. That is to say, every other byte is 0, and the remaining half of the bytes are correct. Based on this, I feel it is not as simple as a BUG, but deliberate. Think about it: what software, when reading sectors, would have this kind of error? It is simply impossible. Whether using BIOS or direct IO port hardware reading/writing, the whole sector is read out together, not read out byte by byte this way. So if it is wrong, the whole sector should be totally unrecognizable; if it is correct, then all of it is correct, with not the slightest difference. Therefore, for the alternating errors described above, I think it is almost 100% deliberately created. Therefore, if we find this section of win98's program and correct it, it should be OK. Similarly, the situation your company encountered, (I think) can also be solved by debugging win98 (of course your company's situation is not very serious, so it can also be left unsolved).

The following is quoted from 不点's speech on 2003-11-27 19:11:06:
This line is too long, and displays abnormally in my mozilla browser, so I broke it with carriage returns:

when we map or substitute one driver letter for another with our real-mode assembly DOS program,
not using Windows'''' SUBST command; all drives enter into real-mode under Win98. However, when
we call another DOS program doing something not essential within our DOS program before issuing
win.com, after entering in Windows, Win98 can recognize all hard disk drives, using Protected Mode.

＝＝＝＝＝＝＝

It is indeed strange, and I am also encountering this kind of problem for the first time. I think perhaps your technical staff can help me; after all, they have long dealt with things in this area. I feel, first, win98 may have bugs, especially the strange situation your company encountered, plus the situation we encountered here with int13, all illustrate this point. Second, there is also this possibility: win98 treats us as a virus, and it deliberately makes the system run abnormally in this environment. In a DOS BOX I used debug to run int13 to read certain sectors. The 2n -th bytes of these sectors are all correct, while the 2n+1 -th bytes are all 0. That is to say every other byte is 0, and the remaining half of the bytes are correct. Based on this, I feel it is not as simple as a BUG, but deliberate. Think about it: what software, when reading sectors, would have this kind of error? Simply impossible. Whether using BIOS, or direct IO port hardware reading/writing, the whole sector is read out together, not read out byte by byte this way. So if it is wrong, the whole sector should be totally unrecognizable; if it is correct, then all of it is correct, with not the slightest difference. Therefore, for the alternating errors described above, I think it is almost 100% deliberately created. Therefore, if we find this section of win98's program and correct it, it should be OK . Similarly, the situation your company encountered, (I think) can also be solved by debugging win98 (of course your company's situation is not very serious, so it can also be left unsolved).

Hi, are you the author of the project Grub for Dos?

We are at Guangzhou. And where are you?

If we are close together, we can meet to help out each other.

Yes, I am tinybit. I now live in the north, but since the network is so convenient, geographical obstacles should be insignificant. The world of the network is both virtual and real; I like the network, even more than the real world. I also really like technology. As long as it is technology, and as long as it is within my ability, I will do my best, regardless of where the problem comes from.