Hi, > On Oct 3, 2023, at 9:20 PM, Danilo Pecher via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > I think the developer tools should go to the bonus CD. As was > mentioned, most FreeDOS users will probably use it to run legacy apps > and games. People who still have the knowledge to do some > honest-to-god proper DOS programming will probably be quite able to > switch the CD and install the stuff from the Bonus-CD or perhaps even > a dedicated developer CD, which then could include some libraries > (like pdcurses) and - a real must really - a version of Ralph Brown's > Interrupt list. > > I would also move VIM to the bonus disk as most 'normal' users won't > have a scooby-doo what to do with it. > > VIM, Watcom, GCC IA16 and FPC are large packages and would free up a > lot of space on the Live-CD for other stuff more suitable to the > casual user. > > Speaking of installing packages. I'm really reaching the end of my > tether with FDIMPLES. Has that ever been tested on real metal?
Yes, on multiple real machines. > It runs > fine in VMWare, but lob it on a 33Mhz 386 and you're in for a very > sluggish experience. Although FDIMPLES will run on nearly all hardware 8086 and up), it gets very sluggish on sub-486 hardware. There are several reasons for this. First, you are not viewing a simple list of programs. For each item, the program pulls in data from multiple files, directories and locations. Plus even more when viewing in language other than English. There can be upwards of 12 (or more) files/data points per item that are loaded, analyzed, parsed, combined and formatted for display. There is a good deal of processing going on behind the scenes. All of that data is handled through a caching system built into the program for the megabytes of processed data. When program memory is low, the cache discards the least needed information first. Do to the memory requirements of the external utilities used by FDIMPLES, the version provided with FreeDOS 1.3 was limited to a very small cache. This meant only a few things could be stored it memory at a time. More recent versions (on recent interim builds) use a few tricks to get around that problem and can use all of lower memory. This provided a great performance boost on slower machines. But, you might be surprised on how much data is processed and stored by the program. It can eat up all of lower memory rather quickly. Support for XMS memory will probably be added at some point to help alleviate the need of reloading/reprocessing cached data. FDIMPLES also permits navigation while still loading/processing an item. Doing so causes the program to abort processing of the item it is working on, discarding that data and moving to the requested item. The checking for a navigation request is only performed a specific points during the processing of an item. This is primary reason for perceived lag in the user interface during navigation on sub-486 hardware. Adding more places that per item processing would improve the perceived lag a lot. But, there is a lot of memory in use, open files, etc that need cleaned up when that occurs. I would not say it would be difficult to add. Just that there is some complexity involved and such “break” points are non-trivial. There a numerous ways that FDIMPLES can be improved. Things like improved responsiveness, reduced processing, improved memory and cache management, network and multiple repository support, searching and mouse support are just a few. Most of which will probably not happen until the next major version. Unfortunately, I am very time constrained now and for the foreseeable future. The next major version will be a long time coming. > I've switched to just pumping the packages > manually with unzip. Although this will work well enough for many of the zips, I highly recommend NOT extracting the packages with unzip. Most of the directories in the packages are pseudo-paths and not subdirectories. Those pseudo-paths get remapped by the package manager to file system paths during installation. For many packages, this won’t matter. But for some, they are configured for specific locations. A simple unzip, will result in files not being where they are expected. Using command line package managers like FDNPKG and FDINST instead of unzip will help prevent such configuration issues. They perform the pseudo-path remapping that may be required. > > cheers, Danilo > Jerome > > _______________________________________________ > 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
