Hi Tom, > On Mar 6, 2023, at 4:14 AM, tom ehlert <t...@drivesnapshot.de> wrote: > > Hallo Herr jer...@shidel.net <mailto:jer...@shidel.net>, > > am Sonntag, 5. März 2023 um 22:43 schrieben Sie: > >> Hi all, > >> I spent a few minutes looking at 386MAX. > >> Unfortunately, it is going to take at least a some work by someone >> (not me) before it could even be considered for inclusion. > >> First, it cannot even be run at present. The precompiled >> executables and even diskette versions are present along with the >> sources. However, the executables must be installed by it’s setup >> program which writes an user/serial number into the executables. >> Those executables will not run without that being done. The setup >> program (and source) are present as well. However apparently, serial >> numbers are not pre-generated and were created when producing the >> media. So, that is all the further I got during testing. > >> Someone who has access to old MS C and Assemblers laying around >> will need to work on this to get it functional. Thankfully, it looks >> like there are numerous batch files to automate the building >> process. It is a large codebase and porting it to open source >> compilers would take someone a very long time. Again, neither will be done >> be me. > >> As far as I could tell in my limited testing, the following would need done… > >> 1) Update Company/License/Copyright information to reflect the >> project was released to the public under GNUv3 by the author. >> 2) Remove or at least disable the user/serial number stuff in the >> executables. >> 3) Possibly, forego the requirement of using the setup program. > >> Since 386 is large, complicated and can be used under DOS with or >> without windows, it may be best that if we ever include a package >> for it, that the package binaries include the installer. This would >> permit installing the program and having it perform all the required >> steps based on the end users system. > >> Any volunteers? > > to start first: what would be the point to have 386MAX in freedos > distribution (after 20 years without it)? > > I know that it was somewhat important in the middle ages, but now? > > Tom >
You are correct. It is not really necessary. JEMM works very well. Most of the reported crashes related to memory are generally caused by improper configuration or bad code in the executing program and not the driver itself. By no means do I purpose replacing JEMM with 386MAX. Nor do I think we should even install it automatically with either BASE or FULL. JEMM does everything need and we want. 386MAX comes with a lot of “baggage” to configure, use and maintain. It is also enormous. I just think it could be nice to have 386MAX available as an alternative for end-users who may be experiencing compatibility issues or just prefer to use that memory management software. If it is ever updated to where it is actually usable, we (the FreeDOS community) might decide it could make sense to provide it on a Bonus CD. But, that probably won’t happen. A volunteer to work on resolving the issues that need fixing with 386MAX is unlikely to happen anytime soon. If ever. :-) Jerome > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > <mailto:Freedos-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/freedos-devel > <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
