Syslinux - Apr 2004 - Lilo like menuing system for Syslinux

Hi,

I'm sure this has been posted before. And I'm just wondering
if anyone has ever implemented it. I just thought that this 
is really a nice feature for Syslinux.

TIA, 

Vic

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.656 / Virus Database: 421 - Release Date: 4/9/2004

Check out the menu subdirectory of syslinux 2.09!

- Murali

Vic Berdin wrote:
>Hi,
>
>I'm sure this has been posted before. And I'm just wondering
>if anyone has ever implemented it. I just thought that this 
>is really a nice feature for Syslinux.
>
>TIA, 
>
>Vic
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.656 / Virus Database: 421 - Release Date: 4/9/2004
>
>_______________________________________________
>SYSLINUX mailing list
>Submissions to SYSLINUX at zytor.com
>Unsubscribe or set options at:
>http://www.zytor.com/mailman/listinfo/syslinux
>Please do not send private replies to mailing list traffic.
>
>
>  
>

H. Peter Anvin wrote:
> Murali Krishnan Ganapathy wrote:
>
>> The only limit AFAIK is memory. All memory is allocated statically at 
>> compile time. The maximum size for a COM file is 64K. The code plus 
>> all the data should fit into this. Assuming about 256 bytes per item 
>> (that is on the higher side), and 10K for code, and about 6K for the 
>> stack, you have a limit of about 200 items. If you go over the limit, 
>> you should not be able to compile the code (the compiler should 
>> complain that your final executable is more than 64K).
>>
>> If your items can be dynamically generated, then you may be able to 
>> leverage the additional 64K available for COM files (this would mean 
>> changing the code, since currently the code assumes a 16bit pointer). 
>> If you need more than 200 and odd items and they are static, I see 
>> one simple workaround...
>>
>> * Cut your menu tree at some level (say level 2). Then you will have 
>> a mainmenu.com which displays the first two levels of the menu, and 
>> for each possible level 2 choice, you will have a different menu.com 
>> file. Choosing a item from the mainmenu, will call one of the helper 
>> menu.com.
>>
>
> Well, the simplest way to undo that limitation would be to switch to 
> com32.
>
>     -hpa
>
The only disadvantage of com32 I see now, is debugging (burn -> test -> 
reburn ....). Using a CDRW reduces the cost, but the time is still a 
factor.

If I am right, the com32 version will have the same menu.* and user 
files. The only files which needs to change is heap.*, biosio.*, startup 
code and some others. Can we setup the code such that, users can compile 
it to an EXE or COM32 by just changing a #define? If so then debugging 
will also not be a problem.

- Murali

hpa at zytor.com wrote:
>>The only disadvantage of com32 I see now, is debugging (burn -> test
->
>>reburn ....). Using a CDRW reduces the cost, but the time is still a
>>factor.
>>
>>    
>>
>
>Why would you need to burn/reburn?  Use SYSLINUX+floppy or
>PXELINUX+network and you don't need that problem.
>
>You can also test it under e.g. Bochs.
>
>  
>
>>If I am right, the com32 version will have the same menu.* and user
>>files. The only files which needs to change is heap.*, biosio.*, startup
>>code and some others. Can we setup the code such that, users can compile
>>it to an EXE or COM32 by just changing a #define? If so then debugging
>>will also not be a problem.
>>    
>>
>
>COM or COM32 would be more realistic.
>
>    -hpa
>
>  
>
The only reason I said EXE or COM32, is incase we cross the 64KB limit. 
I never thought
of SYSLINUX+floppy (need to see if I have a floppy drive/disk somewhere 
:-)).

- Murali