Hi Eric, > On Jul 29, 2021, at 10:16 AM, Eric Auer <e.a...@jpberlin.de> wrote: > [..] > Whether you want to spend 10 of your precious 640 kB to > speed up floppy I/O depends on whether you use floppies.
Not the only reason.. But, it is one of the reasons it is not run automatically in the installed systems config files. Also when incomes to the install media, it is only loaded when booting from floppy. >>> 22. This reminds me that your scripts should >>> check whether a sufficiently smart command.com > >> 1) Works fine on MS-DOS, PC-DOS and probably others. > > Your BAT scripts use no FreeCOM-specific features? You specifically asked about computed jump targets in BATCH files. That works fine under other OS like MS-DOS, PC-DOS and probably others… Not just FreeCOM. If you mean the installer by “your BAT scripts”, the answer is the DO use FreeCOM specific features. But, only after they are known to be running under the FreeCOM shell. If you mean batch scripts that get installed when the OS is installed, then generally they do not require any FreeCOM specific magic. But, that is not relevant anyway… Because you are running FreeDOS. Besides, they are for FreeDOS not for *-DOS. >> 2) Those are only done AFTER the installer makes sure it is >> running under FreeCOM. There are other things the installer >> does do that would not work under MS-DOS. So, it already >> has guaranteed that FreeCOM is being used by the time >> it gets around to using computed jump targets. > > Interesting, so you already check for that? :-) Not precisely. > How > do you implement "make sure to run under FreeCOM”? The install boot media passes an option to inform the installer what media was booted (Like floppy disk, live cd, etc). If this information is present, the installer can assume it was booted from the install media and running under FreeDOS. If this information is not passed to the installer, it assumes you booted some other way and re-spawns itself under FreeCOM. It’s not perfect. But, it works and is something you’d have to intentional try and break for it not to do what is expected. >> At present, only I update the "shipping packages”. > > Would it help you to have volunteers for the version checks? Version checking might help a little, but not that much. Jim is very good at noticing new versions for things and posting “news” items about the big ones and mirroring raw versions to ibiblio. Also, there is some custom stuff running on my server that monitors original websites for the packages. When for changes occur it publishes that information to an RSS feed which is available as a channel in the Slack group. What helps a lot are when those updated programs are provided precompiled and in a “ready to go” format. Accordingly, volunteers who would take those raw updates, compile and organize them, update there metadata, check for conflicts, etc. would be a huge help. On a side note, tomorrow I’m releasing a new multi-language open-source program that makes it easy to view information on installed packages from the command line. PKGINFO will show the metadata, disk usage, all files or just it’s executables and more. It also has an advanced wildcard making things like *XMS*, ED*LN, *X*86, F?X*, etc. all return logical results. But what I have not mentioned until right now, included in the PKGTOOLS package along with PKGINFO will be PKGMAKER. For more info on that, you’ll have to wait until tomorrow and see for yourself. Until then, have fun speculating on what it actually does. :-) >> a large number of still active projects are released as source >> only, or with their own installers, or in big globs of files >> that need reorganized to prevent utter chaos when installed. > > That is surprising in context of DOS. > >> It is a very time consuming process. > > Definitely! Yup. > > Eric :-) :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
