App testing:

- Boot Manager/Loader, BOOTMGR (multi-BOOT ManaGeR): 6kb < FREEWARE
TINY, Simple, works as described .... appears "fairly modern" (it appears aware of cira 2000 era features).. should be able to launch from, disk, "new" floppy or optical.
** Randish Partition Manager has a "near equal" feature, somewhat making this REDUNDANT

- File Manager, PC Valet Shell: 17kb (26K, 17K unpacked & recompressed with UPX), 11K more for the hex editor & other add ons (is this freeware?)
Super light & decent for its size, in light testing seems to work well. I am still having UPX issues unpacking and repacking.

- Partition tool, Ranish Partition Manager 2.37: 57kb (minus its help file) < FREEWARE
Nice, intuitive, easy! very neat little tool. UI/On Screen Text/Prompts = easy to navigate for users not familiar with fdisk/etc.
** Includes its own boot manager, wild/awesome!

- Backup/Restore Tool - ToolWorks Pro 162kb < OEM with some "Conner" Peripherals (& an "unnamed" motherboard maker, according to WinWorld)
Great program, BUT a bit large (trimming out scheduler's utility exe + scheduler's overlay & readme/help txt, as shown in size above, saves abit). IMHO better than others tested, by a fair margin.
Has " Mono/"BW" (black & white) support, plus readme states "compatible with older, non-compatible PC, XT or ATs" (but not in high speed mode)
**further testing shows "full" (non-scheduled) functionality from: BP.EXE + BPUTILS.EXE + backuppro.cfg = 162kb (but no help/readme files)
*** Makes "calls" to DOS commands "chkdsk", "format", plus (unneeded) Scheduler & Report + Compare functions call BPT.COM & BPUTILS.EXE, respectfully.
**** what are the 6 "overlay" files, I think they may be non-english exe variants/extensions? unsure, if you know clue me in

- shcdx86.com (& shsucdx.com) + cdrom.sys (& vide-cdd.sys)
appears to work in fast (emulated) test

EXTPE, Alpha.01 - test
Please test me, feedback sought

If you understand UPX compression better than I do, please inform me of why I am unable to UPX any of these under my win10 workstation's UPX GUI?

