On Thu, May 30, 2024 at 11:52 AM Bernd Böckmann via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote:
> Hi Wolf, > > welcome to the mailing list. Great to hear you started working again on > DOG. Putting it on Github (or some other publicly accessible repo) sounds > like a good idea :) > It's currently on sourceforge, and I have recovered my SF account, so I have the git history, but for personal reasons I'm planning to move to github (I also plan to leverage the wiki and issue tracker). Maybe I'll also keep the sf repo up-to-date, it's not much extra work to push to a second upstream. :) > Looking at https://gitlab.com/FreeDOS/util/dog, that seems to be version > 0.83c. Is this the latest publicly available version? Otherwise we should > update the package. > Huh, that's an impossible version number for DOG. the correct version should be 0.8.3b. The version number is built up like this (from the release notes): Version is built up like this: A H A L --- --- | | | | | | | +-- code maturity always one of a (=alpha), b (=beta) OR f (=final) | | +---- Patchlevel | +------- Minor version +--------- Major version (this implies that the maximum version for DOG is 15.15.15f ;) So yeah, I think we should update that, but we can do that when I release the 0.8.4b version, in the near future. I'm planning on creating a 0.9.0a branch after the 0.8.4b release. > > Now a question: > > What are your dev setups like? I'm on a linux host computer and I've > been using both DOSBox and QEMU to build and test in. I find though that > it's a bit of a chore, since DOSBox crashes randomly (like when compiling), > or QEMU segfaults when I mount my dog source directory as a virtual FAT > drive. So now I'm looking at setting up Dosemu2 (I remember using doemu ~20 > years ago). > > I mainly edit the source code of the DOS programs I work on with my Mac > and compile them inside DosBox-X. For me, this is quite stable. I would > like to test Dosemu2, but that seems not to be fully ported to Mac yet. > It works okayish for me, especially after setting things up in dosbox that when I launch it everything is ready for me to just run make. I did have some odd stuff happening from time to time. though. > I use OpenWatcom 1.9 to compile my programs under DOS(Box), I'm using Borland C++ 3.1 for now as that's the compiler I used 22 years ago... Looks like porting to Watcom will require a bit of work... It is something I want to do eventually, I think. Just need to read up on the inline assembler stuff and how to build COM binaries :) > but also have setup Github actions for some projects to automatically > build my commits using a Linux container with OpenWatcom v2 and IA16-GCC. > While somewhat experimental, the Linux port of OpenWatcom v2 and IA16-GCC > work good enough to produce functional kernel and FDISK binaries. We did > not encounter major issues in recent times. You might get some inspiration from the public repos under > https://github.com/FDOS. > I'll have to take a closer look at how they are set up :) The cross compilation stuff is especially interesting :) > Regarding the edit-build-test cycle, this is where DosBox comes to its > limit. Programs that use the ordinary DOS API and some BIOS interrupts tend > to run fine. I have noticed that, earlier this week I was implementing a ^C handler, and it looks like DOSBox never emits an int23, or handle ^C in any way at all... I plan to implement my int 24 handler over the weekend, and will probably have to test on QEMU. For now I'm building on DOSBox and then copying the files over to a floppy image and then load it from there in QEMU, but that copy to floppy image is an extra step, makes testing that much harder. > But I had for example some minor problems with missing INT13 interrupt > functions. Though the DosBox-X people were fast at implementing the missing > pieces after I filed a report at their issue tracker. The kernel and other > low-level stuff I test under 86box or on a real machine. > Hmm I'll have to try DOSBox-X, I see a lot of people mentioning it. > Regarding debugging, for me the Watcom Debugger is a good enough debugger > to debug most of the user space programs. It has a TUI and supports > symbolic debugging. There are also free sophisticated debuggers like lDebug > (command line based) that might be worth a look at, albeit I would consider > this more geared towards assembly. > Thanks for the pointers, I'll take a look! DOG is mostly C but I do have a whole bunch of inline assembly, and might move some of that over to actual assembly. So, once again welcome. > Thanks! It's good to be back :) -Wolf -- |\_ | .\---. / ,__/ / /Wolf <wolf+...@bergenheim.net>_ > Bernd > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
