henk717 wrote on 2022-12-12, 21:29:
It is definately possible to trim it down bigtime, the io.sys I use on my boot floppy is only 74kb. I did cheat a bit with that since my starting point was a io.sys which already had the logo removed.
I remember seeing an example for DOS 7 or 7.1 in the early 2000s, but I could not find information to replicate the same result today. I appreciate the insight and would like to find information about such a case. I have noticed some discussions on the MSFN board but they were centered on winboot.sys from DOS 8 (Windows ME).
henk717 wrote on 2022-12-12, 21:29:
How do you get it that small? I can't share the full details since I was trusted with a tool called IOPAK by its author on the promise I would not share it (He did not want people to spread things like LZDOS where people distribute this as some kind of free dos clone as the LZDOS author made it seem, while in reality its just a compressed io.sys file).
I understand, although I remember a case where I attempted to promote and collaborate successfully with a DOS app developer, a long time ago, for the UHARC archiver. As a result of discussions and being provided with a special beta version I ended up developing a jerry-rigged solution to integrate the archiver into Windows 9x in the early 2000s. I was not bound by any agreement about sharing my work and results, provided I gave proper credit to whom I should. I think that such a model approach of good cooperation for IOPAK would have been much more successful, but respect is mandatory at each stage.
I am not well aware about the LZDOS claims, but I think that any unrightful claim can be easily contested today and this is the natural approach.
henk717 wrote on 2022-12-12, 21:29:
So you do not have to compromise on features, infact there are patchers that can add windows 3.1 suppprt.
I am well aware of the wonderful W3XSTART patch and it works perfectly, after being tested for a couple of years. One of the reasons of slowly migrating to DOS 7 and FAT32 as the foundation for running dual-boot Win 3X and Windows 9x systems is precisely this flexibility. With a hex patch on KRNL386.EXE for FAT32, well documented on Vogons, I was able to have no inconvenience after running Windows and returning to dos. Using FAKESHAR is also a very good solution to avoid the compatibility problem of VSHARE VXD or the hassle of using SHARE as a TSR on single-user machine, so all these patches and solutions go on to make the Win 3X GUI mostly a success. Moreover, there is also the possibility of using WQGHLT VXD to achieve very good power saving capabilities so the Windows 3X installation is quite potent. There are other tools that address various limitations of DOS including batch-initiated reboot and shutdown.
What I could not achieve was aimed at the IFSHLP switchable functionality that could potentially make Windows 3X play nicely in a FAT16 DOS7 system. For this aim, having an IO.SYS that would avoid loading IFSHLP but still keep the paths for Windows 9x intact was my goal. Of course, SMARTDRV could be used with Windows 3X but it is slower in Windows and still uses up conventional memory all the time, whether you like it or not.
henk717 wrote on 2022-12-12, 21:29:
I am very happy with the one I have, and if you look hard enough I am sure you can find the articles back as well as io.sys files like this that are premade.
I didn't document the process over the years and have that promised secrecy so I can't give exact details. But my own bootdisk project I am very happy with.
I am glad that you achieved such results. Unfortunately, my attempts are not as successful today. Some 20 years ago the internet and search results were less clogged by different pointless aspects. I just hope that some approaches and tools would not get unused or, even worse, lost due to the fact that no-one passes the legacy. I think that this risk is much higher today.
henk717 wrote on 2022-12-12, 21:29:
And then with the right compression techniques you can then really trim the size down.
I once used hard approaches such as cutting down files by literally stripping data off the file or using resource editors to extract and modify PE 32 bit executables and some NE 16 bit ones as a hobby so I am partly aware of what could be done. Overall, I would prefer not to use compression techniques since it detracts too much from a reasonable approach. If I was going down that path, I could also revisit and reliably backtrack on the EBD.CAB concept abused by others, to reach an optimum bootdisk, but this would be lazy in a way. I could also force a MAX disk approach to get from an unformatted size of 1.44 to 1.62 MB, but then again, this would also be lazy as you would not contend with the serious limitations of 1,38 MB usable space. Another path would be to resort to FREEDOS but this is another problem in and of itself that does not solve all issues while bringing new ones on the table.
On a side note, I think that PE 32-bit EXE packers detract a lot from the real challenge of unbloated code created by compilers or masterful programming and it is quite unpleasant to be unable to understand where a particular developer spend a lot of time in improving its product and what kind of solution he devised to a particular challenge. This is why I avoid such an approach on other issues, whenever possible.
Ultimately my choice of MSDOS 7 is for simplicity, lack of surprises in creating or diagnosing a bootable real or virtual hard disk media and configuring the DOS or Windows environment from DOS.
