China DOS Union

I'm sorry, I didn't make it clear enough. The "Super DOS Boot Disk" image originally has a grub on it, so when booting, there is a selection menu to choose to boot from the hard disk, boot DOS, or boot from the CD-ROM. But the pre7 version of grldr can only guide the grub in the image to stage1, and the selection menu can't be seen. But the grubfordos version before can boot successfully. So I think this is a bug of this version. The "Super DOS Boot Disk" is easy to download on this site. Big guy can have a try.

Thanks for your quick response.

Netware (Novell) remote booting DOS indeed adopts the second possibility you mentioned, where the INT13 handler directly handles the machine's access to the floppy disk. This method doesn't occupy the physical memory space of the local machine, (but it occupies memory, as described below). The following English materials are Microsoft's materials about Novell RPL remote booting.

The boot process of RPL is completed by the BIOS calling the RPL.ROM in the network card (or integrated in the motherboard BIOS). RPL.ROM occupies conventional memory, drives the network card and the IPX protocol, and intercepts INT13. In the case where the system has no boot floppy, it directly redirects the machine's access to the floppy disk to the floppy disk image of the Novell server. There are two points of reference here:
1. Use a blank floppy disk formatted by hd-copy, put it in the floppy drive, set the system to boot from the floppy drive, after the system boots, you can switch from booting from the floppy disk to directly booting the hard disk operating system, whether it is DOS or Win2000. Make this blank floppy disk into an image file and place it on the Novell server. Set the remote RPL workstation to boot from this floppy disk, and it can boot the hard disk DOS system but cannot boot the hard disk Windows2000 system (ntldr), nor can it boot grub.exe under hard disk DOS.
2. After RPL remote booting, the system A: drive points to the server floppy disk image file, occupying more than 100K conventional memory. After running the 28-byte nwrpltrm.com provided by Microsoft, the system A: drive points to the local A: drive, and the RPL occupied memory is basically released. At this time, grub.exe still cannot be booted.


Under the Novell RPL process, the Novell RPL ROM's initialization routine will save the Boot Strap interrupt vector (INT 19H) and replace it with an interrupt vector pointing to its own Boot Strap handler. After this is completed, the Novell ROM will return to the system BIOS.


When the system BIOS completes system initialization, it calls the Boot Strap interrupt to begin the boot process. This call now transfers control to the Novell Boot ROM's Boot Strap handler routine. The Boot Strap handler will then check to see if it sees a floppy disk in the workstation. If it finds one, it restores the Boot Strap interrupt vector and then calls it to boot from the floppy. If no floppy is found, the ROM looks for a hard disk. If a hard disk is found, it prompts the user of the workstation with a query whether to boot from the network or the hard disk. If hard disk is chosen, the ROM restores the Boot Strap interrupt vector and then calls it to boot from the hard disk. If network boot is chosen, or there was no hard disk in the workstation, the ROM begins its autoboot sequence.


At this point the Novell RPL ROM checks the workstation to verify that enough system RAM exists. If there's at least 128K of RAM, the ROM will copy itself into RAM so that it can set up its internal variables. This is done because the Novell RPL ROM is composed of two parts: the IPX RPL code and the IPX network driver code. The network driver code is developed by third-party NIC developers from their normal Novell IPX shell drivers. Since this code is derived from the IPX shell driver code, these drivers make no provision for being placed into ROM. Because of this, the Novell ROM copies itself into memory so the shell drivers do not have to be totally rewritten for the RPL ROM environment--they are merely a simplified version of the IPX shell driver code.


Once the ROM code is copied into RAM, the ROM image will then set up the network boot screen and initialize the NIC. If the NIC is initialized successfully, the ROM image will then use the IPX protocol to find a Novell boot server.




Under the Novell RPL implementation, the Novell RPL ROM includes the capability to emulate a diskette by replacing the INT 13H interrupt vector that handles diskette requests and redirects them over the network to a Novell server. After the Novell RPL ROM has completed the initialization process, it uses the Novell IPX protocol to locate and "connect" to a Novell server. The ROM will then replace the INT 13H diskette handler interrupt vector with an interrupt vector which points to a diskette emulator routine in the ROM image.