- 720kb image, bootable (on XT+), Assumes its in "A:\" drive by default
- Includes: Base PC-DOS7.1 Rev 0 boot disk + himem.sys, cdrom.sys, shcdx86.com & ctm21b4.exe (all loaded by default) >> optical drive will default to "D:\OPTICAL"
- Apps: Costa GUI, PC Valet File Manager, ToolWorks Pro Backup & Randish Partition Manager
- 83.9kb free space remaining (possibly 53.6kb more can be saved)
- Room left for?: fdisk32, format, format32, chkdsk ... and perhaps "e" (PC-DOS's editor) ... a network driver??

Auto launches Costa GUI, with exit to DOS prompt option.
- Launching a (target action) shortcut app, DOS-prompt, or "execute" will: "pauses/terminates" costa from memory > launches "target action" > on exit of "target action", costa "restores" to its desktop to memory
- Additional icons/shortcuts may be added, with up to 5x (five) desktop "pages" (Approx. 150+ "well labeled" shortcuts/icons, about 30x per "page", supported)
- the 4x (four) shown icons are the only ones included to use, also there is only 1x (one) included "theme", the shown "mono/b&w" theme as default (I am considering swapping to the "inverted b&w" theme)

If I take Costa GUI down to a single icon option (the "DOS-prompt" one), image can save an additional 1.6kb
If Costa can "see" Cute Mouse (and not its own MOUSE.COM), image can save an additional 32kb

If PC Velet is stripped to just file manager (remove valet.oo1/valet.002 = the hex editor & other add ons) image can save an additional 11kb
If PC Valet's main "valet.exe" can be UPX compressed, image can save an additional 9kb

I am 98% confident this release is flawed/can be improved. Especially autoexec.bat & config.sys improvements (I am not at all an expert in this area)

Appears pretty functional to target use (a PE for XT/AT systems), would be nice to prevent Randish Partition Manager "force closing on open" on systems where no fixed disk is detected, but otherwise fine

720kb is limiting...
"I never thought I would long for the capacity of a 1.2mb floppy disk" - Aazard

Freeing up more space:
- Some work looks like it can free up approx. 22kb more, very easily, mostly in PC Valet.
- Himem.sys may be unneeded (EMM386 is not present...not all "target" systems will have even 640kb+ ram), thats an additional 15kb space saved.
- Getting COSTA GUI to see cute mouse (ctm21b4.exe) & not its own "mouse.com", thats an additional 32kb space saved.

= 83.9kb (current free space) + 32kb (costa's mouse.com removal) + 22kb (PC Valet valet.001/valet.002 removal + UPX packing) + 15kb (himem.sys removal) = 152.9kb free space (total)

Space needed to include "more" PC-DOS 7.1 file additions:
- chkdsk.com, fdisk32.com, format.com, format32.com (nice, could be skipped to save 20kb) & e.exe = 144kb of space needed
- NE2000.com (example network driver) is 6kb (6kb of space needed)
- For above = 150kb of space needed

// This would leave, 2.9kb of free space, at the most! //

Possible useful addon (for rare pre 386 systems with assess to USB, via Lo-tech ISA USB Adapter or Others)
- USB device support? (for CH375B??) usbaspi.sys (38kb) & di1000dd.sys (16kb)

Nice fun addition:
- Pure text-mode (no need for ANSI.SYS/NANSI.SYS driver) ANSI art Logo, similar to this: https://pastebin.com/WE6QmzAX, But edited to say "Welcome To EXTPE, Powered by PC-DOS 7.1", displayed for 5 seconds, (about 1kb?)

1@Echo off
2CLS
3echo                                   Welcome To
4echo                          ÜÜÜÜÜ       ÜÜÜÜÜ  ÜÜÜÜÜÜÜÜ
5echo                          Û    Û     Û    Û Û        Û
6echo                          Û     Û   Û     ÛÛ  ÜßßßßÜ  Û
7echo                          Û      ßÜß      ÛÛ  Û    ÛÜÜÛ
8echo                          Û   Û       Û   Û ßÜ ßßßßÜÜ 
9echo                          Û   ÛÛ     ÛÛ   Û   ßÜÜÜÜ  ßÜ
10echo                          Û   Û Û   Û Û   ÛÛßßÜ    Û  Û
11echo                          Û   Û  ßÜß  Û   ÛÛ   ßßßß   Û
12echo                          ÛÜÜÜÛ       ÛÜÜÜÛ ßÜÜÜÜÜÜÜÜß                                      
13echo                         ÛßßßßßßßßßÜ ÜßßßßßßÜßßßßßßßßßÜ 
14echo                         Û         Üß      Û           ßÜ
15echo                         Û        Üß      Û    ÜßßßßÜ   Û
16echo                         Û    ÛßßÛ    ÜßÛßÛ   Û ÛÜÜÜ ßßß
17echo                         Û    Û  Û   Û  Û  ßÜß  Û   ßÜ
18echo                         Û    Û  Û   Û  Û   Û   ÛÜ    ßÜ
19echo                         Û    Û  Û Üß   Û   Û   Û ßÜ   ßÜ
20echo                         Û    ßßßßß    ÜÛÜÜßßßÜÜß Üß    Û
21echo                         Û            Üß  Û    ßßß      Û
22echo                         Û           Üß    Û           Û
23echo                         ÛÜÜÜÜÜÜÜÜÜÜßßÜÜÜÜÜÜßÜÜÜÜÜÜÜÜÜß     
24echo.
25echo                                       7.10

Additional thought for (semi-related) "easy PC-DOS 7.1 Rev 0 BLD134 install disk".
Idea based off Phil's Computer Lab's "DOS Boot Disk Easy and Fast": https://www.philscomputerlab.com/dos-boot-dis … -easy-fast.html
Driver selection trimming & replacement: SHCDX86/SHSUCDX (replacing MSCDEX.EXE, only 1, system depending), CDROM.SYS/VIDECDD.SYS (select 1) & CTM21B4.EXE (ideal?)

"totally spitballing" this idea: (my understanding of PC-DOS 7.1's fdisk32 is limited), my understanding of PKZIP/PKUNZIP self-extracting files is also limited, but I assume this is the ideal option?

Zipping PC-DOS & included drivers, & including/using "PKUNZIP", plus pre-configured "txt" to copy/rename as autoexec.bat & config.sys, "should" allow contents to fit on a 720kb floppy disk image?
Used post fixed disk/partitioning setup:
- Use FDISK32 to delete all existing partitions (if not done already)
- At "A:\> prompt", run "FDISK32 1 /pri:n" < where "1" is the "target disk", "/pri" creates a primary partition on target disk & ":n" is the size for partition created in megabytes (replace "n" with digits)
- Reboot
- "A:\> prompt", run "FDISK32 1 /mbr" < to create a master boot record
- Then run, "FORMAT C:/s" OR "FORMAT32 C:/s" < for FAT16 or FAT32, respectfully, to make it bootable ("C:" is assumed)
- I ASSUME THE ABOVE COULD BE "AUTOMATED", with user input/choice, via a BATCH FILE
- Then run the below "install.bat" (then reboot):

NOTE: PKZIP/LHA/LHARK self-extracting file would be better, but I do not fully understand their switches/use (yet)
- Preserving directory structure & 16-bit compatibility appears no issue?
- UPDATE: I found wiz 5.03 for info-zip (it seems to support 16bit targets for the sfx's made)

1@ECHO OFF
2if not exist c:\drivers\nul md c:\drivers
3if not exist c:\dos\nul md c:\dos
4PKUNZIP /D a:\dos_and_drivers.zip c:\ /y
5copy a:\autoexec.txt c:\autoexec.bat /y
6copy a:\config.txt c:\config.sys /y

aazard wrote on 2024-09-10, 19:29:

Additional thought for (semi-related) "easy PC-DOS 7.1 Rev 0 BLD134 install disk".

FWIW - maybe this will give you some more ideas:
(please keep in mind that I'm trying describe something I did MANY years ago!)

Back in the day when I distributed software on both "floppy disks" and via
emailed installers - I wanted to keep things as small as reasonably possible,
I thought about self-extracting .ZIPs, but decided not
to got that route for a few reasons:

- Not workable for non-executable files.

- You don't have as much control as I would have liked in unpacking and
placing the files.

- You include the extraction code with every executable.

What I ultimately did was to create my own file archive/compress tool: MAR
(MicroARchiver) - I don't think it compressed quite as well PKZIP, but it didn't
need to include the decompress code with every file, and it was completely
under my control. Also, I could put the decompressor, menu based selection
code AND all of the compressed files into a single .EXE on my install disks.

For many years I did not publish MAR or it's format spec. but as part of my
retirement "publish everything I can that I wrote over the years), It is now
available in the source code are of my site.

You can still see a good example of this in the "bootable" version of ImageDisk
that I have at: DavesOldCompuresr -> Software/Images -> Bootable diskette - IMD

It is designed to boot DOS with optional support for CD/DVD, USB mass-strage
and unpack various tools and utilities including DOS tools, FileTransfer and
Networking, and ImageDisk with it's tools onto a RAMdisk that you could run
things from ... I did this mainly to allow ImageDisk operation on systems which
didn't have DOS installed, but you can boot it anywhere as it doesn't "install"
anything.

Attached "BOOTIMD.TXT" has a list of whats on this diskette with a bit of
description.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Will be updating autoexec.bat & config.sys, with info found at: https://web.archive.org/web/20200501031351/ht … osretro/dosmods, via this post: PC-DOS 7 Memory Tricks, to implement "usable memory" improvements.

These settings should be shareable between EXTPE & the Easy PC-DOS 7.1 Rev 0 BLD135 installer

See "cloaking" below

Drives "a:\" & "c:\", are interchangeable, depending on target (ie: EXTPE is run fully from floppy)

AUTOEXEC.BAT file:
- add the line: "a:\CLOAKING.EXE" before the mouse driver is loaded.
- add the line: "LH a:\SHCDX86.COM /D:OPTICAL" or "LH a:\SHSUCDX.COM /D:OPTICAL" (system depending)
- add the line: "LH a:\CTM21B4.EXE"

CONFIG.SYS file:
- ensure lines:
"[COMMON]" (for menu)
"DOS=HIGH,UMB"
"FILES=30" (is this too high, maybe 15? Can "FILESHIGH" be used?)
"BUFFERS=30" (is this too high, maybe 15? Can "BUFFERSHIGH" be used?)
"DEVICEHIGH=a:\setver.exe" (Is this is fine as "DEVICEHIGH" and not "DEVICE"?)
"STACKS=9,256" (is this correct/optimal? Can "STACKSHIGH" be used?)
"SWITCHES=/I" (What does "/I" do?)
"LASTDRIVE=Z" (Should I leave a few drive letters, if so, why?)
NOTE: What are "STACKS" & "SWITCHES"? (I will look it up of course)
- add the line: "DOSDATA=UMB" (load DOS system tables in upper memory)
- add the line: "SHELL=a:\COMMAND.COM /E:512 /P /H" (/H parameter loads COMMAND.COM into upper memory, saving approx. 13K .. what does "/E:512" & "/P" do?)
- add the line: "DEVICE=a:\CLOAKING.EXE" after the supported memory manager is loaded.
- "re"-add HIMEM.SYS v3.15 & EMM386 v4.5 (from PC-DOS 2000, dated 1996-12-24, 14kb & 117kb, respectfully) & entries
- add the line: "DEVICE=a:\HIMEM.SYS /TESTMEM:OFF"
- add the line: "DEVICE=a:\EMM386.EXE RAM I=B400-B7FF" (Does "RAM I=B400-B7FF" still allows mono video mode?)
- add the line: "DEVICEHIGH=a:\CDROM.SYS /D:OPTICAL" (Do I need to set the IRQ and I/O range of the IDE controller, with CDROM.SYS?)

Plus add Boot Menu, to config.sys (with matching config.sys entries for each):

1[COMMON]
2DOS=HIGH,UMB
3DOSDATA=UMB
4FILESHIGH=30
5BUFFERSHIGH=30 
6STACKSHIGH=9,256
7SWITCHES=/I
8LASTDRIVE=Z
9SHELL=a:\COMMAND.COM /E:512 /P /H
10DEVICEHIGH=a:\setver.exe
11
12[menu]
13menuitem=EC, Expanded memory + CD-ROM
14menuitem=XC, Extended memory + CD-ROM
15menuitem=CC, Conventional Memory only + CD-ROM
16menuitem=A, User Defined A (set as clone of "EC" settings by default)
17menuitem=E, Expanded memory
18menuitem=X, Extended memory
19menuitem=C, Conventional memory only
20menuitem=B, User Defined B (set as clone of "E" settings by default)
21
22menudefault=EC,10
23
24[EC]
25DEVICE=a:\HIMEM.SYS /TESTMEM:OFF /NUMHANDLES=128 /VERBOSE
26DEVICE=a:\EMM386.EXE RAM I=B400-B7FF
27DEVICE=a:\CLOAKING.EXE
28DEVICEHIGH=a:\CDROM.SYS /D:OPTICAL
29
30[XC]
31DEVICE=a:\HIMEM.SYS /TESTMEM:OFF /NUMHANDLES=128 /VERBOSE
32DEVICE=a:\CLOAKING.EXE
33DEVICEHIGH=a:\CDROM.SYS /D:OPTICAL
34
35[CC]
36DEVICEHIGH=a:\CDROM.SYS /D:OPTICAL
37
38[A]
39DEVICE=a:\HIMEM.SYS /TESTMEM:OFF /NUMHANDLES=128 /VERBOSE
40DEVICE=a:\EMM386.EXE RAM I=B400-B7FF
41DEVICE=a:\CLOAKING.EXE
42DEVICEHIGH=a:\CDROM.SYS /D:OPTICAL
43
44[E]
45DEVICE=a:\HIMEM.SYS /TESTMEM:OFF /NUMHANDLES=128 /VERBOSE
46DEVICE=a:\EMM386.EXE RAM I=B400-B7FF
47DEVICE=a:\CLOAKING.EXE
48
49[X]
50DEVICE=a:\HIMEM.SYS /TESTMEM:OFF /NUMHANDLES=128 /VERBOSE
51DEVICE=a:\CLOAKING.EXE
52
53[C]
54
55[B]
56DEVICE=a:\HIMEM.SYS /TESTMEM:OFF /NUMHANDLES=128 /VERBOSE
57DEVICE=a:\EMM386.EXE RAM I=B400-B7FF
58DEVICE=a:\CLOAKING.EXE

And to autoexec.bat

1@ECHO OFF
2SET DIRCMD=/O
3SET PROMPT=$p$g
4SET PATH=\;a:\;
5SET TEMP=\;a:\;
6GoTo %config%
7:EC
8:XC
9:CC
10:A
11LH a:\SHCDX86.COM /D:OPTICAL  (or "LH a:\SHSUCDX.COM /D:OPTICAL", system depending)
12:E
13:X
14:C
15:B
16
17a:\CLOAKING.EXE
18LH a:\CTM21B4.EXE
19a:\COSTA\COSTA.BAT

/

CLOAKING.EXE - allows the DOS mouse driver to be loaded in extended memory, freeing valuable conventional & upper memory for DOS applications.
Work with any of the following extended memory managers:
- EMM386.EXE & HIMEM.SYS [Also: RM386.EXE (v3.03 or later), QEMM386.SYS (v7.1) & 386MAX.SYS (v5.0)]

/

Note: The Last Byte Memory Manager
- Need to look into if this is a allowable/reasonable include

Note: LFN support:
- LFNDOS.EXE, Chris Jones (1999), 1999-08-29: v1.0.6: Seems to support all 16-bit (should work on 8088+)
- Unsure how useful this would be

DaveDDS wrote on 2024-09-10, 23:14:

FWIW - maybe this will give you some more ideas: (please keep in mind that I'm trying describe something I did MANY years ago!) […]
Show full quote

aazard wrote on 2024-09-10, 19:29:

Additional thought for (semi-related) "easy PC-DOS 7.1 Rev 0 BLD134 install disk".

FWIW - maybe this will give you some more ideas:
(please keep in mind that I'm trying describe something I did MANY years ago!)

Back in the day when I distributed software on both "floppy disks" and via
emailed installers - I wanted to keep things as small as reasonably possible,
I thought about self-extracting .ZIPs, but decided not
to got that route for a few reasons:

- Not workable for non-executable files.

- You don't have as much control as I would have liked in unpacking and
placing the files.

- You include the extraction code with every executable.

What I ultimately did was to create my own file archive/compress tool: MAR
(MicroARchiver) - I don't think it compressed quite as well PKZIP, but it didn't
need to include the decompress code with every file, and it was completely
under my control. Also, I could put the decompressor, menu based selection
code AND all of the compressed files into a single .EXE on my install disks.

For many years I did not publish MAR or it's format spec. but as part of my
retirement "publish everything I can that I wrote over the years), It is now
available in the source code are of my site.

You can still see a good example of this in the "bootable" version of ImageDisk
that I have at: DavesOldCompuresr -> Software/Images -> Bootable diskette - IMD

It is designed to boot DOS with optional support for CD/DVD, USB mass-strage
and unpack various tools and utilities including DOS tools, FileTransfer and
Networking, and ImageDisk with it's tools onto a RAMdisk that you could run
things from ... I did this mainly to allow ImageDisk operation on systems which
didn't have DOS installed, but you can boot it anywhere as it doesn't "install"
anything.

Attached "BOOTIMD.TXT" has a list of whats on this diskette with a bit of
description.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Thank you I will test "MAR" as a possibility... great collection of tools you have made!

@DaveDDS

I really like the menu you did. Do you by any chance have it available as a standalone tool?
It would be really great to reuse it. It looks straight-forward, and seems non-bloated, much like much all of your programs.

igully wrote on 2024-09-11, 11:47:

I really like the menu you did. Do you by any chance have it available as a standalone tool?
It would be really great to reuse it. It looks straight-forward, and seems non-bloated, much like much all of your programs.

I was just looking at that (it really has been years) - These tools were kind of
done of "on the fly", are not really documented, and not really set up for
"general use".

I am looking into making it more general and publishing it - give me a few days/weeks!

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Jacob at COSTA GUI has confirmed and updated a few questions on specifics of min specs:

- An 8088 or better CPU (386 or better recommended).
- EGA or VGA graphics supporting 640x350 pixels at 16 colors (most newer EGA or any VGA compatible card should do). (aazard note: so 64kb vram?)
- A recommended minimum of 200 KB available memory while running Costa. When running external programs or games, Costa will use about 8 KB RAM.
- MS-DOS 4.0 or newer, or a compatible operating system.
- A mouse is optional. If used, a mouse driver must be loaded (DOSBox has a built-in mouse driver). (aazard note: can drop mouse.com, for cute mouse 2.1b4, & save 32kb!)

(*DC = Disk caching software (SmartDrive or similar) when running on older machines - especially if running Costa from a floppy drive.)

/
COSTA's DC feature should wok, on an 8088/XT with (I'll test them and report back):
- Cache86 V3.02 [V5.03?]
- DR-DOS 7.03 disk cacher (NWCACHE.EXE)
- Norton Cache 2 (NCACHE2.EXE)
- Helix's CACHECLK.EXE v4.2
?.. QRAM v1 (does it have a cache feature?)

DaveDDS wrote on 2024-09-11, 15:12:

I am looking into making it more general and publishing it - give me a few days/weeks!

Ok, I've tossed together a little "more general" package install/unpack tool.
If it's close to what you want, let me know and I'll get it published on my
site.

It uses a (text based) .PKG file which describes the package content and how it
should be unpacked (I've attached TSTPKG.TXT which is TST.PKG one I created
for a "test" package I've been using it work with it - there are comments within
describing the entries)

When you run MKPKG:
---------------------------
E:\PKG> mkpkg tst
PCDOS\ATTRIB.COM 2702
PCDOS\CHKDSK.COM 12209->12136
PCDOS\DEBUG.COM 14910->14803
PCDOS\FORMAT.COM 22376->22209
PCDOS\MEM.EXE 14501->14450
PCDOS\MODE.COM 13991->13894
PCDOS\MORE.COM 1248->1151
PCDOS\MOVE.EXE 11392->11337
PCDOS\SUBST.EXE 8529->8477
PCDOS\TREE.COM 2286->2284
Y:\cmds\EDT.EXE 10946->10898
cmds\UNZIP.EXE 24052->23956
Y:\cmds\XCOPY.COM 4234
Y:\cmds\DDLINK.COM 17256
Y:\cmds\PC100.COM 21780->21747
cmds\XMODEM.COM 6540->6533
U:\misc\imd\IMD.COM 34143->20685
U:\misc\imd\IMD.HLP 48860->19792
U:\misc\imd\IMDA.COM 5156->3409
U:\misc\imd\IMDU.COM 12817->7377
U:\misc\imd\IMDV.COM 16747->10308
U:\misc\imd\TESTFDC.COM 10085->6169
Tu=316760 Tc=255807 Exe6508+858=263173
E:\PKG>
---------------------------
Most lines show the files it's adding to the package (shown in "real time"
with twirling /-\- while it's working) then either number->number indicating
how much the size compressed. or a single number indicating that this file
couldn't be compressed.

Note that most of these files are precomressed executables (which I often do
for bootable disks to reduce floppy disk size - for .COMs I usually use my own
tool, or for .EXEs UPX) - so most didn't further compress much!

The last line shows the TotalUncompressedSize, TotalCompressedSize and Exe
file size (6508 is the actual .EXE, 858 is the header with names and other
information it needs) the final number is this + Tc=

This generates <package name>.EXE (in this case TST.EXE) which is the ONLY file
you need to "give out" to that others can install your stuff!

Here are the files:
24-09-14 9:33a 15,259 MKPKG.COM
24-09-14 9:15a 1,424 TST.PKG
24-09-14 10:05a 263,173 TST.EXE

Note that although TST.EXE is BIG, that's because it has the compressed package
data appended to it - when run, it only loads 6508 bytes into memory, gets the
rest by reading the .EXE file (Thats why I used .EXE as .COM which I tend to
prefer for small programs would try(and fail since it's >64k) to load the whole
thing into memory.

Attached MKPKG.PNG shows what you see when you run TST.EXE

|> symbols on left mark sections/groups of files, and lines beginning with ' '
are the files in that section. <> (diamonds) indicate which files are selected
to be installed. You can press SPACE to toggle selection of individual files,
SPACE on a section selects/deselects all files in that section.

The white bar at the top is the selection marker which moves up/down to show
"where you are" - screen/items will scroll as needed.
ENTER unpacks/installs all selected files, ESC quits.

Suggestions/feedback are of course welcome!

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

So, in essence, MKPKG for the end-user, has only a disk footprint of about 7.5 KB + the content to deploy. It seems really good.
Which should be the minimum requirements, for the end user (not for the package builder)? I mean minimum DOS version, CPU, RAM and display adapter type.
Also, does it have any limitations/checks regarding file systems and free disk space?
Can the end-user run it from read-only media?

Sorry to bother you with questions, but I really like the overall concept, and think many could potentially benefit from it to deliver all sorts of programs/packages.

Dave, thank you again for all your software.

igully wrote on 2024-09-14, 16:58:

So, in essence, MKPKG for the end-user, has only a disk footprint of about 7.5 KB + the content to deploy. It seems really good. […]
Show full quote

So, in essence, MKPKG for the end-user, has only a disk footprint of about 7.5 KB + the content to deploy. It seems really good.
Which should be the minimum requirements, for the end user (not for the package builder)? I mean minimum DOS version, CPU, RAM and display adapter type.
Also, does it have any limitations/checks regarding file systems and free disk space?
Can the end-user run it from read-only media?

The end user doesn't see or have to know about MKPKG, they would have only the single
<pkname>.EXE which has 6508 bytes of code

plus: a header which consists of destination directories, file names, optional descriptions,
(the preceding are all in zero-terminated strings (namelen+1 bytes), and an additional 8 bytes
for each file (compressed/uncompressed sizes)

plus: the actual compressed file data (which for any files that couldn't be compressed
will be the origionalsize of the file.

MKPKG allocates a large memory buffer, and uses a temporary file in the process
of compressing and building <pkgname>.EXE, but <pkgname>.EXE does not allocate
any extra memory or use any temp files., and only creates the destination directory
and writes the files into them. (should run fine from RO media)

both are actually TINY model 80x86 which means they run in a single 64k
memory segment.

<pkgname>.EXE is currently limited to a maximum of 128 files and a 16k memory pool
to hold names/sizes/descriptions. I could probably expand this if needed, but that's a
pretty big package of files for a single floppy disk!

These are built using my own Micro-C/PC toolset, which generates code that will run
of an 8088/86, IIRC I was using DOS 3.3 when I first created it, and have never had problems
running it's code. I've used it on a few systems with 3.1, and maybe even one running 2.0
but I've never done any exhaustive testing/evaluations on older DOS versions.
(I still use DOS 5.0 on my DosOnly systems)

All display is text-only, and will run on CGA up - I've not checked the colors, but it would
be trivial to provide an option for MDA (the code will all work - just haven't checked to see
what foreground/background colors woukd look like)

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

It all sounds great. It seems the requirements are pretty low, which is indeed welcomed.

MDA support would be nice to have so as not to leave out any retro system. As long as there is enough contrast, everything should be fine whatever road you pick.
Speaking of display extremes, is CGA snow being considered?

DOS 3.3 seems more than enough too. No real need to go below it.
Memory-wise it seems to me that your estimations are more than adequate to suit almost any system out there.

Could you please extend the file limit just a bit? At 128, it could be limiting for certain specific uses which could demand more . I am thinking on game distributions and even complete small DOS deployments being limited with just 128.

Dave, thank you again.

igully wrote on 2024-09-14, 21:25:

MDA support would be nice to have so as not to leave out any retro system. As long as there is enough contrast, everything should be fine whatever road you pick.
Speaking of display extremes, is CGA snow being considered?

Could you please extend the file limit just a bit? At 128, it could be limiting for certain specific uses which could demand more . I am thinking on game distributions and even complete small DOS deployments being limited with just 128.

I don't have any systems with Mono video cards any more, but it is easy to test in DosBox
with MACHINE=hercules

It "almost" worked as its- you just can't see the white hilighted select bar.

Very easy to fix , I've added command line options -C (force color - white on blue),
-M (force Monochrome white on black) If you don't specify it will try to detect which.

Neither programs writes to the display enough for CGA snow to be a problem, you might
see a bit when paging though the install file list, and maybe a very little bit as it updates
the -/-\ twirl while compressing (only updates a few times/second)

The file limit is more because of MKPKG than <pkg>.EXE
MKPKG uses a lot of memory, it allocated as much as it can so that it can try to compress
(and see it the file is compressable) by compressing it into a memory buffer, if it works, it
writes that buffer, otherwise it writes the original file content) - since it's doing a bunch
of files - I don't want to write the "compressed bigger than original" version
for uncompressable files, and I don't want to have to compress twice (once to test, once
to write) - compression can be a bit slow!

MKPKG has tables and code to compress which takes quite a bit of space
- I think it has about 2k left for stack in the 64k TINY model. I could compile
it in SMALL model which would increase the amount of memory available for
the tables, but that would make it use another segment and reduce system
memory available for the large buffer

I expect if you are distributing a package with more than >100 files you
are probably going to want to do your own custom install program (not to
mention that it will probably span more than one floppy disk)

I envision MKPKG as a little tool to make it very easy to pack up a reasonable
set of files into a single simple to use "installer" where you can choose what
get unpacked.

I don't think any of my distributions ever had that many files (but then I
tend to try and keep things small and simple)

And - you can always have multiple <pkg>.EXEs if you really need that
many files on one install media.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

DaveDDS wrote on 2024-09-15, 02:31:

I don't think any of my distributions ever had that many files (but then I
tend to try and keep things small and simple)

Just looked, I did at one time offer "source code" packages which included things like sources
for my compiler, all of its tools, all library functions etc.

I also had one called "DDS" which basically had all of my software products (which was a lot
back in the day)

Needless to say, these had >100 files and also spanned multiple diskettes - they had
custom installers which extracted separate .MAR archives for the various packages and
components - it was "smart" enough to look for the .MAR archive it wanted to unpack
and only prompt you to put in the needed diskette if it didn't find it - that way
it worked seamlessly for floppy, CD and email distributions.

Even if I'd had it back then, I wouldn't have used MKPKG!

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Nice work ! Another old file program that may be useful is Buergs "List". I do recall early .com versions working on 8086 and 286. Was more DOS version dependent than cpu.
I still use v9.x on older systems. After his death someone compiled all his work: https://github.com/sebras/buerg

I've uploaded a preliminary version of "MKPKG" to my site.

DownloadFiles -> MKPKG

Anyone interested can give it a try, give feedback/suggestions, and I'll update as required.

In a day or two, I'll post the source code in the "retirement project" section.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

STATUS.TXT reflecting wrong date [future date to be exact] on https://dunfield.themindfactory.com/dnld/sc/STATUS.TXT

xa3d wrote on 2024-09-21, 16:15:

STATUS.TXT reflecting wrong date [future date to be exact] on https://dunfield.themindfactory.com/dnld/sc/STATUS.TXT

He missed typed, "MKPKG MaKe PacKaGe installer (24/9/17 22.1k)"