Ozzuneoj wrote on 2026-03-08, 17:57:

Weird. That page seems to link remotely to basically every program, so all of the links I tried go to different sites and FTPs that are all dead. Too bad... it seems like a great collection of software.

Most of them are here: https://ftp.sunet.se/mirror/archive/ftp.sunet … net/msdos/menu/

Just tried to build a 16-bit DOS executable LB2GROG.EXE 3.0 with Open Watcom 2.0 compiler and it works without any changes in LB2GROG.C code. I used OWCC.EXE with these switches:

1owcc.exe -bdos -v -mcmodel=l -fsigned-char -std=c89 -Wall -Wextra -fno-stack-check -Os -finline-intrinsics -s -o lb2grog.exe lb2grog.c

I don't know if "large memory model" is the most suitable, but I used it just in case. LB2GROG converter now works fine on 8086/88 CPUs and is only about 21.8KB in size compared to the original 32-bit executable from DJGPP compiler, which is about 238KB (my mistake) 105.5KB. Still 5 times smaller.

I'm thinking how to port the missing libraries needed for GROGMENU.EXE form DJGPP to Open Watcom 2.0...

EDIT: Wrong original exe-file size.

aVd wrote on 2026-03-08, 21:22:

Just tried to build a 16-bit DOS executable LB2GROG.EXE 3.0 with Open Watcom 2.0 compiler and it works without any changes in L […]
Show full quote

Just tried to build a 16-bit DOS executable LB2GROG.EXE 3.0 with Open Watcom 2.0 compiler and it works without any changes in LB2GROG.C code. I used OWCC.EXE with these switches:

Copy code to clipboard

1owcc.exe -bdos -v -mcmodel=l -fsigned-char -std=c89 -Wall -Wextra -fno-stack-check -Os -finline-intrinsics -s -o lb2grog.exe lb2grog.c

I don't know if "large memory model" is the most suitable, but I used it just in case. LB2GROG converter now works fine on 8086/88 CPUs and is only about 21.8KB in size compared to the original 32-bit executable from DJGPP compiler, which is about 238KB.

I'm thinking how to port the missing libraries needed for GROGMENU.EXE form DJGPP to Open Watcom 2.0...

Since your executable is < 64KB, you can use the "compact" memory model.

douglar wrote on 2026-03-08, 21:58:

Since your executable is < 64KB, you can use the "compact" memory model.

Hi, @douglar,
You're right. The switch "-mcmodel=c" saved some more bytes for a slightly smaller executable file. The size of LB2GROG.EXE now is about 21.2KB and seems to work fine.

Thanks for the hint, I forgot to check the documentation about those DOS memory models.

aVd wrote on 2026-03-08, 23:00:

You're right. The switch "-mcmodel=c" saved some more bytes for a slightly smaller executable file. The size of LB2GROG.EXE now is about 21.2KB and seems to work fine.

Are you willing to share this LB2GROG.EXE binary? 21.2kb is magically small and lean.

zyzzle wrote on 2026-03-09, 00:47:

aVd wrote on 2026-03-08, 23:00:

You're right. The switch "-mcmodel=c" saved some more bytes for a slightly smaller executable file. The size of LB2GROG.EXE now is about 21.2KB and seems to work fine.

Are you willing to share this LB2GROG.EXE binary? 21.2kb is magically small and lean.

I feel like the real mode version should be called RealGrog.EXE.

Any guess about large of a menu file can you open ? 640KB should be enough for .... anyone ...... ?

zyzzle wrote on 2026-03-09, 00:47:

Are you willing to share this LB2GROG.EXE binary? 21.2kb is magically small and lean.

Hi, @zyzzle,
G.R.O.G. is released as FOSS project by its original author/creator @kahuna, so I think there's no problem to share it (I hope so). Here's the Open Watcom C/C++ 2.0 compiled 16-bit "real mode" version of LB2GROG.EXE:

EDIT: Attachment is now removed by @kahuna's request.

Inside this zip-archive you'll get five files:

• LICENSE - text file with original GNU 3.0 license
• LB2GROG.C - the original unmodified source code for LB2GROG database converter v.3.0a
• BLDLB2GR.BAT - batch file for building the executable with the long OWCC command
• LB2GROG.EXE - prebuild executable using latest release of Open Watcom C/C++ Compiler 2.0 for DOS
• LAUNCHBX.TXT - a small test "database" file from LaunchBox 2.0 for DOS (you have to replace it with yours)

If you're a space saver on real XT machines (like me), you can chew the LB2GROG.EXE with aPACK for DOS:

1apack -x lb2grog.exe

