Since lot of people want this thing, I will try to take a stab at it. For now, I will hard code the menu in the code, and then somebody else can remove that restriction. May be we can add some kind of keyword to the config file which syslinux ignores and the comboot menu does something with it. I have one question about comboot: If I write a DOS program using C (compiled using watcom -3 -mt -osx flags) and use only BIOS interrupts and the DOS interrupts which comboot API supports, it should work in syslinux right? In that case, it will be easy to debug, since what I write will be a simple DOS .COM file. - Murali
ganapathy murali krishnan wrote:> Since lot of people want this thing, I will try to take a stab at it. > For now, I will hard code the menu in the code, and then somebody else > can remove that restriction. May be we can add some kind of keyword to > the config file which syslinux ignores and the comboot menu does > something with it.Well, the sane thing would be for the menu program to take a configuration file name on its command line and download that file separately.> I have one question about comboot: If I write a DOS program using C > (compiled using watcom -3 -mt -osx flags) and use only BIOS interrupts > and the DOS interrupts which comboot API supports, it should work in > syslinux right?Yes, that should work. It's extremely unlikely that you can get a standard C library to be that restrictive, though... although if you manage, more power to you :)> In that case, it will be easy to debug, since what I write will be a > simple DOS .COM file.Indeed. -hpa
In the sample menu application which I currently writing (sorry I have not yet implemented reading and parsing the file, so only hard coded entries work), I need to read a string from the user. Currently the only way I can do it is to read one char at a time in a loop. May be the syslinux API can add "read a string with echo" to its arsenal? The menusystem currently supports check boxes, and trapping some events in addition to customizing the look and feel of it all. - Murali
Well I have come across a stumbling block... Hopefully somebody can help me out here. I have a C program, which uses only int 10h, and parts of int 21h implemented by SYSLINUX. I do not use any standard include files, and compiled by program using wcl -3 -osx -mt filename.c (Open Watcom) The resulting .COM file worked perfectly in DOS, and when I run the file under ISOLINUX it gives an error "Using DOS Function call" or something to that effect. I then disassembled the .COM file and sure enough, I see that some of the startup code which Watcomm generated uses DOS interrupts not implemented by ISOLINUX. Specifically, the function numbers in question are INT 21h, Functions 4Ah 40h 30h and INT 21h with AX=3D01h. Is there a flag to Open Watcomm which bypasses its startup code or something like that? Or will implementing dummy versions of these in SYSLINUX help? Basically, I am searching for some way to compile my C program which uses only int 10h, int 16h and SYSLINUX compatible parts of 21h to a .COM file which runs under ISOLINUX and preferably under DOS also if I do not run the SYSLINUX specific interrupts (All my calls to SYSLINUX API is wrapped around a check to see if we are running DOS 0.0). - Murali
ganapathy murali krishnan wrote:> Well I have come across a stumbling block... Hopefully somebody can help > me out here. >More specifically what I need is a 16 bit equivalent to c32entry.S and a sample makefile, to compile my .c file and link it with c16entry.o If need be I can send the .COM and/or .C file. - Murali
With lots of help from Peter and the Watcom developers, I have managed
to get the thing working. Right now, you still have to hard code the
menu entries. However, it has its advantages. For example, one can
disable certain options, based on other options, "install event
handlers"....
One really useful menusystem would be combining this with chain.c32. The
program, first queries the BIOS and finds all the installed hard drives
and floppy drives, and using chain.c32 like code, finds which one is
bootable and which is not. Then one can dynamially generate a menu, one
option for each partition, with the unbootable partitions disabled.
So my question is: Do we still need a way to read a file and display the
menu from the file? We can only describe static menu systems using the
file, and besides the following code is not all that difficult to write.
If people are still interested in having static menu entries, then can
somebody else write that code. I have already spent a lot of time on
this now, and don't have the time to write the parser now.
You can download this from
http://people.cs.uchicago.edu/~gmurali/gui/comboot/tui.tgz.
Warnings:
* The color choices I made turned out to be horrible when run under BIOS
(they did not look very bad under DOS box).
* For some reason I haven't figured out, the color palette of the
syslinux display changes if I exit out of the menu. If somebody finds
out why, I'd appreciate knowing it so I can fix it.
--------REALLY SIMPLE EXAMPLE -------
// Bunch of #includes here
int _start()
{
t_menuitem * curr;
MAIN = add_menu(" Main Menu ");
add_item("Prepare","Status Line",OPT_RUN,"syslinux
command",0);
add_item("Second Menu item","Status
Line",OPT_RUN,"command",0);
add_item("Exit", "Exit the menu system",
OPT_EXITMENU,"exit", 0);
curr = showmenus(MAIN); // All the action happens here
if (!curr) return 0; // user hit Esc in main menu
if (curr->action == OPT_RUN) runcommand(curr->data);// Call syslinux
here
return 1; // Should never come here
}
------- EXAMPLE ENDS ---------------
- Murali
I created another one exactly the same size, and used the information gives by mkdosfs this time. The same C/H/S combination worked. It might be useful to have mkfloppyimage script, just like mkdiskimage. So people like me don't do stupid things (like forgetting the parameters). - Murali H. Peter Anvin wrote:> ganapathy murali krishnan wrote: > >>Is there any way I can figure out what parameters I need to pass? All I >>remember now is that the size of the image is 9216K. I guess I can >>recreate a FAT file system on some 9MB file and see what parameters >>mkdosfs uses. >> > > > You could pick apart the DOS superblock, I guess :-/ > > -hpa > >