The diskette emulator routine in the ROM image redirects all diskette requests over the network to the Novell server that it attached to previously. The Novell server contains a bootable diskette image file which looks exactly like a diskette would in the floppy drive. The server takes the sector requests and responds with the appropriate disk information back to the diskette emulator in the ROM image of the workstation. In turn, the emulator returns the disk information to the caller of the INT 13H interrupt.

### How Novell's BootROM works.
It uses technique described above, saving original vector at 0:300h, and setting word at 0:304h to 6a6eh, which is flag telling that the vectors were changed. Then returns.
When invoked by INT 19h it first attempts to read boot sector from floppy A: - if succeed, it (A) restores original INT 19h vector and invokes it for BIOS to boot the computer as usually.
Next it check for presence of harddisk, and if present it does the following: 1. some video processing - moves cursor to home position, asks for video mode, if 7 assumes mono else sets mode 3 (=CO80) and sets cursor shape according to the mode, finally clears screen (assuming address 0B0000h for mono, 0B8000h for color mode, and usual size); 2. displays a question "Boot from Network (Y or N) ? ", and gets answer (if invalid it repeats the question), on N it displays CRLF and goes to A.
Then the code is moved to segment MemTop-900h, stack is set to 0:0c000h and jump is done to the moved code.
After the jump it initializes video as already described and displays "Novell Netware Remote Program Loader", driver info, and Novell's copyright, then enters boot loop. In the loop it:
- calls driver initialization code (2 procedures, the second may return error - ZF=0 means AX=offset of error message, in such a case it shows the message, displays "Error initializing network interface board" and waits 3 second, then retries)
- sends packet from socket 4A58 to broadcast address with socket 0452 (SAP=Service Advertisement Protocol socket) containing SAP query for nearest fileserver, and reads the reply; an immediate address of replying node will be used to route all requests, destination address net part will be used as net part of own address, and the FS address will be used to access the server
- sends NCP ATTACH request from socket 4A57 (note socket change: it prevents receiving replies to SAP query), and gets from the reply connection id (ATTACH only uses connection id 0FFh)
- sends LOGOUT request, error if no reply or invalid
- sends OPEN requests on the following files: BOOTCONF.SYS (on success it is scanned, using READ requests to get data from it, for line for this W/S, and file specified in it is tried first), then NET$DOS.SYS, IBM$DOS.SYS, first successfull open on image file causes boot to be done from it, error if all opens fail.
- on error a message is displayed, and after 3 second pause the loop is started from begin.
The BOOTCONF.SYS is scanned for 0x,=filename, any of these values can be 0 to match everything, preceding 0-s can be omitted, scanning countinues until first match or read error.
The boot is processed as follows: vectors 0F1h-0F4h are set to 5774:654E ("Netw", copy of vector 13h, new vector 13h (it is changed to point to code which reads boot image), and "boot terminate" vector, then a "bootsector" is read from boot image (the most recently opened file), sectors per track and number of heads are took from it, and jump to it is done; then read from floppy is serviced by reading the boot image file
Boot terminate sends DETACH request, and closes the socket used by the boot (see below why).
The boot image is still accessible when IPX driver is loaded by booted system. How? The BootROM contains own "mini-IPX" which on every request checks if real IPX was loaded, and in such a case opens socket (to be able to receive packets), and forwards all requests to the real IPX. This of course works well providing that network adapter will not be accessed until IPX is loaded - true is using IPX.COM containing driver, and usually true if NDIS driver is used - note some NDIS drivers, in spite specification demands they must not do it, initialize adapter when loaded, and cause the boot to fail.
How the Novell's BootROM is made? There is some code from Novell, and there is driver code from the network adapter manufacturer, probably they are two .OBJ-s and usual LINK can be used to produce .EXE, then DCONFIG/ECONFIG can be used to configure it (on image w/o .EXE header offsets would not match), and finally EXE2BIN to produce BootROM image.

Now only reply to the question from dos@fans1. The problem of GONGXP is more complicated, and I will reply after carefully reading it.

> But the grldr of the pre7 version can only boot the stage1 of this grub in the image, and the selection menu is not visible.

The previous reply of mine is also this meaning, and there is no problem here. As long as GRLDR can boot this IMG, the task is completed. The rest, I guess, is not an error of GRLDR, but an error of GRUB in this floppy image. It may be because the version of GRUB in this image is too low. You can try to upgrade the version of GRUB in the image to the latest version and see how it goes? If it still doesn't work after upgrading to the latest version, then it can be confirmed that this is really a problem.

> But the previous version of grub4dos can boot successfully. So I think this is a bug of this version.

The previous version 0.2.0 does not support the --mem parameter. If you use the --mem parameter to simulate this image, it does not mean that the previous version can boot, because the previous version 0.2.0 has no such function at all. Although you didn't explain, but I guess you have used the map command with --mem, otherwise, if the error occurs without --mem, then it is really a BUG. What exactly is the situation, you need to give a detailed explanation. In the case of using --mem, this is not a problem of GRLDR, but should be attributed to GRUB in the image not supporting the int15/e820 memory specification (there was a typo in the previous writing, it should be int15 instead of int13/e820).

--mem represents a brand new software, and you can't compare it with the old version 0.2.0.

I can't find the download address of the Super DOS Boot Disk now, you can give a download address. But the download I have is the same as yours, both for testing. I believe your report, so actually I don't need to download it.

I very much believe that the current GRLDR will not have problems. If the previous GRLDR can do something, then the current one can do the same thing. The previous GRLDR did not support --mem, and the current one supports --mem. This must be distinguished. If you want a fair comparison, then neither should use --mem, otherwise, one uses --mem and the other does not use --mem, such a comparison is meaningless. Thank you for your report, if there is a problem, please continue to discuss.

GONGXP:

> After RPL remote boot, system drive A: points to the server floppy disk image file, occupying more than 100K of conventional memory

This is bad. Conventional memory is very precious. Occupying so much conventional memory casually will bring many potential problems.

Before the BIOS hands control over to the operating system's bootloader, the BIOS's occupation of conventional memory is all limited to the extended bios data area. This space should not be too large. Generally, it is only 1K, and at most, it might be 4K. Although there is no explicit regulation here, it is rare to exceed 4K, and exceeding 8K may cause problems. This space is located at the top of conventional memory. I think it is a "bad behavior" for the BIOS program to move itself to conventional memory. A well-designed program should never do this.

> After running the 28-byte nwrpltrm.com provided by Microsoft, the system drive A: points to the local drive A:, and the RPL memory occupation is basically released. At this time, GRUB.exe cannot be started.

At this time, the interrupt entry address of int13 may still be in conventional memory, so GRUB.exe refuses to run.

In addition, besides int13, maybe some other important interrupts have also been changed. GRUB will therefore all refuse to run.

The 28-byte nwrpltrm.com program provided by Microsoft has not returned a clean environment to DOS. An ideal program should be that after it executes, it is as if the network BIOS never existed, that is, truly cleanly restores the interrupt vectors (and BIOS data areas) in memory.

You can try to rewrite a program, that is, an enhanced version of nwrpltrm.com, to achieve the above requirements.

In the future, our grub for dos may also perform more intelligent detection to find the entry address of the real BIOS interrupt service program, so it may no longer need a program like nwrpltrm.com. But now you恐怕 still need to do these work yourself.

This is roughly my opinion, although these English materials haven't had time to read carefully yet.

Regarding GRUB4DOS, report and request for help.

I am using GRUB FOR DOS, this program is very good and very practical.

However, I have a special need, I wonder if you can help me.

1: My computer is diskless (no CD-ROM, no floppy drive, no hard disk, no USB flash drive). Now I have booted diskless DOS through the boot chip.

2: After booting diskless DOS, I used xmsdsk.com to virtualize a memory disk in memory, such as drive J:, its size is 2.88M.

3: After loading the network driver, I copied a boot image file (such as SYS.IMG) to the memory virtual disk J: in diskless DOS. At the same time, I also copied all the relevant files of GRUB to drive J:.

4: In diskless DOS, I uninstalled all network card drivers and other TSR programs in memory. At this time, the diskless machine is a clean DOS.

5: Now I need:

Use GRUB in drive J: to call SYS.IMG in drive J: to simulate drive A or B to boot.

How to handle it???

The key to this problem is how to locate the files in the xmsdsk memory disk in GRUB4DOS.

Must help me, thank you!!!!!!!

My EMAIL:
nullren@zj.com

Supplementary Instructions and Thoughts:

In diskless DOS, I uninstalled all network card drivers and other TSR programs in memory. (But xmsdsk.com was retained.) Now it's equivalent to a clean DOS environment.

1. In the case of having a hard disk, after booting DOS, start XMSDSK to virtualize a floppy disk, and GRUB can run normally. When xmsdsk uses the internal disk to virtualize a hard disk, the cluster size can also be specified. Also, it supports positioning the virtual disk to the top of XMS memory. (Of course, HIMEM.SYS needs to be loaded before running XMSDSK.)

2. xmsdsk.com has virtualized a memory disk, and I have also copied SYS.IMG to this memory disk.

3. GRUB runs based on BIOS. Then, is the content in the extended memory unchanged when GRUB is running? Can BIOS read the content in XMS memory? If it can be read, then it will be easy as long as we can locate the position of the sys.img file in the virtual memory disk in memory. But I can't write it.

4. I believe that the big guy can also virtualize the memory disk generated by xmsdsk.com again into a physical hard disk and tell BIOS in memory. However, GRUB doesn't seem to have this function now.

5. I use a BOOTP boot chip for diskless boot. After booting, an A: disk will be emulated, and this A disk can be read and written under DOS. Under DOS, using an rdrm.com (very small, more than 100 bytes), the program of the BOOTP boot chip can be exited, and the real floppy disk can be restored. This exit is very clean.

6. If the above functions can be realized, GRUB will have great applications. It can enable real diskless terminal devices (without hard disks, floppy disks, optical disks, USB disks, CF cards) to boot the operating system (except XP, but it can also be used as a tool to develop drivers additionally to make it) or boot other control programs developed based on BIOS, etc.

7. Strongly suggest: The big guy can lower the parameter of memory capacity for the grub --mem parameter. I want to use GRUB in relatively old industrial control computers that are still in use. Their memory is usually only 16M.

8. The information about bootp is introduced in the LINUX station. The bootp boot chip is downloaded from http://rom-o-matic.net/. The program rdrm.com for exiting the BOOTP chip program and restoring the real A disk is downloaded here http://daan.jsphome.com/temp/rdrm.com

It seems that everyone is concerned about issues related to network booting. Perhaps GRUB for DOS will usefully promote a new application again. Thanks to areyong.

According to areyong's description, this diskless DOS booting from the network can smoothly run grub.exe. This is crucial; otherwise, we might encounter the kind of problem that GONGXP mentioned. Now, let's talk about my views on relevant issues.

> GRUB runs based on BIOS. Then, when GRUB is running, is the content in the extended memory unchanged? Can BIOS read the content in XMS memory? If it can, then as long as we can locate the position of the sys.img file in the virtual memory disk in memory, it will be easy. But I can't write (the code).

grub.exe runs under DOS, and at this time, the extended memory is not affected and still maintains the content when DOS is running. Yes, BIOS can read the content in the extended physical memory. However, BIOS doesn't recognize the XMS specification. This specification seems to be formulated with Microsoft's participation and is specifically used to let DOS access the extended memory. This specification is of no use to BIOS. BIOS accesses the extended memory using specifications like int15/eax=e820h, int15/ax=88h, int15/ax=87h, etc.

> Virtually make the memory disk generated by xmsdsk.com into a physical hard disk again and tell BIOS. Of course, GRUB doesn't seem to have this function now.

As long as we can find the position of the memory disk in the physical memory, we can find a way to virtually make it into a disk number (hard disk or floppy disk) that BIOS can recognize.

> I use a BOOTP boot chip for diskless booting. After booting, it will simulate an A: drive, and this A drive can be read and written under DOS. Under DOS, using a rdrm.com (very small, more than 100 bytes), I can exit the program of the BOOTP boot chip and restore the real floppy disk. This exit is very clean.

GRUB.EXE doesn't necessarily require the real floppy disk to be restored. What GRUB.EXE requires is that the entry addresses of key interrupt service programs such as int13 must be in the ROM (space not lower than C000:0000), not in the conventional memory. As long as this is ensured, then grub.exe will run smoothly. If it's not in the ROM, then grub.exe will also try to find the entry address in the ROM. After finding it, it will also make grub.exe run smoothly. If not found, it will exit and report a failure.

> Lower the parameter of memory capacity for the parameter of grub --mem. I want to use GRUB in relatively old industrial control computers that are still in use now. Their memory is usually only 16M.

--mem currently has no limit on the memory capacity. Even with only 2M of memory, 1M at the top can be used to simulate a floppy disk. However, if your machine is too old, it may not support the relatively new memory specification int15/eax=e820h. This specification was first used by Pheonix and has now become a de facto industrial standard and is supported by all new hardware and software. But since someone needs this function, I will keep it in mind. In due course, if it's convenient, I can also consider supporting the old memory specification. At present, hardware and software that do not support this E820 specification cannot work normally under grub for dos.

In the description by areyong about xmsdsk.exe, adding the /t parameter allows direct running of loadce.exe under DOS. Windows CE may also be able to run Linux with loadlin.exe, but I don't know if there's loadXP. I don't know what kind of stimulus Mr. Bill Gates has received to非要 drive DOS to extinction. If you don't click on the great expert's gurb.exe, it would be very good if there is more adaptability in these DOSes that have "polluted" the BIOS.

Don't click, and诸位:
------------------------------------------------------------- Facing these two issues of diskless booting, I have an idea. Since the conventional memory must be "polluted", that is, the interrupt vectors, and Grub.exe must use and refuse to use the polluted interrupt vectors, then why can't we save a copy of the "unpolluted" I-Vectors at the appropriate time? That is, the space of 0x600. Then place a Grub.exe on the diskless server that can use this I-Vectors, wouldn't that work? Of course, we can also think here that the modification of rpl is well-intentioned. If we adopt a trusting method inside Grub.exe, couldn't we access the FDD img on the diskless server through the modified INT13h? In addition, it seems that after Grub is compiled, it can support network booting, even diskless booting.

> Generate a memory disk with xmsdsk.com and then virtualize it again as a physical hard disk and inform the BIOS. Of course, the current GRUB seems not to have this function.

> As long as the location of the memory disk in physical memory can be found, a way can be found to virtualize it into a disk number (hard disk or floppy disk) that the BIOS can recognize.



We can do this. We compile a program that runs under DOS to push the SYS.IMG file in the memory virtual disk generated by xmsdsk.com into the specified memory segment. This is executed under DOS, not based on BIOS, and there is no need to consider the problem of XMS rules. (First assume that this SYS.IMG file is relatively small, for example, it is only 256K, because the application I need temporarily only needs 256K)

Then enable GRUB again and let it inform the BIOS to simulate the previously specified memory segment as a hard disk or floppy disk.

I can't program, but I really want to have this function soon... Don't click to help.



I have tested it in the BOOTP diskless DOS environment and GRUB can run normally. Moreover, even if the BOOTP environment is not exited, that is, the A disk virtualized by BOOTP still exists, the following functions of GRUB can be used:

chainloader (fd0)+1

rootnoverify (fd0)

boot Then DOS can still be started, but after starting, COMMAND.COM cannot be found (because the virtual disk disappears and COMMAND cannot be found), that is, GRUB can read the virtual A disk.



But the following is not successful, showing a crash: (I have copied a SYS.IMG in the virtual A disk)

map (fd0)/sys.img (hd0,0) or map (fd0)/sys.img (fd1) both crash

The following is the speech by areyong on 2005-4-20 23:57:37:
> Turn the memory disk generated by xmsdsk.com into a physical hard disk again and tell the BIOS. Of course, GRUB now seems to have no this function.
> As long as the position of the memory disk in the physical memory can be found, the method can be used to virtualize it into the disk number (hard disk or floppy disk) that the BIOS can recognize.



We can do this. We compile a program executed under DOS, push the SYS.IMG file in the memory virtual disk generated by xmsdsk.com into the specified memory segment. This is executed under DOS, not based on BIOS, and there is no need to consider the problem of XMS rules. (Assume first that this SYS.IMG file is relatively small, for example, it is only 256K, because the application I need temporarily has 256K is enough)
Then enable GRUB again, let it tell the BIOS, simulate the memory segment specified by us as a hard disk or floppy disk.

I can't program, but I really want to have this function soon... Don't click to help.



I have tested it in the BOOTP diskless dos environment, and GRUB can run normally. Moreover, even if the environment of BOOTP is not exited, that is, the A disk virtualized by BOOTP still exists, the following functions of GRUB can be used:

chainloader (fd0)+1

rootnoverify (fd0)

boot This can still start DOS, but after starting, COMMAND.COM cannot be found (because the virtual disk disappears, and COMMAND cannot be found), that is, GRUB can read the virtual A disk.



But the following is not successful, and it shows a crash: (I have copied a SYS.IMG in the virtual A disk)

map (fd0)/sys.img (hd0,0) or map (fd0)/sys.img (fd1) both crash

Don't bother the trouble!
We could do it by:
1. loading the first DOS system by pxegrub or nbgrub with memdisk
2. using GRUB.EXE to load once again the second dos image file
on the virtual memdisk drive (A: or C formed by the first dos system
either
a. as memdisk again
or
b. as etherboot dos image file, nbi image file
(Bean has worked out a version of GRUB that can load etherboot dos image file as well.)

Gandalf: This issue was already considered when I was developing grub for dos 0.0.1. On the surface, it seems feasible, but in reality, there are many problems. The conclusion is that it's not very feasible or appropriate. For example, on the same machine, when booting from the hard disk, the interrupt service entry address of int13 is different from when booting from the CD-ROM. Although both are legal ROM addresses, different boot methods result in different interrupt vector tables and BIOS data areas (and extended BIOS data areas). Therefore, this method is essentially unreliable. There are also other problems that make this method fundamentally impractical.

Regarding the previous question from areyong, the method mentioned by windrv is probably feasible. But now I'll also share my thoughts on areyong's question.

Look at this part:
-----------------------------
I have tested it in the BOOTP diskless dos environment and GRUB can run normally. Moreover, even if you don't exit the BOOTP environment, that is, the virtual A drive created by BOOTP still exists, you can use these functions of GRUB:
chainloader (fd0)+1
rootnoverify (fd0)
boot This can still start DOS, but after starting, COMMAND.COM cannot be found (because the virtual drive disappears and COMMAND cannot be found), that is, GRUB can read the virtual A drive.
----------------------------------------
I want to ask: Why does the virtual drive suddenly disappear? Did GRUB.exe remove your virtual drive?

If your virtual drive doesn't disappear, then you can access your SYS.IMG under GRUB, and you won't have any difficulties. You just need to start the simulation with --mem and it's all done.

The disappearance of the virtual drive may be a manifestation of the imperfect nature of your BIOS, just like GONGXP's BIOS is not very perfect.

To further understand this problem, I want to explain it using an analogy. We know that CDROM and USB have similarities. Both simulate floppy disks by directing the processing of int13 for floppy disks to their own media. For CDROM, it's directed to the CD media, and for USB drives, it's directed to the USB media. The situation of your network should also be handled in this way. At least this way of handling is relatively perfect and won't have problems. That is, directly direct the access of int13 for floppy disks to the network media.

Therefore, what needs to be perfected in the end is nothing else but your network BIOS.

In addition, if you want to write the programs you mentioned, it's恐怕 not that easy. It should take a process. Theoretically, this problem can be solved, but to really solve it, there need to be conditions. It requires understanding all the details, and this takes a process. I don't have these conditions here, so it's difficult for me to solve your problem.

to 不点: I think you really need to set up a guestbook or other quick contact method. 1. For GRUB, it should be okay to run in ROM, just like FREEDOS of ROMOS runs in BIOS. GRUB works at the BIOS layer, and it should be possible to make a GRUB.BIN or GRUB.ROM run in the motherboard ROM. 2. It's the PCI module problem in BIOS I mentioned last time. Currently, the software emulator of the PCI or ISA module in BIOS is a blank, but there shouldn't be technical difficulties in running it with GRUB's CHAINLOADER, of course, I'm just imagining it. If you need this module, I can provide it for you to test. 3. I wonder if the current GRLDR can copy itself and install to the MBR?

TO Budian: 1. Can the existing GRLDR implement copying its own boot code to the MBR? Also, the hotkey issue during startup I mentioned last time. It's better to specify a hotkey, with a time of one second is enough, can't wait too long. Any key is not safe. Without a hotkey, the GRUB menu will appear every time. 2. Regarding GRUB running from ROM, I think it should be possible, just like the FREEDOS of ROMOS booting in BIOS. 3. Can GRUB's CHAINLOADER boot the PCI module in BIOS? In this regard, the emulator of BIOS is still a blank. If corresponding modules are needed, I can provide them to you, including DOS and hard disk protection modules.