I just rebuild upx.exe ... and it is usinc UCL according to upx -V I have just tried to send it to E.C. Masloch, Jim, Jerome and Eric.
To build it I created a file with: [paul@betakard release]$ cat ~/toolchain # the name of the target operating system set(CMAKE_SYSTEM_NAME DJGPP) # which compilers to use for C and C++ set(CMAKE_C_COMPILER i386-pc-msdosdjgpp-gcc) set(CMAKE_CXX_COMPILER i386-pc-msdosdjgpp-c++) In upx/build/release: $ cmake --toolchain=~/toolchain -S ../.. --fresh Note the license seems to allows rebuilding and distributing only a not-modified version. ---- Le mar., 26 nov. 2024 11:20:36 -0500 E. C. Masloch via Freedos-devel a écrit ---- > Hello, > > On at 2024-11-25 15:13 -0500, Jerome Shidel via Freedos-devel wrote: > > Hi, > > > >> On Nov 25, 2024, at 1:39 PM, E. C. Masloch via Freedos-devel > >> freedos-devel@lists.sourceforge.net > >> freedos-devel@lists.sourceforge.net>> wrote: > >> > >> On at 2024-11-16 01:59 -0500, Jerome Shidel via Freedos-devel wrote: > >>> Hi All, > >>> As we are most likely approaching the release of FreeDOS 1.4 in the > >>> very near future, we are coming to the point where we will begin to > >>> look at the monthly Interim Test Release builds of the operating > >>> system as Release Candidates. > >>> At that point any large or complex changes will no longer be made > >>> until after the next OS release. T2412 may be the final Interim build > >>> and T2501 could very well be the first Release Candidate. > >>> Since T2411, there have only been a couple suggestions for changes. > >>> Mostly in regards to reducing the size of a couple packages. Eric and > >>> I updated several of those packages to save some space on the install > >>> media. > >>> Likewise, yesterday a I updated BWBasic to version 3.30 that dropped > >>> a couple days ago. Including, UPX compression of the binary which > >>> will cut its installed size roughly in half. > >>> Are there any general or package groups changes anyone would like to > >>> see made before we move from Interim Builds to Release Candidates? > >> > >> I have two points to add: > >> > >> 1. It seems that lDebug is still not included in the interim builds. I > >> checked the FullUSB [1] and BonusCD [2] images and didn't find an > >> lDebug package in either. (Besides, I found that it was difficult to > >> find the links for downloading the interim build. The freedos.org > >> http://freedos.org> website doesn't seem to point to them anywhere, > >> so I had to look at the mailing list announcement [3] to find the > >> links.) It would most likely go to the DEVEL section. FreeDOS Debug is > >> included in BASE but I don't think lDebug should go there. > > > > I certain this was simply an oversight. Possibly from all the the > > package, group and media shuffling. We have a version of lDebug in the > > FreeDOS GitLab Archive for it to be included. However, it was missing > > from the various lists of packages and the report generated by the RBE. > > > > Therefore, I added it to the appropriate package list. It will be > > included on both the BonusCD and FullUSB media user the DEVEL group in > > the next Interim Test Build (T2412). > > That's good news. Albeit, I didn't mean it necessarily should go onto > the BonusCD. I just expected that it should *at least* be in FullUSB or > BonusCD. If there's space on the LiveCD or LegacyCD instead, what about > those? > > > It will be great when the RBE4 is ready and replaces the current > > version. Under the RBE3, it is very easy not notice an unintentionally > > excluded package. The RBE4 operates in a completely different manner. It > > would be very difficult for such an omission to slip through on an OS or > > Interim build. The RBE4 will even be capable of detecting an excluded > > available package. Most likely, I will have put up a warning message to > > the builder when that is going to happen. Unfortunately, that is > > something which just isn’t possible under the RBE3. > > > > It is another one of those “features” that have motivated me to start > > working on the RBE4. That work is coming along nicely. But, it is a big > > long-term project and will be a while before it can replace the current > > RBE3. > > I'm looking forward to it! > > >> Relatedly, I am about to finish the next release, lDebug release 9 > >> [4]. It will likely be done prior to the new year. It includes some > >> bugfixes and a bunch of new Extensions for lDebug (ELDs). I just added > >> a DCO7 (Debugger Common Options) flag to avoid a crash when loading > >> the debugger as a device driver (in CONFIG.SYS or using a patched > >> DEVLOAD) and specifying a flat binary file on the device command line. > >> I'm considering to default enable the immediate assembler (inspired by > >> D86) and the Heatshrink compression of help pages before the release. > >> Further, this updates the lDOS boot32 loader included in instsect.com > >> http://instsect.com> to the FSIBOOT5 revision, the latest and greatest. > > > > I think that T2501 will possibly be FreeDOS 1.4-RC1. > > > > When RC1 is release, there will be a semi-freeze on packages. Basically, > > bug fix mode. All BASE and other packages critical to the OS will only > > be updated to fix bugs. There will be no more updates any large or > > complex packages. Updating, packages like FPC are very time consuming > > and easy to make mistakes. > > > > Updating things like lDebug are easy to do and are not critical to the > > OS. So, I do not see an issue with provide a limited number of such > > updates to some packages after RC1. > > > > But when RC2 is released (possibly T2502), a full freeze will go into > > effect. No more updates. Only important bug fixes to critical OS packages. > > Understood. > > >> 2. I think that the UPX binaries shipped by FreeDOS are linked with > >> the NRV compressor library, which is nonfree and closed source. This > >> is obviously not desirable. > > > > I am not saying you are wrong. Or, there is no problem. But, I would > > like to get some clarification. > > > > The UPX site[5] states: > > > > • free: UPX is distributed with full source code under the terms of > > the GNU General Public License v2+; either under the pure GPLv2+, or > > (at your option) under the GPLv+2 with special exceptions and > > restrictions granting the free usage for all binaries including > > commercial programs as stated in the UPX License Agreement > > > > We do not build UPX from source. We use the official pre-compiled > > versions they provide on GitHub[6]. > > > > Also if I understand you correctly, you are referring to the UPX > > binaries themselves and not the binaries compressed with UPX. > > Right, the depacker that UPX includes in binaries it has compressed is > considered a type of linking the compressed program with UPX. There's a > GNU GPL exception in the UPX license [7] for this that is applied to > UPX, to allow usage without making the program to compress affected by > UPX's copyleft. > > About my concern, the *compression* part of UPX, this is what the "upx > -V" command of the latest build on ibiblio.org [8] displays: > > E:\>upx -V > upx 4.0.2 > NRV data compression library 0.84 > UCL data compression library 1.03 > zlib data compression library 1.2.13.1-motley > LZMA SDK version 4.43 > Copyright (C) 1996-2023 Markus Franz Xaver Johannes Oberhumer > Copyright (C) 1996-2023 Laszlo Molnar > Copyright (C) 2000-2023 John F. Reiser > Copyright (C) 2002-2023 Jens Medoch > Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler > Copyright (C) 1999-2006 Igor Pavlov > UPX comes with ABSOLUTELY NO WARRANTY; for details type 'upx -L'. > E:\> > > The page for NRV [9] is now very small, it just says: > > > NRV data compression library > > > > Discontinued - superseded by our stunning LZO Professional Plus > technology. > > An older revision of this page [10] as linked by the english Wikipedia > [11] is longer, but also does not list NRV as FLOSS in any way: > > > NRV generic data compression library > > Not Really Vanished, the next-generation data compression library, is the > > flagship of our embedded data compression technology for small devices. > > NRV introduces the paradigm of generic programming into the world of data > > compression. It does this by orthogonally decoupling concepts like memory, > > models, filters, coders, algorithms and implementations. Furthermore all > > details can be fine-tuned by using so-called policy classes. > > NRV is written in C++ and consists of a huge number of template classes. > > For systems which lack a recent C++ compiler (like some embedded systems) > > it can get translated into ANSI C by a special compiler frontend. > > If you are unfamiliar with this concept, you can view the generic > > decomposition as an extremely powerful preprocessor which preserves type > > safety and value semantics. > > The latest version is still build 1.183, which runs very stable for quite > > some time. On the development side our focus has shifted to the LZO > > Professional technology since. > > The license cell in the Wikipedia page's info box [11] lists the UPX > license as "GPL with exception for compressed executables,[1] > proprietary for compression algorithm in binary distributions[2]". The > link "2" in this blurb goes to the "README.SRC" file in their repo [12], > which reads in its foreword: > > > The precompiled UPX versions are linked against the NRV compression > > library instead of the UCL library. Using the same compression > > algorithms, > > NRV achieves a better compression ratio. NRV is not publicly > > available, though, and probably never will be. > > (The next paragraph after this contains some fluff related to NRV being > closed source.) > > Your link to the upx.github.io landing page [5] is indeed confusing on > this matter, as it states "free: UPX is distributed with full source > code under the terms of the GNU General Public License v2+". That about > the "full source code" is in my opinion not true when the default builds > ship with the closed source NRV. > > Briefly, if the default builds use NRV, you want to have an UPX-UCL > build (using the FLOSS UCL library for compression rather than the > closed source NRV). Unfortunately I don't recall whether I have a DJGPP > build environment on our server, so I cannot at this time provide builds > like I do for a few programs [13]. > > I did want to bring up the UPX-NRV problem for a while however. Perhaps > someone can provide UPX-UCL builds before the FreeDOS 1.4 release. > > Regards, > ecm > > > [7]: https://upx.github.io/upx-license.html > [8]: > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/upx/4.0.2/ > [9]: http://www.oberhumer.com/products/nrv/ > [10]: > https://archive.ph/20120909151357/http://www.oberhumer.com/products/nrv/ > [11]: https://en.wikipedia.org/wiki/UPX > [12]: > https://github.com/upx/upx/blob/3757579ffc6fa8710b4b7a1055529fea9dcaf149/README.SRC > [13]: https://pushbx.org/ecm/web/#projects-subsection-otherbuilds > > > > [5] https://upx.github.io/ https://upx.github.io/> > > [6] https://github.com/upx/upx/releases > > https://github.com/upx/upx/releases> > > > >> > >> [1]: > >> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/FDT2411-FullUSB.zip > >> > >> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/FDT2411-FullUSB.zip> > >> [2]: > >> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/FDT2411-BonusCD.zip > >> > >> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/FDT2411-BonusCD.zip> > >> [3]: https://sourceforge.net/p/freedos/mailman/message/58836419/ > >> https://sourceforge.net/p/freedos/mailman/message/58836419/> > >> [4]: https://pushbx.org/ecm/doc/ldebug.htm#news-r9 > >> https://pushbx.org/ecm/doc/ldebug.htm#news-r9> > > > > _______________________________________________ > 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