This will give you a smaller 8086/88 compatible (don't forget the "-x" switch) aPACK packed executable named "OUT.EXE", which you have to rename back to "LB2GROG.EXE".

Or if you prefer other exe-packers like UPX (I'm using both DOS or Linux versions), then use:

1upx --8086 --best -k lb2grog.exe

This will give you a smaller 8086/88 compatible (don't forget the "--8086" switch) UPX packed executable named "LB2GROG.EXE" (no renaming needed, the original non-packed exe-file will be kept under the name "LB2GROG.EX~").

It will be nice to get some feedback if this OWC 16-bit "real mode" LB2GROG.EXE version is working fine with bigger "database" files from LaunchBox 2.0 for DOS.

douglar wrote on 2026-03-09, 01:02:

I feel like the real mode version should be called RealGrog.EXE.

Any guess about large of a menu file can you open ? 640KB should be enough for .... anyone ...... ?

If I manage to replace all the GROGMENU's functions used from "sys/farptr.h", "go32.h" and "dpmi.h", which are missing in OWC/C++ Compiler 2.0 libraries, then we can discuss which data-fields can be removed, thus reducing the memory footprint needed for database loading. I'm still waiting to get answer here.

Thank you!

P.S. I think I got it, but I need a confirmation from @kahuna. The missing OWC/C++ libraries functions are used only for direct VRAM drawing code and LFN support code. So, for a 16-bit "real mode" XT compatible GROGMENU.EXE I'll have to fallback in these two functionalities. Perhaps there will be also need for some memory adjustments in the code, but for starting a 16-bit port I think those functions are more important to be replaced or removed entirely.

EDIT: Due to some weird freeware license conflicts the attached 16-bit LB2GROG is now removed. Never thought, that even free software licenses could cause problems.

Hello everyone,
hi @aVd, @douglar, @zyzzle,

First off, I just want to say how awesome it is to see the enthusiasm for getting GROG running on 16-bit hardware.

I mentioned a while back that a 16-bit version wasn't really in the plans, but seeing you actively looking for a way definitely made me rethink things. If the demand is there, I want to make sure to get a proper, official port.

So, I decided to take the plunge and port the entire GROG codebase to 16-bit! I've learnt a lot in the process! I must say I really like 86Box, setting up both a 286 and a 8086/8088 machines has been a surprising rewarding experience 😁
To keep everything standard and avoid obscure compiler chains, I went the route of using gcc-ia16 (cross-compiling with ia16-elf-gcc on Linux), and it's working beautifully.

Here is a sneak peek of GROG running on an 86Box VM. This is an emulated 8088 at 4.7MHz with just 256KB of RAM, a CGA display and MS-DOS 3.30 (click to enlarge):

Since this official 16-bit release is pretty much ready and I expect to drop it in the next few days, I do have a favour to ask @aVd regarding the LB2GROG.ZIP you uploaded. As much as I appreciate the initiative to compile and share it, there is unfortunately a pesky, hidden legal quirk we have to navigate.
GROG is licensed under GPLv3, and because the Open Watcom compiler statically links its own runtime libraries (which are under the Sybase Open Watcom Public License), it creates a strict licensing incompatibility. To keep the project's licensing completely clean and avoid any messy offshoots, would you mind pulling down that specific zip file from your post?

I really appreciate your understanding on this matter! The great news is that you won't have to wait long at all; the native, fully GPL-compliant 16-bit version of GROG will be dropping in just a few days, I have invested quite some time on this effort. I'll be sure to ping this thread the second it goes live so we can see how it runs on your XT/AT machines!

Cheers!

Hi, @kahuna!
First of all, I removed the license complicated 16-bit Open Watcom compiled version of LB2GROG.EXE attachment ASAP and it was with zero downloads, so no freeware license complicated version was leaked 😉

I'm sorry, I was not aware, that even the freeware compiler and linker used for building some free software have to be with the very same free licenses as the source code used. I think this breaks all the concepts of free and open source software we have, as probably not many programmers/developers/authors of free software are into this (free) license matter. In general I don't care to attach some license text files or declare if it will be GPL, MIT, CC or whatever free license, when I write some small DOS tool. I think, if something is given to public for free, usually we can't rely on restrictions by these free licenses. I'm not aware which free license is the least restrictive. Some people even say, that CC (Creative Commons) non-restrictive license variants are not suitable for software releases (which sounds ridiculous), so I like the CC0 (public domain) "license" the most. And I can't find any compiler and linker released under CC licenses. Does this mean I break the law? Anyway... by the low and its tricks we're always guilty.

Thank you very much for making the official 16-bit port of G.R.O.G.! So, there will be no need to make a mangled 16-bit port of your 32-bit code.

I'm eagerly awaiting your official XT compatible G.R.O.G. version. Thank you!

P.S. Now I got license sickness 😁 Those exe-packers also come with some kind of different free licenses, so we have to be aware if the software licenses match when packing executables. What a freeware license nightmare... we're all pirates, cheers!