Hi Mateusz, >> LINK/LN worked for me for years with no problems on MS-DOS 6.22. > > Could work, although it will be EN-only... Would be better to have
Yes, it's EN only, but: 1) Usually one loads LINK.COM on boot and doesn't touch in again. Only messages are "LINK 1.0 -- Copyright (c) 1994 TBH-Softworx" and "LINK is already installed.". 2) LN.EXE isn't required for experienced users, because that the basic steps to create a new link are: Create PROGRAM.COM or PROGRAM.EXE of 0 bytes size. Then add a matching pair of "PROGRAM.COM R:\EALPATH\TO\PROGRAM.COM" to a plain-text file named "LINK$". (Entries are sorted alphabetically.) Example: "A.EXE D:\AURORA\A.EXE" (w/o quotes) -- Should be easy to write this part again in an NLS-aware version. (The rest of LN.EXE is only for convenience.) This is how I worked for years. I have ~90 links. By the way: LN.EXE needs an 80286. Not sure about LINK.COM. (We will need to discuss this later again in detail, but I think, if we add more packages and more to the "repo", then we need some nice filtering mechanism.) > multi-language support for all CORE packages (although that's not the > case even now, yet). I support this idea. > History note: > > In FDNPKG I was creating "links" automatically based on metada in the > packages. It was working by having a directory called "LINKS" in the > PATH, where FDNPKG was generating tiny COM files that were starting the > target application. The COM stub is there: > https://sourceforge.net/p/fdnpkg/code/HEAD/tree/trunk/comlink.asm That's similar to Stephen Harris' EXELINK: https://www.sweharris.org/post/2012-06-01-exelink/ LINK/LN author Oliver Fromme also mentions EXELINK as his inspiration. > ...but ultimately I don't like this approach very much, I think the > users should have the control over this, albeit it should be as simple > as possible to use. For example I though of something like this: > > C:\PROGS\ZIP\>LINKADD ZIP.EXE > system-wide 'ZIP' alias created and points to C:\PROGS\ZIP\ZIP.EXE > > C:\>LINKDEL ZIP > system-wide 'ZIP' alias removed That's how LINK/LN works. Except: Even your tiniest .COM file will occupy a full cluster on the disk. So, a lot of disk space will be wasted. LINK/LN is better here, because a file of 0 bytes just occupies a FAT entry, but no other space on disk. > This is something that would be relatively easy to add to SvarCOM, with > an almost zero overhead. I don't know if a third-party tool could be as > user-friendly... Feel free to replace LN.EXE with some code in SvarCOM. Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ _______________________________________________ Svardos-users mailing list Svardos-users@lists.osdn.me https://lists.osdn.me/mailman/listinfo/svardos-users
