Hi, > On Nov 30, 2024, at 1:31 AM, Mercury Thirteen via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > The UPX issue would be irrelevant if we didn't ship binaries at all. Hear me > out. :) > > Repeatedly, I have seen stressed here the importance of making sure all > packages we ship are 100% open source. And rightfully so - I don't disagree > with that. > > However, shipping binaries could be seen as a form of bloat because they are > completely redundant when each package is supposed to have complete source > code included. What better way to ensure that the packages we ship both > currently and in the future meet this crucial goal than to prefer that a > package contain only source code, which the installer then builds into a > functioning binary at install time? Source code, as it is simply text, has an > extremely high compression ratio, with the only tradeoff being a (perhaps > slight?) increase in install time on some older machines. And are any FreeDOS > apps truly so large that they couldn't be built fairly quickly on all but the > very oldest install targets out there? In my mind - and I realize others may > disagree - a one-time "penalty" of a longer install is a worthwhile trade-off > to make for an overall much smaller package size. > > Doing this would facilitate another nicety, too: dynamic compilation tailored > to the user's machine. Have a modern machine? Cool, the installer will > compile you a 386+ binary with no additional hassle from the user's point of > view. Got an older PC? No sweat, one 8086-compatible binary, coming right up! > All from the same code the package already contains. > > The only notable exception to this principle which comes to mind would be > applications which are written in commercial languages, such as Borland > Pascal and the like, which we could not install temporarily to facilitate > installation. Applications written in such a way would need to have binaries > shipped in the traditional manner. But I wonder how many applications written > in the FreeDOS-preferred combo of Watcom C and NASM could be converted to > this paradigm, and how much space could in turn be saved. >
While it would be possible to compile many programs at install time, the end users would not stand for the increased install time. We already get complaints that the Floppy Edition takes too long on very old hardware for using compression. The simple act of decompressing the files can result in a several hour long installation on sub-286 hardware. However on 386+ systems it is a lot faster and decreases the overall install time by cutting the number of required disks in half. Let us take a more relevant example. V8Power Tools are the backbone of the primary FreeDOS installer on the CD and USB media. They are relatively simple in design and written purely in assembly. At present, there are 27 binaries that make up V8PT. Those tools can be compiled with NASM under DOS using the BUILD.BAT or cross compiled using build.sh. When compile under DOSBox at 10,000 cycles per second it takes several minutes to compile. I think about 15 minutes. But, I honestly forget how long it takes because I always cross compile. That takes only a few seconds, like single digit number of seconds. And that is nothing, my more modern assembly in NASM use my newer DOS libraries. They make use of complex macros that generate fairly efficient and very optimized binaries. Those macros also provide near HLL level of support for writing code in assembly and require the latest version of NASM. They provide things like a complex “Write” macro that is on par with Pascal’s “Write” procedure. Only the macro is in several ways better. Supporting strings, hexadecimal, signed and unsigned integers up to 512 bit numbers and much more. Those macros are very cool and are great for compiling very small programs. They include things like optimized parameters. Preserve registers if needed. Take into consideration registers that are returned with values. Non-optimal registers might get swapped around before entering the main portion of a macro. On top of that, only the code that gets used is included. Take that Write macro for example. Never display a ZWORD as a binary number. Well the code needed for that is not included in the binary. Plus memory management, integrated mouse support, etc. All that is to say, those macros are a monster of complexity that really puts NASM through its paces. I have done some compile tests under DOS just to make sure it works there. But, it takes a very very very long time. Even cross compiling those takes several minutes for a "simple” program that results in a 3 to 4 kilobyte binary. Compiling something large directly under DOS would be measured in hours or maybe days. On the other hand, it would be good if it could be done. It would also be nice to see that someday that when program source code is committed to the GitLab archive, it could build any binary files there using the CI/CD. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
