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!

Just a quick heads-up: a new version of GROG is coming, I’m planning to release it later today or tomorrow.
I’ve put a good deal of effort into this new version, looking forward to sharing it with you and reading your feedback!

Hello again, everyone!

Following up on the recent discussions, G.R.O.G. v3.1 is now officially live!

The main focus of this update is hardware compatibility. I know some of you have been wanting to run GROG on original XT/AT hardware (8086/8088/286). I hope I'm not forgetting anyone, but I'm tagging a few of you who showed interest because I'd love to hear your feedback if you have a real XT/AT machine ready to go: @Ozzuneoj ; @vetz ; @aVd ; @douglar ; @zyzzle

This version ships with two completely different engines: the classic 32-bit executable for 386+ rigs, and a brand new, highly-optimized 16-bit real-mode port built specifically to thrive on low-RAM systems. The best part is that both versions read the exact same GAMES.CSV database. You can pop your CF card out of your Pentium, drop it into your IBM XT, and the 16-bit engine will read your existing lists just fine.

Beyond the 16-bit port, which you can read all about in the official doc and release notes, there are a few nice quality-of-life updates across the board:

• Under-the-hood performance: Swapped out some heavy memory allocation and rendering loops, so UI navigation should feel noticeably snappier and flicker-free on slower hardware.
• 16-Bit "Offset Zipper": To save vintage hard drives, the 16-bit engine completely abandons random disk thrashing.
• Older DOS Support: Rewrote how the batch wrapper generates scripts to fix compatibility issues with rigid older command interpreters like DOS 5.0 and 6.22.
• Not interested in slowing down your machine with setmul, cpuspd, etc.? You can now disable the speed option so it won't appear on your main menu.
• CRT Offset: Added a new MENU_OFFSET setting in GROG.CFG. If your CRT geometry is a bit misaligned, you can now manually shift the whole menu left or right to centre it. Only for people with OCD like me 😜

and much more...!

Important Note: The zip extracts the 32-bit version by default. If you are deploying to an XT/AT machine, just copy the executables over from the included 16-BIT folder.

Download: https://codeberg.org/jjmarcos/grog/releases
Source/Docs: https://codeberg.org/jjmarcos/grog

Shagittarius wrote on 2026-02-10, 05:24:

Works good with down arrow, not as well with PageDN and PageUP, I feel so picky, 🤣. [...]

Please, give 3.1 a try when you can, the new rendering logic should make PageUp/PageDown feel more responsive now.

As always, let me know how it runs on your setups.
Thanks for all the testing and feedback!

Hi, @kahuna,
Many, many thanks for this new milestone G.R.O.G. release! I have nothing to say, you made it waaay better, than I expected, with all these new optimizations and features.

At first glance everything is fine with the new 16-bit "real mode" version. Thank you very much for the port.

From the first quick test the 32-bit LB2GROG.EXE produces csv-file containing DOS-friendly "\r\n" line breaks, but the one made with the new 16-bit LB2GROG contains *nix style "\n" line breaks. Perhaps the GCC-IA16 compiler doesn't automatically convert "\n" line breaks to "\r\n".

Also, the prebuild 32-bit GROGMENU.EXE from the archive with the v.3.1 binaries release shows itself as the better version "16-bit Port", but in its source file it contains the correct string "32-bit DPMI". Probably you've added some older test build inside the archive.

If I find something wrong, I'll write it in a later post.

I have to admire, that you're writing your C code in a very clean and readable way. Very professional.

P.S. I hope, that this brand new (and IMHO better) 16-bit XT compatible version of G.R.O.G. will make this wonderful DOS launcher popular. At least among retro gaming community.

Outstanding port to 16-bit. This is now lean and mean, very optimized. BTW: I actually prefer the UNIX-style line breaks, as they save space compared to the (0x0D 0x0A) DOS-style ones. The 800-game limit is sane enough, and should be plenty for 16-bit systems, anyway.

This is now very mature, professional, and suits its purpose extremely well. I hope this will fill a niche in making the running of DOS games easier for more people. The preservation of DOS games is important, and this will make it easier for more people to run them and perhaps even get a few into the hobby that were "scared off" because of DOS before. Any effort at bringing in new recruits to my beloved hobby is most laudable!

EDIT: Yep, this was actually a very stupid suggestion.

It's important for GROG to be flexible enough to provide useful functionality for the largest number of use cases. We should try to think about changes beyond our own perspectives. This 16 bit version seems already to be pushing towards something that it streamlined into a very narrow use case. Let's be careful to not let the desire for this use case ruin the greater intent, but at the same time expand the use cases for the 16bit version.

Hi, @Shagittarius,
Could you explain what you mean by "narrow usecases"? The 16-bit version of G.R.O.G. runs on everything, that can run DOS 3.30+. How this could be a "narrow usecase"? Or you mean, that probably my proposal for some database optimizations (in terms of size and consequently smaller RAM usage) is not proper to be even discussed? I don't insist on anything, I'm just thinking how this wonderful software may be improved further. Please, be more specific. Vague comments doesn’t contribute to a constructive dialogue.

Thanks!

Narrow use cases means we can't just examine our own needs for the software, we have to consider how others might want to use it. I don't have a problem with anyone discussing their ideas, I just don't want the flexibility to be compromised, I don't want the tool to become useless for me or anyone. I spoke broadly because I wanted to encourage everyone to think broadly, not to call anyone out. I would have been very specific if that was the intent.

I think it's great to add more capacity to the library of the 16bit version, I've already got more than the limit of 800 games, but my personal goal is my pentium dos library, not my 5170. This tool was designed with 32bit systems in mind, that's why it has all the built in speed toggle functionality. It's great to be expanding the reach of utility to older machines but let's try not to lose the original intent in the process.

To me the creator who did not want to do a 16bit version has already had his hand forced so he wouldn't lose his concept to competing builds. I feel sorry for him about that. It felt pretty rude to me.

Ok. I got it. Thanks.

Keep sharing, I can definitely see savings in your proposal, I'm not much of a programmer outside of automation scripting so I'm not much help in the way that you can be.