Hi Michael, long mail ahead ;-)
Please do not mix long file names and FAT32: The former can even be used on FAT12 floppy. In FreeDOS, you have to load a LFN driver TSR to use it, but I think most of command.com already is LFN-aware. You may have to set some shell options in your startup files (config, autoexec). The question is which other apps need LFN support: As mentioned earlier, it would be possible to create a TSR (similar to SETVER in MS DOS) which knows which apps are LFN-aware and replaced LFN file and directory names in command line options by their short counterparts in the background for everything else. See that bunnyhop "c:\forest level\" fictional old game example :-) In which situations is FAT32 not stable? And which tools lack support for it yet? You probably know my point of view regarding CHKDSK: Because FAT32 partitions have way more metadata, CHKDSK (8086 compatible) did not get support for it, but you can use DOSFSCK (ported from Linux, needs 386 and enough free RAM) to check your FAT32 partitions. For defrag, I believe there were some initial steps towards FAT32 support, but it was long ago. Of course dosfsck does not look like scandisk, if style matters. The look and feel libraries of defrag or edit could be used, or probably something again ported from Linux, to stay in 32 bit C. Which other disk tools need more FAT32 support? > Highest priority is memory management In which sense? > followed by FAT32 support improvements See above. > and then improvements to out of the box tools for everything > from filesystem tools to something like what MSD provided. Let us know how you like hwinfo, nssi and informer :-) Which other tools should be improved (or added)? > Anti virus is very important, maybe some improvements > to clamav are in order. While it would be possible to port a newer clamav version to DOS, it is horribly bloated even on more powerful systems. My assumption is that new viruses for DOS are rare, so I would prefer something stripped down towards that virus ecosystem. You may also want to have a look at my old FDSHIELD which is vaguely similar to VSAFE but does not try to detect specific virus "brands" at all: It just detects, blocks and alerts on generic virus like activity, with simple command line options. > A stretch goal is to make Freedos Windows compatible, at > least 3.1 and 3.11. To a certain degree 3.1 works now, but > does enhanced mode work and could 3.1 / 3.11 be replaced by > an open source alternative on top of Freedos? I remember that you needed a lot of creativity to make Windows 3.1 386enh mode or Windows for Workgroups 3.11 in normal, non- safe mode work on FreeDOS, but I think some people did get it to work. Also, when you run Windows in FreeDOS in for example DOSEMU, the improved DPMI host of DOSEMU helps you. That said, you could try using DPMIONE, HDPMI or similar on raw hardware and maybe use 386SWAT to debug problems ;-) Regarding your other question: The standard answer is ReactOS which originally was meant to be a Windows NT (in 1996 started even as FreeWin95) alternative and actually did get updates in 2019 and now supports a few popular Linux filesystems, too. A common platform are virtual computers, but by now it should be working on reasonably widespread real hardware and apparently it is realistic enough to let MS Office 2010 run? Parts of the code co-evolve with Wine, but to be honest, if you want to use Windows software on a modern PC, Wine in Linux will often be sufficient anyway. ReactOS needs 96 and recommends 256 MB RAM, according to Wikipedia. Another way to run Windows software in DOS is Japeth's HX RT, which you could compare to an extremely extended DPMI extender including implementations of many popular Windows API calls: > https://www.japheth.de/HX.html > https://www.japheth.de/dwnload4.html This lets you run non-fancy Windows programs directly from the DOS prompt, for example compilers (non-graphical) or graphical apps which only use SDL or similar very compatible frameworks, such as QEMU or DOSBOX. Run virtual PC & DOS inside DOS! :-) Note that only half a dozen of the most basic Windows DLL are emulated, so do not expect to run Chrome on DOS with HX GUI. > I really like FLTK for example and seem to be remember a > freedos spin that used FLTK to provide a gui. Yes, that was a very nice project by Georg Potthast :-) > https://code.google.com/archive/p/nanox-microwindows-nxlib-fltk-for-dos/downloads > https://sourceforge.net/projects/fltk-dos/ It has a desktop with icons and Win95 style start menu, the Dillo web browser, FlWriter text editor, FlMail client, the sprsht spreadsheet and other things. > The system was roughly comparable to Windows 3.1. Not really. > I'll port Tyco's Q-Soft to Freedos for the real > time system and Linux for the gui ;-) Maybe I > can run the program in Linux using WINE... What is Q-Soft, which OS does it run on and why would you port 1 half to DOS and 1 half to Linux? > It would be awesome if open source modern video support > existed so you can do higher resolution in say FLTK or > Windows 3.x. As far as I remember, HX supports VESA graphics modes and I would expect FLTK to do the same. So instead of doing any low level mess with PCI / PCIe, you would just have to worry which VESA modes are supported and how the support could be improved, e.g. by some TSR. > A revival of the open source implementation of the > IPX protocol would be awesome. It would make a lot > of old dos games work and an IPX/IP gateway could > be a Linux server where the Linux server could handle > security (anti virus squid proxy anyone). I do not even remember what IPX was for, WfW 3.11 maybe? Eric _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
