[Freedos-user] Hardware compatibility adventures
Hi! I stumbled upon a long page on PCI soundcards in DOS, Win and Linux: https://flaterco.com/kb/audio/PCI/index.html Compatibility is mediocre at best. Reminds me of the time 15 years ago when I collected sort-of DOS compatible PCI soundcards myself. The website also has a long page about how classic graphics cards no longer are supported in Linux. Sad for those classics, but at least most of those cards probably still work quite OK in DOS :-) https://flaterco.com/kb/video/X-regressions.html Those were the times... I hope the pages are useful for some of you! Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB keyboards [was Re: DOS Actively Used Scenarios]
Hi! Actually, many reasonably new computers supported the following: - boot from USB storage devices (flash sticks, SD cards in card readers, USB zip, USB floppy, USB CD/DVD, harddisks, SSD etc.) - use USB keyboards as if they were PS/2 - use USB mice as if they were PS/2 You may have to first configure the BIOS setup to tell it that you want to boot in legacy (BIOS, not UEFI) mode and that you want USB legacy support. One limitation is that PS/2 mice lack many extra features USB mice may have, so you will usually not get support for much more than 3 buttons, one of which can be a wheel. When doing some reaction time experiments, I also noticed that actual PS/2 keyboards had a more predictable delay between pressing the button and DOS noticing it. USB legacy support had more jitter and it was noticeable that USB processing sometimes delayed other activities of my app. So I preferred PS/2 keyboards in my experiment. I do not know whether USB serial or USB printer port devices are covered by BIOS based USB legacy support, but it would be interesting to know! Note that most BIOSes do not support plugging or changing legacy USB storage after boot. So you can only access USB storage that you booted from, or which at least was present at boot, that way. On the other hand, those will be presented to DOS as if they were their classic BIOS-supported non-USB counterparts, making it much easier for DOS to use them without having to load DOS USB drivers :-) Regards, Eric PS: Note that DOS wants MBR partitioned drives, not GPT partitioned ones. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB to RS-232 Adapters
Thank you for the license warning, Karen. The github page links e.g.: https://bluegrasspals.com/pipermail/dectalk/2020-June/005253.html https://bluegrasspals.com/pipermail/dectalk/2015-October/004517.html So it is probably not a good idea to use Dectalk as Linux synth. Which brings us back to the Dectalk USB. Luckily, it also has RS232. For DOS, I would recommend to use the RS232 connector and RS232 mode. If that PC has no RS232, the next choice are USB to serial cables. Which you may use with generic DOS USB serial drivers, or emulators. If RS232 mode of the Dectalk USB is not satisfactory, USB mode exists. I wonder if you can use DOS software for RS232 based Dectalk Express with Dectalk USB in USB mode once you install a generic driver for USB serial bridges. Or by using an emulator in which the entire DOS runs. Given that I do not know the answer for that, I would say the other two ways to use the device with DOS are more fool-proof than pure USB mode. There is no existing screen reader in Linux that is fully comparative to DOS programs. When I checked years ago, BRLTTY helped with braille screen access: https://brltty.app/ https://github.com/brltty/brltty It also supports some speech synths: Alva Delphi, Blazie BrailleLite, Elan Televox, IBM ViaVoice, Tieman CombiBraille and University of Edinburgh Festival. So while not being a pure screen reader, it may still be useful. The default screen reader for the Linux Gnome GUI apparently still is Orca. I do not know whether it is considered a comfortable option: https://orca.gnome.org/ There also is Voxin, but I have never heard of that before: https://voxin.oralux.net/ it seems to be related to Emacspeak, Fenrir, Orca, etc. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB to RS-232 Adapters
Hi Karen, I have checked the web regarding Dectalk USB: https://www.tegakari.net/en/2017/10/dectalk_usb/ shows an image of a small device indeed having both USB and serial port connectors, as well as a 6 volt power connector. you can also run it for 1 hour from a 9 volt battery. However, somebody on Linuxquestions.org complains about a 4 second delay when using the device in RS232 mode with Linux a few years ago. https://archive.org/details/dectalk-usb-user-manual comes as a single text file, which mentions that RS232 mode is Dectalk Express compatible, made by axsol access solutions, running Fonix Dectalk on a Dragonball cpu with 16 mb of flash and 32 mb of ram. rs232 speed is not given, but USB speed is 12 mbps, so the manual recommends to use USB. You can find an open source version of the Dectalk engine on github now: https://github.com/dectalk/dectalk This probably allows you to use it for software speech output on Linux. If you use any embedded controller with a serial, but no USB port built in, you always have 2 choices to connect USB: Add a bridge chip to your circuit or use an USB to serial cable which has the bridge chip built into it. Either way, a modern operating system will see an USB-based serial port and then let apps use that just like a serial port, but with a wider variety of speed choices. In DOS, you would first have to load an USB and bridge driver before you can access that not-physically-RS232 port at all. Running DOS in an emulator is another option, letting you use the drivers of the host operating system instead of needing DOS drivers. I would assume that quite a few software speech synths and screen readers are available for Linux, but I do not know which of them are how good. Anyway, we now know that Dectalk USB can be switched to RS232 mode, which lets you use it with actual RS232 ports. You can also use it in RS232 mode with USB to serial cables if no physical RS232 port exists ini the PC, or if you hope to improve transfer speed by using USB. Both will offer some degree of Dectalk Express compatibility, which is good in case the native USB mode of Dectalk USB differs too much from what DOS Dectalk drivers expect. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB to RS-232 Adapters
Karen, granted I was intending to connect my friend in California with Joseph Norton, he wants to run freedos, but use a USB speech synthesizer. If I follow what you say here, in theory at least, he could use this Linux USB drivers for the actual hardware, but in an emulator, tell say his screen reading program to use the simulated serial port? Depends on the nature of the USB speech synth. You can do it if the USB version of the synth in fact is just the serial one with an USB serial bridge chip added, or maybe even just an USB serial adapter cable to plug it to USB-only computers. In that case, you need nothing specific to the USB device. You only need a generic way to make the underlying serial communications visible to DOS. This can be done 1. by a DOS USB driver supporting your or generic USB serial bridges. Or 2. by running DOS in an emulator on an operating system with support for USB serial bridges, configuring only the emulator to make the right serial thing visible as if it were connected to the emulated RS232 port, even if it is not physically RS232 in the outside world. It could be USB, IrDA or Bluetooth, for example, depending on bridge chips. If, however, your USB speech synth has no serial port roots at all, it will probably need a quite different driver. One may write something which connects any speech synth your Linux or Windows supports to an emulator in a way which looks like a fixed, classic DOS compatible synth from the DOS side. That would be a very generic solution, but also more complex. It would be similar to having an ESC/P printer data capture thing connected to your emulator, creating a PDF of whatever DOS is printing, to give you flexibility on how to print the contents later, in the Linux or Windows hosting the emulator. Joseph has a build of freedos that uses something internal for speech. What does "uses something internal" mean here in technical terms? still I was wondering how Freedos itself would, or if it could simulate the same thing? DOS itself does not simulate things in that sense. But as said, you may get drivers for DOS which simulate for example RS232 ports from a BIOS or UART chip perspective, or tell an emulator to do that, without needing a DOS driver. The modern DOS drivers which simulate soundblaster hardware while using AC97 or HDA hardware for actual sound output are an impressing example of direct simulations without emulators. In the decades before those, you had to run the entire DOS in an emulator to get a simulated soundblaster, while the actual sound output worked via any sound device of your host system. provide the DOS floor, add in a good USB dos driver, like the Panasonic one I use, but simulate the serial port? I believe the Panasonic driver has a focus on block oriented storage (USB flash, USB card reader, USB floppy, USB CD, USB DVD, USB harddisk, USB SSD etc.) but more modular drivers like those of Bret and Georg may have support for serial (bridge) class devices. Another popular class is HID, human interface devices, which includes keyboard, mouse, joystick and similar. the serial port is needful, because the screen reader program uses it, not necessarily a physical port, but the serial port address. If you need a port with an address, make sure that the USB driver or emulator you use has UART level realism. Some might only support BIOS level, not realistic enough. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB to RS-232 Adapters
Hi Luke, I am looking for information about getting a USB to RS-232 adapter to work in the FreeDOS environment. This is the first step in a project to find an alternative in programming legacy Motorola handheld and squad mobile radios. I guess the experts here are Bret Johnson and Georg Potthast. My assumption is that such adapters implement a generic class of device, so support might be possible without knowing the particular chipset, but I also remember from Windows, that specific adapter cable chipsets only have drivers for some Windows versions, contradicting generic support. My understanding is that the software only runs in DOS and connects to the radio via RS-232 serial. The local Motorola enthusiasts state these devices require the front-end program to run in an actual DOS environment and cannot handle emulation. That depends on which emulators those enthusiasts have tried so far. I would assume that generic emulators like VMware or Qemu might not be sufficiently optimized towards DOS, or might just lack the feature to connect to a physical RS232 device, directly or through USB adapters. However, I see no general reason why it should not work, so I would suggest that you try DOS-specific emulators like DOSEMU2 or DOSBOX. The advantage of using emulators is that they can use the USB drivers of the host operating system (Linux, Windows, Mac) while presenting a simulated classic RS232 port to DOS and the apps running there. Depending on your planned expenses, you could also get a new or used DOS-compatible computer with a physical RS232 port, which avoids all USB issues. Most computers which still have a BIOS should work, while computers which only support UEFI and no longer have a legacy BIOS boot options are not suitable for running DOS directly on hardware. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Running software in freeDOS
Hi Kevin, Hello everyone. First time FreeDOS user, and first time in a mailing list Welcome :-) I am struggling to run the program cnczeus ( https://github.com/lumen0/cnczeus ) on an Asus CUW-AM ( https://theretroweb.com/motherboards/s/asus-cuw-am-hp-oem ) ... Not sure whether I understand your (LegacyISO?) FreeDOS config and whether you use the ISO as live CD or install to disk, but: If you get a JEMMEX error, simply try not to load JEMMEX :-) You can load any HIMEM variant instead (including QMGR or FDXMS) as XMS and HMA drivers. It often is okay to have no EMS or UMB. If you do want EMS and UMB, you can read the JEMMEX docs or switch to JEMM386 or 386MAX and read the docs for those to find more compatible settings for them than what your default JEMMEX settings were. Maybe they just were not compatible with the BIOS or hardware of your board, or did not autodetect well. It is perhaps helpful to know that the floppy installer does not fully work, (failing on the fourth disk) nor do FullUSB and LiteUSB when used with plop boot manager. Interesting! So you have to boot from CD/DVD made from ISO? Does the LegacyCD work better than another CD? You can also try the monthly rolling distro test releases, see: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html Those have seen more than 1000 package updates since FreeDOS 1.3 :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Minor performance anomaly / question re DIR command
Hi! I put calls to FREESP, (https://github.com/ChartreuseK/FREESP) in my AUTOEXEC, (FDAUTO.BAT) and that worked well for me. FREESP C FREESP D Trevor Which settings for cache and read-ahead do you use? I think there is potential to fine-tune things :-) Also, how much RAM do you have and how many clusters and files are there on your C: and D: drives? If the drives are not too big, you could try this as part of your autoexec bat at boot: lbacache 32000 flop tickle /chs /lba lbacache cool dir c:\ /s /b > nul dir d:\ /s /b > nul lbacache temp That is supposed to pre-load your FAT and directory metadata into cache, with read-ahead, and flag it as "prefer to keep it cached". Cache size e.g. 32 MB. Alternatively, just load UHDD /S31 for a 31 MB cache instead of LBACACHE. Your UIDE can be up to 4 GB and it already has read-ahead built in (UIDE may not?). You can also use UDVD2 or CDRCACHE to cache CD/DVD, or UIDE which caches both fixed disks and CD/DVD. Looking forward to hear about your experiments, thanks! Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS on a Dell Inspiron 1150: safe-mode only?
Hi! I recently pulled a Dell Inspiron 1150 from my local landfill. This is a Windows XP-era laptop... Intel Celeron 2.6 GHz, and I installed 2 GB of RAM. I was able to install FreeDOS... but... https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html Well, if JEMMEX and JEMM386 do not run out of the box, have you tried reading their documentation? Maybe there are some command line options for JEMMEX or JEMM386 to *manually* configure them in an Inspiron-friendly way. If that does not work, you should *at least* try to get some form of HIMEM working. HIMEMX, QMGR, FDXMS, FDXMS286, any XMS and HMA will be better than none, because that will help you to have more DOS RAM free and you can use most caches and ramdisks when you have XMS :-) Even XMS drivers may need *manual* configuration, because some hardware and/or BIOS variants can fail to offer or properly setup auto-detectable A20 gates or memory maps. I can only get sound from the 'bell', I can't play MP3s. The problem is that most classic games expect SoundBlaster era soundcards. Your laptop has something more modern, so you have to use VSBHDA, SBEMU or similar for games and old media players. Some newer media players for DOS can work directly with AC97 or HDA compatible sound hardware such as the hardware I expect your laptop to have. As usual, you will have to read the docs carefully to select the right ingredients and configuration to get sound to work. Regards, Eric PS: You can use PCISLEEP to find what sound the Dell has. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Minor performance anomaly / question re DIR command
Hi Rugxulo, as you already found out, FAT16 is limited to 64k files per partition and 128 kB (usually 256 sectors) per FAT. Only rather small FAT16 drives use far less than 64k clusters. Most drive sizes differ mainly in how large clusters are. With the usual side-effects. FAT32 usually has way more clusters and way larger FAT, making it very slow to read the whole FAT to figure out how much disk space is used and free. *Cached FAT* You can improve speed by loading a cache, preferably with read-ahead, before you start doing "large" stuff with the FAT. If I remember correctly, I even have an example in the LBACACHE and TICKLE docs where you deliberately DIR /S > NUL to get all FAT and directory info in the cache, so it already is cached when you need it again later. Poor man's "copy disk to RAMDRIVE" ;-) *Cached disk usage info* You are right that Win9x buffers the answer to that in https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FS_Information_Sector but you also have to keep track of whether the values are up to data. Win9x does that by forcing you to explicitly shut down instead of powering off. Each time you fail to do that, it has to read the entire FAT on the next boot to re-compute FSinfo values. You do not want to force DOS users to explicitly shut down before they power off. However, you could implement something similar to the following in DOS: I. When DOS gets asked for used/free disk space: 1. if DOS has the answer in RAM, return that 2. else read FSinfo and FAT headers to see if FSinfo values are up to date. If yes, return values and keep a copy of the answer in RAM :-) 3. else read entire FAT to compute values, return them and, again, keep a copy in RAM. For all cases (1, 2, 3) also update a copy of the values in FSinfo and set a flag there and/or in FAT headers, unless drive is R/O. Only write FSinfo and FAT headers on disk if the write would really change values! II. When the FAT gets updated in a way which has an effect on used/free disk space: Reset the mentioned flag in FSinfo and/or FAT headers, to indicate values are no longer up to date, but do update used/free count in RAM. Only write the flag to disk if it actually did change! Use a copy in RAM to keep track of it. III. You can also trigger FSinfo updates on disk for a few selected other events, such as file system sync / flush calls or apps exiting via int 21.4c / int 20 etc. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Minor performance anomaly / question re DIR command
Hi Tom, Rugxulo et al, To comment on the underlying performance bottleneck: For FAT32 drives, the FAT itself is huge. Which means it takes time to process it, for example to find out how many clusters are free. It actually comes with a filesystem info sector with places where you can store that count, so you do not have to browse the whole FAT each time you want to know. You can also keep the value in RAM, of course. The problem is that if you do not trust the FSinfo data, you have to read the whole FAT (either during boot or) when the first app calls the API which tells how much free space you currently have on some FAT drive. This will take a long time, and in particular if you do not have a large enough cache loaded at that moment, it will not even have the side-effect of caching the FAT for whatever you want to do with the FAT later, for example growing a file etc. Given how unpleasant all of this is for performance, you might understand why Win9x keeps a copy of the whole FAT in RAM :-p Which in turn made Win9x unable to work with FAT32 drives if they have too many clusters in relation to RAM size, I think. Either way, you cannot have 8086 compatibility, FAT32 drives and good performance at the same time. Just pick your pain ;-) As said, if you can delay the big counting of free clusters until you have loaded a cache, preferably one with read-ahead to compensate for DOS only looking at one FAT sector at a time, then you can reduce the pain. IF you have 386+ and much RAM. Doesn't FAT32 already keep the amount of free space stored somewhere? No, And for a good reason. DOS crashes regularily, with no opportunity to write back this number to the disk before shutting down. That is why Windows keeps a flag on whether you have properly closed (unmounted) a drive. If you have, it can still trust the FSinfo data to some degree. DOS could do something similar. If I remember correctly (from dosfsck) the flag is stored in the 0th entry of one of the FAT copies, or the FSinfo sector? No slow calculation at bootup needed. This is not at bootup, but at the first time "free disk space" is requested. Which is typically when you first use DIR after boot, I guess. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Checking some old bug tickets
hi! to reply on-list to an off-list request to comment some old bug tickets on sourceforge, I wrote this mail. my provider today does not want to mail to mail.com :-p i guess the x61 lbacache problem and ctmouse defaults are the only tickets which are still "actionable"? https://sourceforge.net/p/freedos/bugs/63/ lbacache freezes on via c7 in 2011, could be a himem bug, but one of the comments say the bug ticket can be closed? ==> https://sourceforge.net/p/freedos/bugs/57/ in 2010 and ==> https://sourceforge.net/p/freedos/bugs/233/ in 2019 says lbacache crashes with stack nesting on thinkpad / lenovo (t61 and) x61 computers when used with usb drives, in one case in context of an invocation of vinfo by the installer https://sourceforge.net/p/freedos/bugs/397/ feature request asking for nansi to notice and block attempts to load it twice. rather low priority IMHO? https://sourceforge.net/p/freedos/bugs/31/ something with kernel and int 24 critical error handling? ==> https://sourceforge.net/p/freedos/bugs/26/ 2009 ctmouse should change defaults for text mode mouse cursor color masks to preserve intensity/blink bits. https://sourceforge.net/p/freedos/bugs/43/ multiple 2016 complaints regarding the distro, ems, xms, kernel, mouse and various pci sound cards. could close and open fresh tickets for any topic which did not get fixed since then? https://sourceforge.net/p/freedos/bugs/104/ some VERY unspecific 2013 bug report about the mouse stopping to work on virtual box. too few details to do anything IMHO. https://sourceforge.net/p/freedos/bugs/190/ half of our apps fail to work after a 2017 usb install, maybe just a problem with usb disk access for that user? close. https://sourceforge.net/p/freedos/bugs/214/ no mouse cursor in edit if width > 80, is this still the case? for all edit and ctmouse versions? what causes it? https://sourceforge.net/p/freedos/bugs/77/ find freezes, but this seems to be an error in which syntax the user tried to use. would it have worked with MS DOS find? regards, eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Copying Files Between Linux And FreeDOS
Hi! I do not like dosemu2. See the [rant] section of the following post for details. https://www.hardwareasylum.com/articles/retro/mystic-dosemu2/page8.aspx You do not actually HAVE to compile dosemu2 yourself, there are pre- compiled versions for popular Linux distros. And you do not HAVE to use comcom or fdpp, it still supports all other DOS kernels, including of course classic FreeDOS kernels and any command.com shell you like. Dosemu2 just comes bundled with fdpp and comcom. I would only compile dosemu or dosemu2 if I had any self-made patches. And I do not agree that the process to replace kernel and shell would be undocumented. There are many comments in /etc/dosemu/dosemu.conf and making your own config in your home directory is all you need to do to get your own settings and your own DOS drives where you will be able to install any DOS you like :-) Installation can be as easy as copying kernel and shell into your Linux directory which "is" C: My personal preference is booting from a Linux DIRECTORY serving as the C: drive for DOS, plus IMAGES for FAT tools tests, for example: $_hdimage = "freedos2 fatimage.bin fatimage2.bin (and so on)" The first item is a directory, the others are disk images (made with tools which come with dosemu2) to test stuff like dosfsck and format. Other things for which I prefer to use custom settings: - size of EMS, XMS, DPMI, VGA and VESA etc. memory based on my taste - blink rate of cursor, title of window, default zoom for 320x200 - hotkey for grabbing the mouse focus, hogthreshold for CPU load - floppy images, optionally bootable, also for testing disk tools - some mouse and printer settings for testing drivers for those None of those are necessary for most users, defaults are quite ok. I have not tested the network support, so no comment on that yet. Personally, I would recommend to set a custom DOS drive, custom 320x200 zoom factor and a mouse grab hotkey you can remember ;-) You can now configure quite a bit of sound stuff, including MIDI engines, so that would probably be interesting to play with, too. For games, the usual default SB16 with Adlib etc. is good enough. Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Copying Files Between Linux And FreeDOS
Hi Frank, I kind of second that :-) DOSEMU has traditionally been "special". Different from e.g. QEMU in that DOSEMU was a relatively thin emulation layer. Not emulating what needed not be emulated. Note that current versions do emulate everything, even including the CPU, given how hardware has become less suitable for DOS over time. However, the emulation is a lot more tuned towards DOS than, for example in VMWare. You even get some virtual drivers for EMS, XMS and the mentioned "drives which are mapped to Linux directories". Those sometimes work based on shim drivers shipping with DOSEMU2, sometimes they even do not need you to load any drivers at all, which is why you can boot DOS from a Linux directory in DOSEMU2: The read-only mapping works with magic and you load a shim driver later to enable write access. This is one of the differences from classic DOSEMU: You did not need any drivers even for writing in classic DOSEMU, but you do in DOSEMU2. Such things change from time to time with little warning, so if your DOS config gets weird, you have to check what the config of the FreeDOS spin-off bundled with DOSEMU2 looks like at that moment and update your own config accordingly. Or just stick to the bundled one and enjoy the surprising features ;-) The DOSEMU2 FreeDOS uses their own command.com and a heavily updated and modified kernel integrated more closely with DOSEMU2, but you can use your own classic FreeDOS install if you prefer, even from a directory-based simulation of a drive. This differs from DOSBOX, where even DOS itself is a simulation unless you boot a diskimage in DOSBOX. I would NOT give either a raw actual block device. Sure, you could technically say the device can be used instead of a disk image, but you would have to tell Linux about the risk of competing access, which is a problem avoided by using dedicated disk IMAGES. The feature of letting a directory appear as a drive is very convenient in that sense, because competing access is no problem, plus you immediately see changes from Linux in DOS and vice versa. Such mapped drives are not FAT, but that rarely matters. Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Copying Files Between Linux And FreeDOS
Have you considered using EtherDFS or NetDrive? https://etherdfs.sourceforge.net/ https://www.brutman.com/mTCP/mTCP_NetDrive.html If you have networking support, they are both great options. Even without the effort to create a network between QEMU and the host Linux, have you considered using DOSEMU2? ;-) https://github.com/dosemu2/ For pre-compiled binary downloads for Ubuntu, Fedora and OpenSuSE Linux, see the README here: https://github.com/dosemu2/dosemu2 DOSEMU2 makes it trivially easy to exchange files between Linux and FreeDOS: It can use Linux directories as DOS drive letters. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Regina Rexx 3.9.6 released
Hi! Rugxulo writes on BTTR: https://www.bttr-software.de/forum/forum_entry.php?id=22023 Regina Rexx 3.9.6 was released on 5 May 2024. Download: regina396dos4gw.zip (1.0 MB) Sources: regina396.zip (3.0 MB) > Changes in this release (from 3.9.5) > > * Bugs Fixed: > - Crash with UPPER and LOWER BIFs > - #560 MAX(1m2m05,0,4) returns 5 (not what the doc says) > - #561 Crash with 10 trace off > - #564 Two STREAM QUERY EXISTS generate wrong result Rexx >= 3.7 > - #575 Parsing fails > - #581 Silly syntax typo causes Regina to CRASH > - #583 Trace "Failure" ineffective. > - #586 syssearchpath() under Windows not using updated > - #588 Configure probes for gethostbyname_r and getpwuid_r fail incorrectly with strict compilers > - #589 Translate BIF only translates aplha characters > - #593 bad format, numeric digits not honoured > - #594 FORMAT(123.4573, ,3,0,0) > * Feature Requests: > - #44 Regina pauses at execution end - installation check box pls > * Potentially improve performance by reducing initial variable pool hash size from 2003 to 227. Certainly improves rexxcps - suggested by Jake Hamby > * Add REGINA_HASHTABLELENGTH to enable initial variable pool size to be changed at runtime. This value MUST be a prime number! Use with caution. > * Add sysgetline() and sysgetlinehistory() to Regutil; implementation of GNU Readline (actually added in v3.9.5) > * Add handling support for SIGUSR1 and SIGUSR2 to turn on/off TRACE I > * Add ReginaGetAddonDir() API call to obtain location where Regina looks for external function packages > * Initial support for Windows ARM64 platform > * Check for Windows 11 and arm/arm64 architecture in UNAME BIF > * Add OPTION STRICT_ANSI_FORMAT_BIF to apply strict ANSI rules to the FORMAT BIF ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How to compile FreeDos. There is some tool with all already done?. Help
Hi Gabriel, if I have to guess, then buildall does the following: It compiles several different types of FreeDOS kernel, for example with and without FAT32 support. Each kernel is just a single binary which you can rename to kernel.sys, then use SYS or similar tools to install it to a FAT drive of your choice. Our SYS and kernel support FAT12, FAT16 and FAT32. As you have already noticed, buildall will not build a complete distro. All apps are packaged separately :-) However, there is of course some scripted build process used to create the distro in ISO and other formats: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html If you just want to learn about operating systems, then re-building the entire distro clearly is NOT what you want to do. Instead, you want to look at the kernel and command.com sources and maybe those of a few interesting low level apps and drivers and compile THOSE, possibly with your own custom changes. That would be more interesting from the operating system exploration point of view, compared to pumping around 100s of megabytes of data to create an ISO. Enjoy FreeDOS! Regards, Eric Yes. I was taking a look and I discovered I needed some old tools... As said, you should NOT need any hard to get tools. We tried to make many components buildable with modern free open source compilers and assemblers. You may still need Turbo C in some cases. Let us know if and for which relevant packages you need more old tools. Reading some documentation on kernel repository ( Github), I saw a file called "buildall.bat" , so , I thought that pick all source code ,compile it and create a .iso , something like that . See above and visit https://gitlab.com/FreeDOS/OS/builder ;-) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installing for 8086 CPU on SD Card.
Hi Jerome, Trevor, Mateusz etc. :-) Thanks for explaining how to turn 386 installs into 8086 ones! I hope the CPU detection is now working, so the installer will create an 8086 install when used on 8086 systems? Does the installer have an option to manually select an 8086 compatible install result, for people who plan to later copy the installed system to some 8086 based PC? AT or 286 systems are an interesting case: They support XMS and some kernel optimizations, but no 386 specific apps, drivers or kernels. Which style of install will people get on 286 based computers? I notice you recommended to backup config and autoexec, then reduce the config, but not create a lightweight version of autoexec? Or is there a trick and I just overlooked how the lighter autoexec is created? Regarding the shell, I do recommend the KSSF version of FreeCOM. While the normal version will need XMS to swap itself out of DOS memory and have a lot of RAM free for DOS apps, it will use a lot of RAM on systems where no XMS is available. In particular: 8086 PC :-p The KSSF version of FreeCOM uses a different trick to just re-load most of FreeCOM from disk when apps return to the prompt, to have more RAM free for apps without needing XMS to get there. Mateusz also has the lightweight SvarCOM shell as an alternative. Several other shells exist for DOS, in various sizes. ROMOS uses a minimal one. For example http://www.rayer.g6.cz/romos/romose.htm comes with a 10 kB small RJDOS command.com shell, which helps making a minimal FreeDOS installation which fits into your BIOS, together with the MM MicroManager file manager (midnight commander or norton commander style, you know the concept) :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How to compile FreeDos. There is some tool with all already done?. Help
Hi Gabriel, Hi , I'm studing Operative Systems . I was trying to compile FreeDos but looks like a hard job, I think I can do it but maybe exists some tool with all already done on it, and just doing some command all is compiled. The answer to this question depends a lot on what exactly you mean by "FreeDOS". In Linux tradition, you might mean only our kernel? For that, you can now even cross-compile using a Linux (or maybe Windows?) computer to compile our kernel binary without having to install DOS first. I guess Jeremy, ECM and others can point us to which readme to read and which toolchain packages to install to use that road. You can also install DOS first - if you like, in dosemu2, dosbox or a virtual machine - and then use that as your build environment to compile new kernel binaries. If you also want to compile FreeCOM (command.com) or all the different apps and drivers included in our distro, then the answer is indeed complex: They use a number of different compilers, assemblers and tools to build the binaries. Some of them may not be easily available today, but we tried to use free or even open source compilers whenever possible. Some Borland compilers are available as free legacy or museum apps now and some free assemblers now include MASM or TASM compatibility modes. We have also used tools written by DOS experts to translate assembly language files to free dialects like JWASM, WASM or NASM. In short, if you find a FreeDOS package which still can only be compiled with tools which are hard to find, please let us know about the oversight :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Printing to USB Printers
Hoi Nico, bedankt voor je uitleg! To clarify A) It is an epson printer. With a centronics parallel interface B) I have a usb to centronics cable wich works ( under windows 10) C) The cable interface uses a ch341a chip. My guess is that this should not matter: There should be a generic category of USB printer ports supported by the cable. But we have actual USB experts here who may either confirm that intuition or say that I am totally wrong :-) https://www.usb.org/sites/default/files/usbprint11a021811.pdf D) i dont have an ethernet (wired) connection yet with the laptop. Which chipset does the laptop use for wired networking? You can use PCISLEEP to check which devices you have. E) DosUsb gives Errors when talking tot the printer. Sounds like a question for the USB expert(s) here! My thoughts were to build a driver to talk to the ch341a in c or assembly. To be continued You do not want to do that from scratch. For USB, there is a big mountain of stacked layers of logical structure and in operating systems with versatile USB support, you would only have a driver for the chip in context of all the already existing drivers for USB in general, which in turn support USB controllers on your mainboard in somewhat generic ways, to need less instance specific complexity. So what you would do in DOS is: Wonder whether the generic USB driver can treat the chip as instance of a generic USB printer port category and if not, whether you can get it supported by making it a special case of it with as small as possible differences, to not have to modify too much in the USB drivers. A driver "only for the chip" would not help you, as the chip always exists in some large, complex USB ecosystem. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Printing to USB Printers
Hi! If your printer has USB, you could try a generic USB "printer port" driver as long as the printer still understands commands DOS apps can produce. Some just accept plain text, PDF or PostScript, which DOS apps can produce to some degree. If your printer only has Centronics, but your PC only has USB, you can get an adapter cable. You cannot get an adapter cable for the other direction as far as I know. But, as others have said, you can get a "print server" adapter which basically is a small box with a network port as input and a printer port or USB port as output. Then you can use standard DOS network printing tools and standard DOS network drivers to print to your USB or centronics printer, which may actually be EASIER than using USB drivers for DOS. Note that DOS networking is only available for wired LAN, not for WIFI! However, you can also get a bridge box which lets you connect your PC using a LAN cable to the box and then the box connects you further to a WIFI. Regards, Eric So I understand that I am using a usb->Centronics parallel adapter. Which works fin in Windows 10. Those are for Centronics printers and USB PC. You can use them with DOS USB drivers, but this is as complicated as using USB printers with DOS USB drivers. Better avoid it. However where can I find a more technical reference of talking to the CH341A IC. There is a datasheet but that is limited more or les to the electronics. The drivers are apparently only for the windows systems. You do not want to build your own hardware for this ;-) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] DOS packet drivers and NDIS wrappers
Hi! Here is an interesting thread about DOS networking: https://www.bttr-software.de/forum/board_entry.php?id=21820&page=0&order=time&category=0 For RealTek GbE (gigabit ethernet, LAN) there were no packet drivers on http://www.georgpotthast.de/sioux/packet.htm but a NDIS2 driver, https://drivers.eu/Network/RealTek/RTL8111/DOS exists and there was a discussion about possibly updating existing open drivers. https://www.realtek.com/Download/Index?cate_id=194&menu_id=297 seems to have a problem with JEMMEX. Shims like http://www.shikadi.net/network/ could convert different APIs into each otther. In the end, David wrote: "Hello, ethernet is working :) This could be usefull for someone who use NDIS package to packet driver Realtek conversion" so you can use the description on how David made it work if you also have an Ethernet controller for which only NDIS exists :-) See also: https://www.shikadi.net/network/ shim convertor dis_pkt11(9).zip https://www.realtek.com/Download/ realtek NDIS for rtl8168 chip RayeR confirms that the method is what RayeR uses as well :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Lousy NTFS...
Hi! To avoid boot virus problems in DOS, you could: - use FDSHIELD to write-protect boot sectors in DOS - configure your BIOS to write-protect boot sectors - configure your BIOS to not boot from floppy etc. Of course there are viruses which infect both files and boot sectors. You can also configure FDSHIELD to write-protect executable files, which is not nice if you want to compile new executables :-p And of course if you do boot from an infected floppy, it will infect your other disks BEFORE you can load FDSHIELD so only the BIOS can help you against that. If you already have a virus, you either have to throw away the infected files and SYS infected disks with a non-infected boot sector or you have to use classic methods like actual antivirus software ;-) Note that a virus tends to stay in RAM after boot or after you start an infected executable, so it would immediately re-infect you after a SYS or similar. It is a good idea to have a known-healthy write-protected boot disk somewhere to be prepared for such cases. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS live stream event with VCF
Hi ECM, thanks for the explanations! If I understand https://github.com/FDOS/kernel/issues/50 correctly, Windows 386enh support is not part of the automated builds yet because there originally were limitations regarding which compilers are supported, which have since been resolved? The second half of the thread sounds like it still is non-trivial to get Windows to work smoothly, but at least it does work to some degree, so I would suggest to already enable all Windows support by default :-) Regarding GPT support: The history.txt says a bit does exist. I have not checked whether source code does... The WIN31SUPPORT define is still not enabled/defined by default I believe. Some discussion in [7]. At some point I manually built a kernel including it. I also contributed a workaround to allow the gcc build to succeed with WIN31SUPPORT defined on 2024-02-04 [8]. However, I did not test this nor compare it to Enhanced DR-DOS's support of the same APIs, it just builds now with gcc ia16 as opposed to failing at build time. So EDR-DOS also has improved Windows support now? How stable is the Windows support there compared to FreeDOS? Interesting [8] diff! The GNU C implementation seems to handle 3 segments plus the way to tell where instance data ends differently from the implementations for the other compilers? And there is something about the lol pointer in win.h, not affecting other patched places? Maybe that just meant that GNU C wanted things to be done properly while other compilers accepted somewhat less elegant ways? Or to put it in a different way: Could it be useful to use your patch for all other compilers, without #if defined __GNUC__ condition? Regards, Eric [1]: https://pushbx.org/ecm/download/fdkernel.zip [2]: https://pushbx.org/ecm/download/fdshare.zip [3]: https://pushbx.org/ecm/download/freecom.zip ... [7]: https://github.com/FDOS/kernel/issues/50 [8]: https://github.com/FDOS/kernel/commit/ab3cac6d0c3a6014fcf0f450c77f1e3d7177cf99 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS live stream event with VCF
Hi Jerome, I basically wonder about something like a third choice, next to "auto-fdisk & auto-format" and "exit to DOS", which lets the user run FDISK interactively and then returns to the installer. It only auto partitions in normal mode when no partitions exist. If partitions exist and are not usable by DOS, you are sent to FDISK to modify them. If partitions exists and is usable by DOS, partitioning is skipped. Or, use advanced mode to not auto-partition a drive without partitions. The installer will not proceed beyond the partitioning phase of installation until there is a partition that will be usable by FreeDOS. The usable partition is only formatted if it is not readable and requires formatting. It does not reformat a drive that is readable by DOS. Whether in advanced mode or normal mode, neither partition or formatting occurs without a prompt to the user. So basically the trick is that steps which have already been done by the user or by an earlier install are indeed skipped and the trick to continue after "exit to DOS" is to manually do whatever you want to do manually, then boot the install medium again, or start the install tool again, without the need to pass special arguments regarding where to continue? Good to know! Now I wonder how it could be advertised better, because "exit to DOS" sounds a bit like aborting or giving up the install process. One thing the installer could do when that option is selected would be to show a final message to the user after leaving full screen mode, with instructions on how to proceed. Another thing would be to give "exit to DOS" another name which somehow implies the possibilities to continue :-) The installer never wipes. It only partitions and formats drives when required. Thanks :-) However, if a previous version of DOS is installed on the drive, it will prompt to backup those files along with any of the conflicting system files and directories. Nice :-) To install non-destructively (for example, if you already did FDISK + FORMAT + SYS, and don't want the installer to run SYS again) you can run this: SETUP ADV If I understand you correctly, it will automatically not run FDISK or FORMAT anyway, when I already have, so the difference would only be in asking me whether to write boot sectors when the ADV option got passed? If the installer already has that ability, it could be advertised more :-) You mean like the ability to switch to and from advanced mode without exiting the installer? No, just the ability to continue where one has left by that "exit to DOS" choice in any of the dialogues which ask the user whether to do large impact things. Which already is there, which is good to know :-) Regards, Eric PS: Thanks for the new monthly test distro update! :-) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS live stream event with VCF
Hi Jim, *Installer* the installer tries to do everything for you; the user should just be able to respond to prompts. I basically wonder about something like a third choice, next to "auto-fdisk & auto-format" and "exit to DOS", which lets the user run FDISK interactively and then returns to the installer. For example Ubuntu used to have the choices, paraphrasing: "wipe whole disk and install Ubuntu", "arrange everything for a dual boot and preserve Windows" and "open interactive partitioner". Of course FreeDOS does NOT need to automatically do dual boot, as it would sometimes have to access non-FAT content for that. A third option beyond "wipe" and "abort" would already be nice. If you want to do things manually, you can always exit the installer and run FDISK. Yet how do I re-enter it to continue where I have exited it then? To install non-destructively (for example, if you already did FDISK + FORMAT + SYS, and don't want the installer to run SYS again) you can run this: SETUP ADV ...and that will give you the option to control the installation... So it does not automatically detect which steps are not necessary, if I understand that correctly? If the user picks "exit to DOS" in the current installer to manually run FDISK and FORMAT as needed, and/or there already is a partition and/or FAT filesystem on the disk, it would be convenient to know that when you boot the install medium again, the installer would detect which steps have already been handled (by the user, a previous OS install or a previous run of the installer aborted half-way) and automatically skip those, or offer to skip them to preserve existing data. If the installer already has that ability, it could be advertised more :-) I only paused a few moments while watching the VCF stream. *VM image* image for qemu. We should offer a pre-installed disk image. Which format? IMG? QCOW? QCOW2? VMDK? DMG? VDI? VHDX? If you ask me: IMG, because multiple VM brands support it. I can do the "Plain DOS, plus sources" install on a 120MB image (zipped) and put that on Ibiblio too. That could be a nice addition :-) *Downloads* Note that there is no obvious link from https://freedos.org/download/ to the used subdirectory https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/ Do you mean the links to download the LiveCD, BonusCD, FullUSB, LiteUSB, LegacyCD, and Floppy Edition? Click the links on that page to download them. What I would have liked would be two things: 1. Links to the specific "official" and "test" directories, instead of the global "files" directory and 2. Something which tells you how large your download will be, so people do not just blindly press all download buttons but make an informed choice on how much they want to download. Optionally, also mention the build date next to the version? For example, https://ubuntu.com/download/desktop has a button saying "Download 24.04 LTS" with the text "6GB" right next to it. So if I do not have a double-sided empty DVD or a large enough USB stick to create the install medium, I am able to immediately move on and search for smaller alternatives. Alas, Ubuntu fails to specify file sizes in their list of downloads on https://ubuntu.com/download/alternative-downloads as well. Only after selecting a mirror and a version, you will see them: https://mirror.math.princeton.edu/pub/ubuntu-iso/24.04/ which are: 2.6 GB live server, 5.7 GB desktop and 81 MB netboot file. So you can decide whether server is okay or whether you really have to fetch a large enough empty DVD or USB before installing. Note that, alas, nothing at all is offered any more for 32-bit PC. In short, Ubuntu IMMEDIATELY tells you HOW BIG their 1 primary download will be. It would be even better if FreeDOS were tp mention the download sizes for ALL SEVEN direct download links on https://freedos.org/download/ as well as providing an easy deep link to the 1.3/official/ and rolling test/ directories. *Kernel* Regarding the "outdated kernel" issue, it surprises me that http://kernel.fdos.org/ only has (2021-05-13?) kernel 2043 ZIPs at the moment, while https://github.com/FDOS/kernel/tree/master says there SHOULD also be downloads for newer compiles there. At least a 2023-12-02 build 2044 ZIP. Even better a 2045 one, as the history file suggests that we have already reached 2045: https://github.com/FDOS/kernel/blob/master/docs/history.txt Note that the current main.c says copyright 1995-2023, while version.h somehow still says REVISION_SEQ 43 for some reason? Either way, given that we HAVE a 386 enhanced mode compatible kernel which NEEDS testing, it would be really useful if one of the kernel people were to PACKAGE it, so Jerome can INCLUDE it in our monthly rolling release distro, so it GETS tested :-) Regards, Eric PS: Good to know that SLOWDOWN (and FDAPM) and TP7P5FIX are in there. Had overlooked that, as it has no "200" in it ;-) PPS: I do not suggest
Re: [Freedos-user] FreeDOS live stream event with VCF
Hi Jim and VCF, thank you for sharing the stream on https://www.youtube.com/watch?v=_peIYEAM9pk Of course, I have some thoughts about it: Earlier in the video, when you present some spreadsheets and word processors, there is a point where you show the Windows 3 about screen and it mentions 386enh mode? When going through the install process, I do not see how you can do interactive partitioning of the disk, or to install non-destructively. I guess you have to exit to DOS for that and somehow trigger the remaining steps of the install manually, bypassing the destructive steps? Unfortunately, the rolling monthly release apparently uses very OLD FreeDOS core components: A 2021 kernel with a copyright message saying 1995-2012 and a 2021 shell version 0.85a :-( Later on, you give a verbose description of how FreeDOS alas "does not" run Win3 in 386enh mode, but proceed to say that an experimental kernel which DOES support 386enh EXISTS, but still needs more testing. What would be a better way to GET that testing than to include exactly that new kernel in the rolling release? Also, it seems a bit tedious to download roughly 1 GIGABYTE of installers (livecd and bonuscd) and walk through the entire install process only to create a 50 or 120 MEGABYTE image for qemu. We should offer a pre-installed disk image. Note that there is no obvious link from https://freedos.org/download/ to the used subdirectory https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/ and even less so the subdirectory presented in the video, https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/ so visitors will have a hard time to see which files are from when and, importantly, which sizes they have: "official 1.3" LiteUSB 16MB, FloppyEdition 21MB, LegacyCD 227MB, FullUSB 356MB, LiveCD 375MB, BonusCD 621MB, all 2022-02-20 "test" in the current version LiteUSB 17MB, FloppyEdition 25MB, LegacyCD 272MB, FullUSB 400MB, LiveCD 422MB, BonusCD 629MB, all 2024-06-01 Remember that Jeremy first posted in 2021-07-26 about his proof of concept demo of a Windows 386enh install on FreeDOS kernel. Kernel version 2044 exists since 2023-12-02. Since then, we basically have been waiting for people to TEST the improved kernel, while Jeremy, Tom and ECM and others have worked on yet more news. For up to date kernel versions, go to: https://github.com/FDOS/kernel (alas, the link to precompiled kernel.fdos.org needs updating) Improvements include SYS 3.6f and kernel supporting 128 kB cluster size (boot: FAT16 only), some GPT partition support, improved partition handling at boot, multiple fixes, such as cherry-picked ones from dosemu2 fdpp, improved A20/HMA code, some COUNTRY and FCB fixes, more SHARE flexibility, improved DMA boundary (non-)handling when the BIOS already handles it, generally improved compatibility, incl. Windows 3 386enh mode compatibility, improved config sys handling and boot logging including COM output option, NEC V20/V30 "186" CPU detection, better handling of uninitialized partitions, simplified intr flag handling and STI before INTnn, improved UPX build style, a DPB / memory fix https://github.com/FDOS/kernel/issues/148 and a truename fix from https://github.com/dosemu2/fdpp/issues/212 and more: https://github.com/FDOS/kernel/blob/master/docs/history.txt Interesting that MS Word for DOS looks a bit like EDIT, but with char style highlighting and a graphical preview :-D Does the distro include error 200 patchers and slowdown tools? UEFI related question, how are projects to provide a BIOS as loadable EFI module doing these days? Any hot ones to name? Of course I still recommend dosemu2 as alternative for VM image mounting ;-) Good that we have vmware vmsmount, too. Thanks for the verbose video! Regards, Eric PS: There is only a TEXT file about metados left here? https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/ PPS: https://www.lemonde.fr/resultats-elections/ seems very brown :-( ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS live stream event with VCF
Hi and a belated happy 30th birthday FreeDOS! If using freedos exclusively, what tools would allow you to attend this event? As Jim mentioned accessibility (although in another context) it would indeed be a good question whether for example the audio could be provided as a non-https download for listening directly on FreeDOS computers. I remember selected apps for playing media now support modern sound hardware in DOS. Even the now available SoundBlaster emulators, combined with an older audio player app, could be used. For an audio-only download, an OGG should be a nice open alternative to MP3. Cheers, Eric It could be downloaded with a browser using an Invidious link (either the audio, the video, or both) and later reproduced using a media player. Has mplayer been ported to DOS, perhaps? While I like the idea, invidious may still need non-DOS browsers? ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS Actively Used Scenarios
Hi Jim! My favorite example of someone running FreeDOS was years ago, probably around 2005. They built pinball machines, and FreeDOS ran the scoring system, lit the lights, and played sound effects from a sound bank... Maybe they used some type of lab control or GPIO type ISA or PCI card? My favorite example before that was a nebulous one. Someone from NASA emailed me in the late 1990s to say they were using FreeDOS on some of their computers. They never provided details, so I don't know what it was doing - but how cool that NASA was using FreeDOS!? I remember somebody asking whether FreeDOS had contributions from people from evil countries, because they wanted to use it to run some type of in-flight entertainment system with some media player app for DOS :-) More recently, during a small demoscene event, I noticed that one of the presented demos was a 256 byte demo running on FreeDOS. The boot message was only visible for a moment, so I do not know what type of virtual hardware that FreeDOS instance was running on. Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unexpected results from DIR command
Hi! Not sure whether I can reproduce the problem... If I have a directory with files 1.2, 3, 4.5 and 6, DIR and DIR *.* shows all files and DIR * only shows the files without extension: 3 and 6. DIR *. does the same. So everything seems to work as expected? Tested on FAT12, FAT16, FAT32 and DOSEMU2-redirects, with FreeCOM version 0.84-pre2 XMS_Swap Aug 26 2006. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] If you use smartdrv, load it before mkeyb
Hi! Japheth found an interesting problem and explains on BTTR: https://www.bttr-software.de/forum/forum_entry.php?id=21818 It turned out that Mkeyb and MS SmartDrv don't like each other. The root of the problem is that MKEYB's Int 15h handler expects the carry flag to be set, else it does nothing. If SmartDrv is loaded AFTER Mkeyb, it also installs an Int 15h handler, to catch Ctrl-Alt-Del. It doesn't care about the the carry flag, and the crucial code is: > cmp ax, 4F53h jnz prev_handler That also explains why it's just key 56h that isn't translated, the usual keys have scan codes < 53h. > The simplest fix is to load MKeyb AFTER MS SmartDrv. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Web forum
Hi! Would there be any interest in a web forum for FreeDos? You mean something like https://www.bttr-software.de/forum/board.php ? ;-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS diagnostic tools?
Hi Karen, the utilities recommended by Rober To sound useful: HDAT2 harddisk repair and diagnostics ATA, ATAPI, SATA, USB, SCSI ASTRA Advanced Sysinfo Tool and Reporting Assistant HWiNFO system information, monitoring and diagnostics Do you recall the items in norton utilities? There is a wikipedia article about them: https://en.wikipedia.org/wiki/Norton_Utilities The first version in 1982 included: unerase - Freedos comes with a simple undelete tool filefix - "repairs damaged files" (?) disklook - apparently a floppy disk cluster map display? secmod - floppy disk sector changer (disk editor, I guess?) filehide - Freedos attrib should be sufficient for that bathide - related to filehide timemark - "displays date, time, elapsed time" scratr - sets colors, you can use ANSI and PROMPT for that reverse - sets colors to black on white clear - you can use cls for that filesort - sorts directories on disk diskopt - tunes floppy access speed beep - just beeps the speaker print - prints files Which free and open tools for directory sorting and disk editors do we have in the distro at this time? I guess diskopt works by creating an interlaced floppy sector format, which tools do we have for this style? According to wikipedia, Norton Utilities 2.0 added filefind and renames print to lprint because MS DOS 2.0 already came with a tool called print itself. In version 3.0, you get additional tools for file size and directory listings, system information, text search, wiping of disks and files etc. Which tools do we recommend for directory listings, file size info and wiping? For size info, I would use the GNU "du" tool, which is available as DJGPP compiled DOS binary. What could we recommend for finding files and text? I guess the GNU tools "find" and "grep" would be useful choices here? Similar for "wipe". Version 3.1 adds unerase and unremove directory tools. New in version 4: Defrag tool (speed disk) and format recover. The defrag tool is the same which MS DOS 6 bundled later on. New in version 4.5: "batch enhander" and a disk editor, the ncache disk cache (faster than smartdrive / smartdrv) and diag. Version 5 improves the disk editor further and bundles 4DOS in a variant called NDOS. By now, 4DOS is sort of free/open. Version 6 adds Win3.1 icons and "diskreet" and improves the system info. The unerase tool now supports the same optional delete tracking driver as MS / central point undelete does. Version 7 adds support for compressed disks (doublespace, stacker and superstor formats) and norton disk doctor. Would be good to know which features the disk doctor had exactly. The final DOS version 8 just adds some Win3.1 related tools. Later versions gradually add Win9x, FAT32, WinNT etc. support and features specific to Windows, like a registry editor. Even a line of products for Apple Macintosh existed. Competitors to Norton Utilities: Central Point PC Tools, various smaller ones. The author of spinrite claims norton disk doctor is a rip of it: https://www.grc.com/sn/sn-666.htm Spinrite scans disks for recoverable files and even tries some tricks to reconstruct data from almost unreadable sectors, but only supports 128 GB style CHS, not LBA. https://en.wikipedia.org/wiki/SpinRite claims FreeDOS bundled with SpinRite to trigger some 16-4-8-bit CHS overflow > 128 GB? Well-known free/open alternatives are photorec and testdisk. The batch enhancer is similar to our v8 power tools, I guess. It can beep and show messages in color and with text boxes etc. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS diagnostic tools?
Hi Karen, please specify the type of diagnostics you would be interested in. For example PCISLEEP can give you a list of PCI devices in your PC, but you seem to be interested in disk or filesystem analysis etc.? Maybe tools which display the SMART health status of your disks? I remember having used tools for that and to configure disk sleep. SMARTUDM (1997-2003-?) from sysinfolab was one I tried. No idea whether there are variants supporting post-IDE/ATA/SATA drives. SMARTDFT / DFT 3.00 also displayed or logged SMART disk status. Regards, Eric PS: Interesting to notice that Veit's tools still exist on https://kannegieser.net/veit/programm/index_e.htm My hope is that there is also dos based software supporting the care and diagnostics of that infrastructure? For example, while I have Norton Utilities for DOS, it cannot see my larger drives and so forth. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] documentation update
Hi! Turns out I only had some 2020 Bochs and no boot "disk" for it, so I could not easily test any hotkeys :-o But: What if the DOS distro installer can be improved, so it no longer matters which emulator or virtualizer people use? ;-) As I’ve mentioned many times before, it already does that. And has done that since FreeDOS 1.2. I was not referring to "autodetect in which virtual environment you are and do special things for that" but to "be flexible enough with real or virtual PC hardware to just work out of the box with all popular virtual computers", in combination with "to make it easy to install DOS on virtual computers, we could have a disk image with pre-installed DOS, suitable for all types of virtual PC, one size fits all". Of course virtual computers today tend to be tuned towards Linux or Windows running inside them, but my hope was that a few hints for options might be enough, something like "configure your virtual PC to offer AC97 or HDA sound, SATA without AHCI and BIOS instead of UEFI boot mode, then this FreeDOS disk image should be sufficiently happy", leaving "only" the issue that emulators often isolate DOS too well. Because you need specific drivers to get files out of or into the virtual computer, which is a problem very elegantly avoided by dosemu2 or dosbox or similar DOS specific environments. There are drivers for DOS as client OS for some virtual PC, but no universal ones. And there are drivers for a few of the network cards a typical virtual PC can simulate, but maybe not for those simulated by default and maybe not at least one for each popular virtual PC brand? In addition, it is not very convenient to have to use a FTP or NFS or SAMBA client or web browser for DOS to transfer files, which in addition means that you would have to run the corresponding servers on the host operating system, on your real PC. However when it comes to virtual environments, it only has separate config files for DOSBox at this time. In a perfect world, no special config would be needed, because a generic config would be compatible enough. But I agree that exactly because dosbox and similar are MEANT to be used with DOS, it can be good to have a special config to activate the special DOS interaction helpers dosbox and others support :-) ... V8Power Tools program VINFO to detect if and what virtual environment it is installing the OS. At present, that is Virtual Box, VMware, QEMU, DOSBox and some others Good to know :-) As you may recall, the installer now uses this information to also determine how to behave when a disk is not partitioned. On real hardware when a drive has no partitions, the installer will prompt to overwrite the MBR. Inside known virtual environments, it just overwrites it and does not bother the user. I remember that I would prefer if the detection checks whether there is absolutely nothing that could get lost, not whether the target is virtual. If the disk is REALLY totally empty, then there is less need to ask. If it is NOT, then even in a virtual PC I would prefer to be asked. It also is conceivable that the detection just THINKS a disk is empty, due to a read error. So I would prefer the most cautious approach, even if it means that the user has to press a few more buttons during install :-) Big and little USB images, live and legacy CD, plus the floppy edition. The floppy edition is a special case. The live CD could get replaced by a live disk image :-) One which could be either copied on USB or used directly as virtual disk of a virtual PC, with everything pre-installed? Does that live CD sometimes use "install to ramdisk on the fly" strategies for some apps? Or does it really have every app fully pre-installed? Would a live DVD make sense? Of course old PC cannot boot from USB, but then those could also be too old to have decent live performance from CD, so people could rather boot the legacy CD and install from there to their legacy PC harddisk instead? As every installer, the legacy CD also offers a bit of live DOS as well. So to keep the number of downloadable install media at 5, the live CD could get replaced by a live disk image suitable for both USB and virtual PC? This would be convenient for users of virtual computers, because they do not need to worry about installing to actual disks when their disks are imaginary anyway :-) Sounds similar to what the LiveCD provides. Exactly :-) Without the worry of having too small or too large of a disk image Yes and no. DOS cannot use ISO filesystems for interactive persistent read/write access, while it could use FAT on a disk image for exactly that. In addition, users could still take any of the better partitioning tools, as long as it has disk image support, to resize the disk image :-) If there are worries about bootability after resizing, a pre-installed disk image download could contain TWO FAT partitions, one of them as safely to resize D: drive :-) With enough ram, it reloca
Re: [Freedos-user] documentation update
Hi! Initially I tried Bochs, but found Bochs either cannot go full screen using SDL2, or I just haven't found the magical incantation... A quick google says "try alt-enter" (to go full screen). In 2011, this had the side-effect of risking to switch to a resolution DOS dislikes, I have not googled further to check whether Bochs in 2024 has issues? More research showed DOSEMU out of date and not available on Void Linux I agree regarding the first part, but have never heard of Void Linux. distribution here, and/or requiring other self compiled libraries, as well as DOSEMU2 requiring additional self compiled libraries, with only DOSBOX (intended for games) available on Void Linux. For Ubuntu, you can simply add the PPA to your software manager, https://github.com/dosemu2/dosemu2 explains the details. They also have pre-compiled packages for Fedora and OpenSUSE. No manual compilation is needed for either of the 3 distros. After more research, found Jim Hall's book tends to sway towards suggesting Qemu, a virtualizer rather than an Emulator. I have and currently use Virtualbox here, but wanted to remain to the de facto used emulator for DOS environments. Regardless, Qemu readily resizes to full screen, so that I can finally see and read the font/characters. I doubt that there is a "de facto used emulator for DOS". Personally, I prefer dosemu2. Windows users often prefer dosbox. Various users also like to use software which emulates or virtualizes a complete PC on which you then install DOS, but I have no idea why that would be better than dosbox or dosemu2 which spezicalize on supporting DOS and offer nice magic like "any Linux DIRECTORY can become your C: DISK". 1) Jim Hall's FreeDOS qemu incantation likely needs some minimal updating, for those that desire to get-up and running quickly... $ qemu-system-x86_64 -name FreeDOS -machine pc-i440fx-4.2,accel=kvm,usb=off,dump-guest-core=off etc. That is a very long command line indeed! An incantation :-o 2) Book or documentation should probably lead or advise users, the best (as of date) emulator or virtualizer per their intended use. What if the DOS distro installer can be improved, so it no longer matters which emulator or virtualizer people use? ;-) As they say, the more we keep something simple, the easier and more readily we get things done. We could provide a disk image with pre-installed DOS. This would be convenient for users of virtual computers, because they do not need to worry about installing to actual disks when their disks are imaginary anyway :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] odd news
hi! as jim prefers all dos related things to be discussed on-list: why would a https server which is "not in real working condition" and a dos port of gnupg where important features cannot be used because dos has no /dev/random (see bttr thread) be newsworthy? the changes to nasm do not seem to affect the dos version either? i hope it is not necessary to start 3 separate list threads now ;-) https://sourceforge.net/p/freedos/news/ regards, eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] cannot boot installation media
Hi! Not all USB sticks are enabled for booting. And maybe it is disabled in your BIOS setup. The MBR of the stick may matter as well, and whether you boot UEFI style (not possible with FreeDOS) or classic style ;-) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How can I make FreeDOS correctly display the "ã" character?
Hi Robert and Davi, The system's keyboard and layout are already configured to "br" (for Brazilian Portuguese) and working perfectly. Other accentuated characters display just fine. That is the case of "á", "à", "ô". However, "ã" shows as something else entirely. Image below: oIh6TW8.png How can I get FreeDOS to correctly display those characters? You probably have to load DISPLAY and use MODE to set the codepage to load a font which has all accented characters at the place where your already Brazilian keyboard configuration expects them :-) See the HTMLHELP system for details. There should also be some examples on the web. It should work similar to this: First, load the DISPLAY thing. You can do this in your autoexec to load it automatically at boot, or manually at the prompt: LH DISPLAY CON=(EGA,,1) rem or maybe for example DISPLAY CON=(EGA,858,1) or similar? Second, use MODE CON CODEPAGE (shorthand MODE CON CP also works) to first prepare (shorthand PREP) and then select (shorthand SEL) the codepage for your country. In my example the codepage is 858, which happens to be in EGA.CPX, which is a compressed version of EGA.CPI - some less common codepages will probably be in other CPX files. MODE CON CP PREP=((858) C:\FDOS\cpi\EGA.CPX) MODE CON CP SEL=858 You can do those two MODE invocations in autoexec or at the prompt as well. You can use MODE /? for help, too. The internet says that Brazilians prefer codepage 860 :-) Regards, Eric 1) How do you enter "ã"? 2) Is that a separate key on your keyboard? 3) What does https://bootablecd.de/fdhelp-internet/en/hhstndrd/base/keycode.htm produce, when you hit that key or key combo? Interesting questions :-) Maybe all falls into place with CP860. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dial-up emulation?
Here is a neat summary of the DOS PPP drivers: http://www.oldskool.org/guides/tvdog/internet.html#I ...but, someone has already raised this question: Do you have a "counterpart"? I mean - a dial-in service answering with a modem and a PPP stack. Or at least a null-modem connection to a PPP "server", such as pppd running on Linux. Or possibly Windows running the "server side of RAS" would work too. On BTTR, there is a thread about this video: https://www.youtube.com/watch?v=wLVHXn79l8M "Let's Make a DOS BBS in a offensively modern way" 00:00 - Intro 00:15 - A Word from our sponsors 00:39 - What is a BBS 05:16 - How does a BBS work 13:15 - Lets get modern (containers) 23:51 - Kubernetes 26:56 - Build a server install Kubernetes 31:30 - Ceph, lets store some files 38:09 - Doors 42:38 - Lets make a helm chart 49:03 - Dial in and modems 53:17 - fTelnet 55:28 - Fidonet 58:13 - Thanks https://github.com/jgoerzen/docker-bbs-renegade Might fit with the topic discussed here, but on the other side, it might not answer the question which SLIP or PPP servers can be recommended and whether you connect them to real or rather simulated modems? I have not watched the video yet. Let me know :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] GIT news via BTTR
Hi :-) Following the postings on BTTR, I collected some GIT links for you: 1. Japheth has released VSBHDA (Virtual SoundBlaster for HDA, I guess) now with 16-bit support, improved emulation and Runtime Error 200 fix. https://github.com/Baron-von-Riedesel/VSBHDA/releases 2. The DIY SoundBlaster 1.0 clone "Snark Barker" comes with a free/open diagnostics tool SBDIAG, which is nice for everybody. https://github.com/schlae/snark-barker 3. A new version of the MicroWeb browser, 2.0 has been released. It supports Unicode and GIF and creates PNG/JPEG placeholders, if I understand things correctly and can now use EMS memory. https://github.com/jhhoward/MicroWeb/releases/tag/v2.0 4. USBDDOS is a DOS driver stack for USB by Crazii: https://github.com/crazii/USBDDOS Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Adapter PCMCIA to CF
Hi! If I have to guess: If your CF is at least a POTENTIAL boot device, the BIOS may add it to the list of harddisks for which no DOS drivers are required. If it is not, then it is just some plug and play device which may come and go and for which you would probably have to find appropriate DOS drivers to let DOS handle the coming and going properly. Similar things happen with USB flash sticks: If you boot from them, they may behave like internal harddisks, but if you do not, or if you remove one stick and plug another stick while DOS is already running, DOS and/or the BIOS may not notice the "disk change", causing all sorts of problems. Regards, Eric OK, apparently the PCMCIA -> CF adapter must be added to the BIOS boot list. Otherwise FreeDOS doesn't detect it. So everything is fine, 100% functional. Can someone explain to me why I have to add it to the boot list in the BIOS? I don't want it to try to boot from the adapter. If you can give me a website to read, that'll be enough for me. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Directory comparison program
You could try a DOS port of (GNU, diffutils?) "diff", for example from the Delorie DJGPP compiler website. Diff can be used to list differences in text content of files or directories full of files, but you can also use it with options "-qr" to just get a list which files only exist in which of the two directories and which files exist in both with different contents. Files which exist in both and have the same contents will not get listed, unless you add the option -s Whether file sizes differ is covered by whether contents do, but diff does not tell you whether date and time differ. You could abuse the dry run mode of rsync for that, maybe, but this would probably be a weird solution for the task. So I suggest: diff -qr onedirectory otherdirectory or, at your choice, diff -qrs onedirectory otherdirectory :-) Eric Yes indeed. It would be recursive too. Report the absence or presence of files/ directories, differences of file sizes, date/ time. On 2024/03/20 10:38, Thomas Cornelius Desi wrote: You mean it would list filenames differing from a Dir /foo and Dir /fuzz like in a diff program? Does any know of a directory comparison program? John ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] QEMU - Max size of Linux access folder
Hi Jim, while this is a bit off-topic: Turning a 32-bit Ubuntu into a 64-bit one is tedious, so the recommended way is to just install the new over the old and keep your home directory. A few commands in the shell can help you to, more or less, clone your old package selection into the new system, but there is no wizard to help you with that at all, which I found very disappointing given how smoothly their upgrade wizards usually lift you from one version of their whole distro to the next if you stay within the same bit-ness. So people just decide that 32-bit is dead and you end up with no longer getting updates from your distro, being forced to re-install more or less from scratch. In my case, I could not have stuck to the outdated packages, because the new graphics card only had 64-bit drivers. Nevertheless, I liked the time when dosemu could just use hardware vm86 for fast CPU access on 32-bit Linux. Now you always get emulated CPU, which of course does have advantages in some cases - such as running on ARM or emulating more aspects of real and protected mode. Also, dosemu2 gets FAR more frequent updates than dosemu. Regards, Eric PS: It also frustrates me that 4 GB are not enough for a few dozen browser tabs in 2024, neither with 32- nor with 64-bit Linux under the hood. I want efficient apps instead of repeatedly having to add more RAM or SSD swap. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] QEMU - Max size of Linux access folder
How about using Dosemu2? When you add their PPA, you get frequent updates. Unfortunately focused on 64-bit distros, but performance is quite okay and it can map any Linux directory to a DOS drive letter, so size is "unlimited". Eric Hi Jim Thanks again. My problem is that I have assembler source code from 40 years that occupies about 680Mb that needs to reside on one drive in order to assemble. Then there are the application programs. All this currently resides on an ancient XP machine. I have stayed with Lubuntu 18.04 as the later versions use SNAP and no longer support old hardware. Newer versions are very slow. I have removed snap and tried all the tips to improve speed and responsiveness without success. The current system error appears to have no obvious impact. I have located the logs and nothing jumps out at me. QEMU has improved. I tried QEMU over 2 years ago and gave up. It fell over every time while trying to run Borland's Sprint word processor. It now works correctly. John ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Ramdisk
Hi! You probably want to use XMS based ramdisks, not EMS. Also, the max size for FAT16 ramdisk is a bit below 2 GB and you can only have far less than 4 GB combined size because some of your first 4 GB address space are used for graphics etc. You can use "super extended" XMS 3.5 for a combined size of more than 4 GB, though. Several FAT16 drives, there is no FAT32 ramdisk that I would be aware of yet. The concept of XMS 3.5 is experimental, a special XMS driver and modified ramdisks for it can be found on: https://github.com/Baron-von-Riedesel/HimemSX ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] C programming guides
Hi Thomas, many screens will resize the signal you send them to full screen, probably with black bars either on top and bottom or left and right to match aspect ratio. This will usually give you large pixels or a fuzzy, blurred experience, so it has downsides nevertheless. So it is not common to get a physically small image from low resolutions. Some laptops did that, but they typically had a hotkey to enable scaling, something done by hardware and/or BIOS? Anyway, I would suggest that you either use MODE to activate one of the more classic modes, or some VESA based utility to activate any of the modes offered by the VESA VGA BIOS. This, however, will give you more characters on screen, but not larger ones! If your screen does scaling, the characters will actually be smaller if you have more of them. So you could rephrase your question: Is there a DOS text editor which uses high resolution VESA modes and high resolution character fonts, for large and sharp character outlines? I think Blocek uses graphical fonts, but I am not sure which font sizes it includes. Editors with vector based fonts could scale dynamically based on screen resolution. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] C programming guides
Hi Ed, Is there any major differences between FreeDOS and MSDOS under the hood? FreeDOS aims to be highly compatible with MS DOS, so even if you rely on some "reasonably inner workings" of DOS beyond the normal int 21 interface etc. everything should still work very much the same with FreeDOS. A well-known exception is Windows: If you use 386 enhanced mode or Windows for Workgroups and open multiple DOS windows in parallel, Windows will rely VERY much on deeper inner workings to be exactly as in MS DOS to make this work with DOS, which normally does not run several times in parallel. This only has rather experimental support in newer FreeDOS kernels. Probably no issue for you, though. I did notice differences in DosBOX as this has the SVGA drivers built in so you can use high definition modes up to 1024x768 in 256 colours iirc. That is not actually a property of DOS: It is a property of your DOS applications and whether your hardware (or simulation of it, if you run DOS in a DOSBOX window) is compatible with what your applications expect. It also depends on whether your VGA BIOS is compatible with what your application expects. That said, SVGA will work equally well with MS DOS and FreeDOS, because DOS itself does not participate in SVGA infrastructure. SVGA just is something used by your apps, provided by your hardware and BIOS. In exciting related news: There is a new project to create a simulation of a classic Sound Blaster soundcard, figure out what sound it would produce, and then send that sound data to a modern standard HDA or AC97 sound chip which is more likely to exist in your modern real hardware PC than an old ISA slot with an old soundcard. This can be very useful because your old games are likely to hardcode expectations about sound hardware which simply are not met by modern sound chips. So there are no easily swappable drivers and the simulation is a good workaround. Yet again, your old games communicate directly with the real or simulated sound hardware. There are no interfaces for this provided by DOS, so it makes no difference whether you use MS DOS or FreeDOS when it comes to sound in apps. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] News from the forum
Hi! Here are some recent news from the BTTR forum :-) Japheth has updated JEMM, DEBUG and vSBhda: https://www.bttr-software.de/forum/forum_entry.php?id=21356 - VSBHDA is a fork of crazii's SBEMU which creates a virtual SoundBlaster and sends the sound to your real HDA, ICH, nForce, VT82c686, VT823x or SB Live or SB Audigy sound with the help of HDPMI32 and JEMMEX protected mode APIs - DEBUG has some bugfixes in version 2.01 and 2.02 this year - JEMM 5.84 improves simulated I/O QEMM QPI API compatibility (which is relevant for VSBHDA, for example) Some person who created a HMI style HDA sound driver now also offers something called AHCIWRAP .sys: https://www.bttr-software.de/forum/forum_entry.php?id=21336 The fork implements audio and raw secctor functions, as well as controller PCI addresses != 00:1f.2 on top of AHCI.SYS https://github.com/PluMGMK?tab=repositories Laaca recommends the same developer because of the mentioned HMIDRV_HDAUDIO driver for DOS games with HMI driver framework: https://www.bttr-software.de/forum/forum_entry.php?id=21335 https://github.com/PluMGMK/hmidrv_hdaudio I wonder which games use HMI. Apparently Rayman and Watlers World. There is a new version of the ASTRA "Advanced Sysinfo Tool and Reporting Assistant" from sysinfolab as well as a new HWINFO: http://www.bttr-software.de/forum/board_entry.php?id=16853 https://www.hwinfo.com/download/ HWINFO 6.2.3 2023-12-29 http://www.sysinfolab.com/download.htm ASTRA 7.0 2023-12-12 (free for non-commercial use, with SPD, SMBIOS, chipset info) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] AUTO SHIFT keyboard on DOS??
Hi! So it would need a »timer« to count from pressed key to released. if >500 ms, it should send an ASCII We understood that. But be aware that you normally set the typematic function to start typing MULTIPLE characters after a selectable delay of between 250 and (at most) 1000 msec. So if you hold the "a" key for more than 1 second, would you want it to type multiple "a" or rather multiple "A"? And would you need this "hold for at least 500 ms to get A instead of a" only for A-Z or also for other keys? Bret mentioned the example that people want to keep "=" pressed to type "" lines and I myself would want to keep "left" pressed to move the cursor further left etc. example uppercase A = DECIMAL code 65 lowercase a = DECIMAL code 97 Difference between lowercase and uppercase is 32 In my example with MKEYB, you would not actually manipulate the ASCII value. Instead, you manipulate whether the BIOS believes whether you have pressed SHIFT ;-) The actual key to ASCII conversion stays in the reliable hands of the BIOS. Would this work? Sure. You would not even need a new timer for it, because you already HAVE a system timer tick counter. So you just look at that counter when a key is pressed and look again when it is released. Then you calculate the difference and based on that you decide whether the special driver pretends SHIFT was pressed at the moment the key got released ;-) Of course this means you have to modify the source CODE. It will not make the driver much more complex. Feasible. The other suggestion was that you could press some key which is otherwise not used BEFORE typing the "a" to tell the driver that you mean "A". This is very similar to the well-known feature that you can press ^ followed by a to type â and so on. A driver which already has support for such accent combos could probably support new combos for upper case chars by simply editing the CONFIGURATION without editing the CODE. You could probably use a key like one of the windows keys, the scroll lock key or some accent you do not really use as "the accent/special key which makes the next character you type an upper case one" :-) Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] AUTO SHIFT keyboard on DOS??
Hi! Indeed I was hinting at "manipulating 40:17 does not automatically sync the physical LED, but we might not care for auto shift anyway". Regarding your idea to show shift LED status on screen, check out the old LOCKTONE with audible feedback: https://auersoft.eu/soft/ Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] AUTO SHIFT keyboard on DOS??
Hi! https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/xkeyb/xkeyb-1994/XKEYB.TXT This seems one of those nifty keyboard drivers, but it has not time-critical functions I was more thinking in the direction of MKEYB or other int 15.4f based drivers: They see all key press and key release events and are able to manipulate things before they return control to the BIOS keyboard routines. The idea is as follows: If the driver sees a key press event, it could record the current time (counter at 40:6c) and, if a temporary fake shift was active (see details below), deactivate it now. If the driver sees a key release event, it could check if the corresponding key press event was long enough ago. If yes, it could make the BIOS believe that SHIFT would have been active at the moment. The driver can set some flag for itself, so it knows to undo the fake later. Return to BIOS. To fake shifts, one can just modify the flags at 40:17 and 18. It will not update the keyboard LEDs, but that is acceptable. The BIOS itself uses 40:96 and 97 to track its own status. Of course the details can get a bit more complicated, as you also have press and release events for shift keys etc. and special E0 ... key combinations and so on. But if you are happy with just the most mainstream keys acting in that "long press means shift" style and only while no actual ctrl, shift, alt or similar modifier keys are pressed, it should be quite feasible to implement this. Note that you will also have to manipulate the autorepeat functionality of the keyboard or BIOS. For example our MODE CON RATE=... DELAY=... command shows how to do this. It just uses BIOS function int 16.0305, no low-level trick. You can also think of the driver keeping track of WHICH key is in progress of being pressed for longer, for extra control over the interaction of typematics and autoshift. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] AUTO SHIFT keyboard on DOS??
Hi! I am not aware of such drivers, but it would not be hard to write one. I think there already are drivers to make shift keys sticky, or to give audible feedback, as in my ancient locktone experiment inspired by Mielke.cc :-) Eric is it possible in DOS (using BIOS?) to implement a tsr or so which allows the following: holding a key longer to return a SHIFT-key on screen? Example: press key »a« and HOLD the key for e.g. 500 milliseconds, => print shift-a = »A« on screen. Anyone around who has an idea or knowledge if this is possible or has been done or any hints where to look? ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] One use case for FreeDos
Hi Thomas, actually I was looking for a laptop with FreeDos using a photovoltaic system… That should be relatively easy. Photovoltaics can output 12V DC, 230V AC with an inverter, or higher DV voltages directly via USB-C which some newer laptops use for charging. However, those will not usually have a BIOS, only EFI, so they cannot run DOS on hardware. Running DOS on a not too new laptop is generally easy, but you will almost never have WiFi / WLAN drivers for DOS and whether popular DOS text or graphics modes look okay on the laptop screen will vary depending on the model. Maybe a trial and error thing. Or maybe some people here can recommend some laptop models :-) I once tested DOS on an eeePC, which was okay, but as far as I remember, popular resolutions had to be displayed either with black bars or in a distorted and somewhat fuzzy zoom mode, so it would probably take some experimenting to find a smooth mode. Also, eeePC are too tiny for real work, I was just curious there. (Is there DosBox for iPhones :?? ) There probably are some PC and/or DOS emulators for Android. Interesting that you already knew Velotype! Regarding mouse movement: In text mode, the mouse will jump one character at at time. Of course there are graphics mode based editors for DOS, too, like Blocek. Which may also have the advantage that you could pick a graphics mode with better match to your laptop screen size. printers understanding plain text or PDF are easily available. However, remember that text editors for DOS do not directly output PDF, so you will need additional tools and steps from text file to printout on paper. I agree that Centronics no longer is popular for printers, but if you want to run old printers on new PC, use an USB to LPT adapter cable. I would hope generic DOS drivers exist for that. Interestingly, with modern hardware, printing from DOS through wired LAN to a network printer with PDF and/or PS or plain text support might actually be less effort than using USB, but those printers are probably more bulky than certain USB printer types. Which brings in small external "print server" devices where you can plug USB printers and a network to make printers networked. Maybe some can also do the PDF rendering for "dumb" printers, but the whole idea is getting close to "just use Raspberry Pi or all that modern hardware and run a DOS window on that" ;-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] One use case for FreeDos
Hi! Why a typewriter? Because where I write, I don’t have electricity (!). Well there always is sun and photovoltaics... What type of text input hardware would you like, given that you dislike the current style of keyboards? Apart from sliding a pen over an on-screen keyboard? Is your goal to enter text quickly? Maybe learn to Velotype :-) https://en.wikipedia.org/wiki/Velotype The estimated energy consumption of a Google search query is 0.0003 kWh (1.08 kJ). The estimated energy consumption of a ChatGPT-4 query is 0.001-0.01 kWh (3.6-36 kJ) [...] That means a single GPT query consumes 1,567%, or 15 times more energy But 36 / 1.08 would even be 33, not 15? Every first letter of a new sentence appears with a lower case letter. Autocorrect could fix that. The road map of FreeDOS seems to me include compatibility with advancing storage devices. And USB devices such as printers. Maybe networking. I think it already does support printers and WIRED networking. For wireless, you can use a small external device as a proxy. Note that some printers are not smart enough and have to be fed pixel data, for which DOS drivers usually are not available and not planned, but printers understanding plain text or PDF are easily available. You can connect printers using USB, printer port or network. And you can again use small external devices as proxy, or even adapter cables, to make more combinations work with DOS. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Using HDMI monitor and USB keyboard/mouse on FreeDOS
Hi Bill, Today I built an adapter that translates USB keyboard and mouse to PS/2 signals. https://docs.pikvm.org/pico_hid_bridge/ It works great! Great to hear :-) From another thread on another forum, here are some suggestions for VGA to HDMI converters: - the current best choice might be the OSSC (open source scan converter) device for somewhat above 100 Euro: https://videogameperfection.com/products/open-source-scan-converter/ The OSSC converts SCART, component and VGA to DVI and HDMI, with some choices in scaling style (scanlines, rectangular pixels, etc.) and you can add audio from the OSSC audio jack input to your HDMI signal. See also https://www.retrorgb.com/ossc.html - "Foinnex VGA adapter cable" to convert VGA to HDMI up to 1080p, code X000PPZ323 and probably quite affordable - ATEN.com VC180 VGA and audio jack to HDMI converter with audio, up to 1080p, price unknown, but exists since at least 2014 - the future https://oummg.com/ CRT Terminator which is an 8-bit ISA card which connects to your VGA card internally, via the feature connector, to add DVI-D output to it for further conversion, such as USB3HDCAP bridging mentioned below, planned to be available for around 200 Euro Projects and devices with a focus on old game consoles: - there is a DIY Raspberry Pi based project called RGBtoHDMI: https://github.com/hoglet67/RGBtoHDMI - Ligawo scaler from SCART (with RGB), composite or S-VHS to HDMI, various models, below 100 Euro and it might be feasible or even easy to convert VGA to SCART-RGB? - XRGB mini Framemeister by Micomsoft with composite, JP21-SCART, RGB, HDMI, ... inputs, apparently. 300 Euro, specializes on retro looks with square pixels and scanlines and similar You could also use another PC as a bridge: - any PCI or PCIe framegrabber with VGA input - StarTech USB3HDCAP video grabber for PC with USB3, inputs include DVI (see above), HDMI, component, composite 210 Euro Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] shutdown and USB Stick ?
Hi! Does the Shutdown- Command merely provide for those »spinning down« delays to... The idea is that it is better for mechanical harddisks to first spin down and park heads before you switch off the power supply. Spinning down may take a moment. Also, this gives the disk the chance finish writes from the internal cache of the disk, if it has one and it is enabled. The latter also is useful for SSD. If you do have a software cache with delayed writes, such as SMARTDRV or NWCACHE with the respective features activated, it may also be useful to wait a moment after triggering the cache flush, but actually: Could somebody who HAS those caches TELL me whether this is necessary? It could also be the case that the caches do the complete flush in a blocking way anyway. So when I give them a hint that they should flush, they might block all other DOS activities until they are done with flushing? In that case, no additional delay would be necessary. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] shutdown and USB Stick ?
Hi! FAT is always a finicky filesystem, especially if you're utilizing a caching or BIOS emulation for USB HDDs. Are you using a caching program like lbacache, cdrcache, smartdrv, etc? Of those 3, only SMARTDRV can cache data before it gets written. Even this delayed write caching is a config choice of the user. The other 2, as well as Jack's drivers with built-in caches, always send writes to the disk immediately. They only use the cache to speed up reads. The don't delay writes as in collecting them in DOS-based cache RAM and then sending them to disk later. However, various types of harddisks and SSD have built-in caches which can collects written data before it actually gets sent to disk. And even without a cache, a shutdown or reboot can easily happen at a moment where some disk contents are being sent to disk and only some of them have arrived yet. As a rule of thumb, it is generally safe to disconnect drives or shutdown or reboot DOS as soon as you are back at the DOS prompt and the disk activity light has stopped. Maybe wait an extra sec. Longer waits or explicit flushes of write caches should only be necessary if you have explicitly enabled such caches. SMARTDRV, when you tell it to enable delayed write caching (DR DOS NWCACHE also has a "write pooling" mode as a "smaller" write delay choice) will monitor some activities to trigger flushes itself: For example, it would flush the write cache when an app exits (or returns to the prompt) or when you press ctrl-alt-delete or when there were no disk accesses for some amount of time. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Using HDMI monitor and USB keyboard/mouse on FreeDOS
Hi Bill, group. The short version: With the coming of Wayland I have little choice but to get new display adapters for all of my Linux machines. You probably are not technically forced to use Wayland: Most distros give you a choice of drivers to pick from, even when they recommend one specific framework as default. My FreeDOS system is hosted on an old mainboard - an Asus P5A-B. This board does not have USB ports and does not have emulation support That is a Socket 7 board with EDO/SDRAM DIMM, AGP, PCI and ISA. Are you sure that you need a board THAT old for your DOS tasks? According to https://www.anandtech.com/show/116 P5A-B should have two USB ports. Maybe you just need a slot bracket to access them. If that fails, you can still use a PCI USB adapter card. I agree Bad or missing USB legacy support in the BIOS may be an issue, but: I could install a board with USB ports, but that does not help FreeDOS. Without BIOS support, try DOS USB drivers. I guess it would be acceptable to have to connect a PS/2 keyboard directly, without a KVM switch, for BIOS setup purposes once, as long as DOS can use the USB keyboard properly after booting with USB drivers loaded. The Raspberry Pi Pico is not a full-on Pi. It is a microcontroller much like an Arduino, though with quite a bit more processing power. Good to know. I checked what "USB PS/2 Arduino" brings up, so in case somebody else is curious about alternatives: - Stackexchange says flexible USB keyboards can do PS/2 data and clock on USB D- and D+ respectively, and of course +5V and GND, so that is the wiring which your USB KVM switch MIGHT support: https://arduino.stackexchange.com/questions/54853/how-to-convert-usb-to-ps-2 https://i.stack.imgur.com/tXhcw.jpg - Instructables has an Arduino PS/2 to USB adapter project, but that is for connecting PS/2 keyboards to modern computers. - There are Arduino libraries to use PS/2 keyboard or mouse, so that again is easier than the other way round, simulating them. - Arduinos default to showing up as serial port devices when you plug them via USB, but there are versatile libraries like V-USB: https://www.obdev.at/products/vusb/index.html My quick search did not bring up a ready-made solution for what you were looking for, I just THINK it should be possible with much less computing power even than an Arduino style RPi Pico. At $4 a Pico is also cheaper than most Arduinos. :-o Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Using HDMI monitor and USB keyboard/mouse on FreeDOS
Hi Bill, if I understand you correctly, your Linux PC stopped to support VGA or PS/2, so you upgrade everything, including the DOS PC, to HDMI and USB? It should be no problem to use HDMI and USB directly with DOS. The BIOS will have USB legacy support to convert keyboard and mouse data into PS/2 simulations made visible to DOS. You could also use DOS drivers, but using the BIOS is easier. You cannot use both at the same time for the same controller, but you often have more than one controller: You could run one with a driver and leave the other to the BIOS, if you have the need to use DOS USB drivers for special hardware. Modern graphics cards (think all sorts of GeForce etc.) have slowly degraded with respect to their compatibility to DOS and VGA, so for example the 8x14 font may not be installed (you can load a driver to fix that) or only the most popular graphics modes (320x200, 640x480 and 1920x1080, I guess) will work correctly, while exotic gaming modes may show garbled screen contents. I would not use hardware converters unless you really need to use them. For example a PC without AGP, PCI or PCIe where you cannot install a graphics card with DP, HDMI or at least DVI output. Those three luckily are close enough family of each other, so graphics cards may automatically assist mostly passive adapters or adapter cables. Your "receive VGA, calculate HDMI" converter, on the other hand, is basically a computer itself, with limited compatibility. I would not use a complete Raspberry to convert PS/2 to USB or back either if your DOS PC already has USB anyway. Also, Arduinos have enough power if you do want a PS/2 to USB gadget. Regards, Eric PS: Here is a short thread on 4k screens in DOS ;-) https://www.bttr-software.de/forum/board_entry.php?id=21010 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] SNMP agent for DOS?
Hi Anton, The machines are indeed physical with custom made ISA Bus controller cards, built on prototype board, and only 4 were made, 2 in production That sounds exciting! plan is to eventually replace ... with something more ubiquitous. Looking at other forums, people do impressive things combining old and new hardware. For example there are tiny modern microcontroller based extension cards for old PC, emulating all sorts of classic boards, people convert from TV to HDMI using DSP based boards and DOS expert RayeR is working on a way to connect classic ISA sound cards to modern mainboards through the LPC bus on the TPM header! For more general purpose things, Raspberry Pi style computers can be a good option, natively running Linux, sometimes other operating systems, or emulators for retro operating systems inside Linux, while at the same time offering a variety of GPIO and bus systems suitable for different control projects. Have a good evening, too! Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] sound blaster emulation for modern hardware - SBEMU and forks
Hi folks! As you know, crazii has taken the idea of VSB on a whole new level by writing a simulation of a Sound Blaster 16 for DOS, which is able to output the calculated sound on modern HDA sound hardware, ICH, nForce, SB Live, SB Audigy, VT82C686 or VT8233, -35 or VT8237. Checking Vogons again, I noticed that there are 2 threads with a total of 75 pages of posts about SBEMU by now. Development is really active and there already are 3 forks! SBEMU-X adds support for some additional sound hardware (in your real computer, not virtual) and VSBHDA by Japheth fixes compatibility with HX. I hope the forks will eventually merge, but I guess we should already add at least one of the versions to our distro. Note that they all need HDPMI32 and JEMMEX with QPIEMU or QEMM. https://github.com/crazii/SBEMU https://github.com/sbemu-x/sbemu-x https://github.com/Baron-von-Riedesel/VSBHDA All variants together feature quite a few supported sound chips and sound cards and I am sure they are getting the deserved attention on Vogons, but I also am sure that they will enjoy feedback from testers who have one of the lesser tested chips! Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS or DOS based mail clients
Hi Jose, > PS: The older POP3 only allowed access to the inbox, > while IMAP also allows access to your other mail folders, > so I expect most mail providers to support IMAP now. I thought that folders were a client-side convention, and mail (POP3, IMAP) servers kept all incoming mail to one address together. Folders are something managed on the server and you can use either IMAP or webmail to access them. With POP3, you can only access the inbox, so you would have to use the client to move individual mails to folders stored on your local disk. The mails in those client side folders would not be visible on other devices or webmail, so I assume and hope that most providers support IMAP today, so all devices can share the same folders :-) According to the google support website, IMAP will always be active for gmail in the future. No idea how old the article is - probably the future already is now :-) In the past, one had to manually enable it using some online menu. The google support website recommends that you do not store sent mail on the server manually, as sending mails via google will automatically do that already. It also recommends to save drafts, but not deleted mails on the server and it recommends to not move deleted mails to the trash can folder, as they would get permanently deletted after a month in the trash can and google prefers old mails to stay forever :-p It recommends that you set your client to just mark deleted mails as deleted where they are. Servers for Gmail: smtp.gmail.com TLS port 587 or SSL port 465. imap.gmail.com SSL port 993. pop.gmail.com SSL port 995 (but IMAP is better). Use the email address as user name to log in. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] roundcube, is freedos, or dos based mail clients?
Hi! a few years back, before the Pandemic, we had a serious Shellworld crash. At the time I sought to contact them, did not reach a person, however. Likewise at the time, I believe? they did not allow mail to be sent. it has been a few years. If you use a Linux mail client to access your gmail from a shell, then the mail itself will still be stored and sent by google, not directly from your shell account. Note that this only works with mail providers which support imap and smtp and with clients which support the security protocols required by the providers. For some mail providers, one first had to enable imap etc. access using a menu item on their webmail portals. GMX & web.de are two mail providers having that issue as far as I remember. Regards, Eric PS: The older POP3 only allowed access to the inbox, while IMAP also allows access to your other mail folders, so I expect most mail providers to support IMAP now. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] roundcube, is freedos, or dos based mail clients?
Hi! Thanks for your roundcube webmail tests! Both interesting and annoying that most features work with most text based browsers - except sending mail, due to JS in the send button! Anyone at all know if roundcube has a support team? This tool could be amazing with some slight JavaScript fixes. https://roundcube.net/support/ lists a community forum, bug tracker, several mailing lists (probably not what you need) and an IRC chat. The bug tracker, forum and chat should help you. A quick search in the forum suggests that roundcube used an editor called tinymce to compose mails, I wonder if it would be possible to switch off the editor to be able to write mails with less javascript usage? It may help to switch to text-only instead of HTML mail composition, if there is an option which lets you choose. There is an interactive drop down menu to edit either in HTML or plain text, but I guess that uses a script, too? User preferences or configuration should have an option compose HTML messages, choices always / never or similar. Related keywords may include HTML editor or rich text. https://github.com/roundcube/roundcubemail/issues/5937 "Send a reply and archive in one action button" is vaguely related because whoever addresses that feature request will also know how send buttons are to be processed. Trying to find an answer on roundcubeforum.net I got the impression that people did not get answers at all when their questions were not specific/detailed enough. Sometimes people report that send mail button does not do anything and got the reply that the roundcube server was misconfigured. I guess this can be excluded in your case and you have tested that sending DOES work okay if a fully javascript enabled web browser is used? Some skins (graphical look and feel choices) appear to have send buttons arranged in different ways. Sometimes there is more than one send button visible at the same time, with the extra buttons using javascript to "press" the main button, if I read correctly between the lines. There also seems to be the issue that TAB switches to the next form field or button (for example send) which annoys people who want to type TAB as part of a mail. If roundcube manipulates this, it may affect usability. https://www.roundcubeforum.net/index.php/topic,29737.msg75552.html has somebody find out that their browser plugins interfere with whether the send button works. Not helpful for your problem, but suggests that this button indeed contains more complexity than necessary in some way. I am probably not very good in navigating advanced search in forum or bug list. Maybe asking on IRC works better? Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] freedos, or dos based mail clients?
Hi! As it seems that sshdos (ssh) and the links text mode browser for DOS support current security protocols and https: Does anybody here have experience with using a squirrelmail or roundcoube webmail in links? Might need less java script compared to gmail to use those, and one could forward the gmail mail to a mail provider with squirrelmail or roundcube. Another option, given that shellworld offers access to Ubuntu Linux servers, would be to use any of the current or less current text mode email clients. As long as they support imap (or pop3) etc. they should work with gmail? For example mutt, pine, alpine, cone, or the old mailx. Graphical mail clients for DOS are not the answer here. Regards, Eric PS: I also wonder whether it is an option to run a Linux email client in a shell directly on the router at home? ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New versions: R. Swan's A72 assembler 1.05 and 1.05c
Hi! Forwarding from Rugxulo on BTTR: https://www.bttr-software.de/forum/forum_entry.php?id=20850 R. Swan's A72 assembler 1.05 (self-assembling, 8k .COM) posted by Rugxulo A72 1.05 was released on Oct. 9 on Github. Changes: * Listings are generated by default along with binary output. To have only one or the other, use the /L or /A switch, respectively (e.g. "a72 my.asm /a") * Listings have line numbers * Symbol tables, alphabetically sorted, are appended to listings * More modular construction; in particular, the CPU-specific assembler module is exchangeable (6502, 8085) * HIGH, LOW, INCBIN, ECHO, TITLE, PAGE directives added * Lines can be 255 characters long (previously 120-something) and generate an error otherwise * LF now recognised as valid line terminator alongside CR * 8087 not supported after 1.04 until I have figured out how to work with floating point numerics and encoding https://github.com/swanlizard/a72/tree/master/1.05 N.B. As of four days ago, there is also a minor update, but it has been renamed to RA. I don't know if major work is going on there or what will happen. https://github.com/swanlizard/a72/tree/master/1.05C ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] SBEMU soundblaster emulator news?
Hi! SBEMU is a project based on MPXPLAY, DOSBOX, HX and JEMM superpowers to create a virtual SoundBlaster soundcard on real computers with more modern sound hardware (HDA, AC97 etc.) which sounds quite exciting! The BTTR thread has been silent since mid-March, so now I wonder whether there have been new developments worth discussing here or on BTTR and whether more testers are needed, and if so, which modern sound hardware needs testing or other support :-) https://www.bttr-software.de/forum/board_entry.php?id=20131&page=0&order=time&category=0 https://www.vogons.org/viewtopic.php?f=62&t=89304 The 2023-03-19 beta can be downloaded here: https://www.vogons.org/download/file.php?id=160136 Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] DosView, a modern image format viewer and converter
Hi! SuperIlu is has recently released version 1.1 of DosView: https://github.com/SuperIlu/DosView It uses Allegro and compiles with DJGPP 12, so with a 386+ CPU, enough RAM and VESA, you can now view those WEBP, JPEG2000, TIFF and other modern file formats in truecolor graphics modes on DOS. You can convert images to other formats with DosView as well :-) A thread about it on BTTR: https://www.bttr-software.de/forum/board_entry.php?id=20798&page=0&order=time&category=0 Interestingly, the newest DosView EXE UPXes from 1.5 to 0.6 MB :-) Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MSdos 7.1 question
Hi! I said it before but I'll re-iterate - any filesystem with proper journaling would be a total banger. I still remember how Rayman ate my FreeDOS and I still have dosfsck in my fdauto as a preventative measure. It's slow as molasses in January however. The same program under Linux blows it out of the water. Do you have enough cache (Jack's drivers or lbacache for example) and enough RAM, and/or made sure that CWSDPMI will not use swap? See the documentation for CWSDPMI, or try using another DPMI, such as DOS32A or DPMIONE, to run the DOS version of DOSFSCK. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] 7zip for dOS?
Hi! I did download Eric's file, as I do not use freedos. While you get extra package management features by opening our zipped app packages with a package manager, unzipping them with any UNZIP style tool will usually be sufficient. So you should be fine. The information indicates that it might be a port of a windows package. My search suggested that I should fine an executable called 7za, or even just 7z, but it is not there. the p7z file does not work at all. There are two EXE files in the download: 624292 bx defX 09-Mar-05 00:00 ARCHIVER/P7ZIP/P7ZIP.EXE 542956 bx defX 09-Mar-04 23:48 ARCHIVER/P7ZIP/P7ZIPR.EXE When you run p7zip -h or p7zipr -h they will show the help text which makes me assume that they are two different compiles of a standard 7-zip binary. I have no idea why they got renamed to p7zip here? The directory also contains various text documents and a subdirectory with a HTML manual. In addition, there are APPINFO, LINKS and SOURCE directories. The former contains metadata about the package, the latter contains a zip with the source code and the LINKS directory contains a batch file which seems to be meant as a wrapper to be put in your path to call p7zip.exe without having to add the archiver p7zip directory to your path. It does not pass the command line arguments, though, which confuses me. In short, you should be able to just copy the exe and maybe the .1 documentation files from the ARCHIVER/P7ZIP directory into a directory in your path and keep everything else around at a place of your choice for some extra documentation. You do not need to use a package manager then. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MSdos 7.1 question / Sound in DOS and FAT huge file support
Hi! You use to promote MSdos 7.1. Have you ever found a way to get sound on it. Sound, network and graphics are not related to DOS as operating system: Because the kernel does not support those, the applications, not the operating system, are the ones who have to support it. This also means that apps with support for those will have support for them on all versions and brands of DOS. It should be possible to use MPXPLAY to get DOS sound with modern hardware: https://mpxplay.sourceforge.net/ It might even be possible to get old games which expect ISA SoundBlaster hardware to work on modern hardware with the help of SBEMU or DOSBOX-X. Those have drivers for modern sound chips (AC97 and HDA standard, I guess) and provide simulations of old SoundBlaster soundcards: https://www.bttr-software.de/forum/board_entry.php?id=20131&page=0&order=time&category=0 https://dosbox-x.com/ I have never tested those two myself, so I would love to hear from others how well they work :-) I deleted a command called KILL on it. Do you know what that command does because I don't? It might be for killing tasks. DOS itself does not support multitasking, but MS DOS 7 is the DOS which ships with Windows 95 and 98, so maybe it simply is a Windows command line tool to stop Windows tasks. I love the large file size that it supports. Freedos is limited to 2 gigs and PCdos stops a 8 gigs. It would surprise me if PC DOS supports 8 GB files. Technically, the bottlenecks are the ability to seek and the file size. For relative seek, you can only go +/- 2 GB from the current point. Absolute seeks could be defined as 0 to 4 GB from the start or the end of a file. A flag when opening/creating a file with int 21.6c determines whether int 21.42 seeks should work 2 GB style or 4 GB style for that file. According to our kernel source code at https://github.com/FDOS/kernel/blob/master/kernel/dosfns.c FreeDOS does not yet support 4 GB file open and seek! But it does treat dirent.dir_size as ULONG, max 4 GB. The file size can be up to 4 GB on FAT filesystems, but one could check the cluster chain length or put a few extra bits somewhere in the directory entries? I do not know which DOS and Windows brands support such extensions for FAT filesystems, but I think EDR-DOS is one of the brands working on this and proposing an interface for it? Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Testing quite a few DOS games with modern graphics hardware
Hi! Before rebooting my Linux to activate the newest kernel updates, I have booted into DOS to find out how DOS games deal with my new GeForce GTX 1650 graphics card. It is surprisingly bad as a VGA. According to VESAINFO, only packed pixel and direct color modes are supported, with 256 or 65536 colors or 32 bits per pixel. VESA packed pixel modes: 640x480, 800x600 (1024 bytes per line), 1024x768, 1280x1024, 1600x1200 (1664 bytes per line!). Modes with 2 or 4 bytes per pixel also all have "round" numbers of bytes per line (1280, 2048, 2560, 3328, 4096, 4120, 6144, 6656 or 7680, all multiples of 128 as you can see). Resolutions up to 1920x1080 :-) As the USB mouse is not supported in my current BIOS settings and I was too lazy to change them, CTMOUSE only attempted to use a non-existing Mouse Systems RS232 mouse. So games requiring mouse input were not actually working, but that is a different story. My board still has a serial port, so I could try an old mouse ;-) Unsurprisingly, quite a few games throw error 200 or run too fast, including the popular Jazz Jackrabbit and the Kamango memory game. IGO works in VGA mode, also in monochrome VGA. Somehow it does not show MCGA properly, maybe tweaking it? For Hercules, CGA, EGA and Tandy, it reports that it could not activate the mode. GOPART (GoPartner by Ingolf Hellmann) sort of works, but one can see that the graphics font is incomplete. It is supposed to work with CGA, Hercules, EGA and VGA. I guess it tries VGA. WARI (Kalaha by ImagiSOFT) fails to enter graphics mode: You would have to play blindly while still seeing DOS text. Ballgame and Mahjongg (by Nels Anderson) also fail to enter graphics mode. I guess this happens with all EGA or CGA apps. Bananoid, which I think uses a tweaked MCGA mode, would work if I had a mouse. A cute little Arkanoid clone. Breakfree, a 3d Arkanoid clone, works, including speaker sound. 20th Century Frog shows no graphics, apparently it uses EGA. I would have thought that it uses VGA. Laserbeam by Proline just shows a blank screen, no idea. Shooting Gallery would work if I had a mouse. MCGA + Speaker. Descent would work, but runs too fast. Probably MCGA, too. The IUS intro, which uses an interesting graphics mode, shows something graphical, but not similar to the intended graphics. Crystal Caves and Commander Keen 1 effectively stay in text mode, apparently failing to switch to EGA (VGA?) mode. In Captain Comic, switching to EGA fails with a message instead. Commander Keen 4 claims not enough RAM is free if no EMM386 is loaded, or crashes if JEMM386 X=TEST ALTBOOT MEMCHECK is loaded. EGAroids (Asteroids) and Alley Cat (an ancient CGA game) fail to enter graphics mode, so once again, you see garbled text. Lemmings does not work, but I may have failed to try all the conceivably supported graphics modes for that one. I once bought a decent Windows port of it on CD, by the way :-) I have not tested Lemmings 3d (needs EMS etc.). Zeliard does work! I would have thought that it uses EGA just like all the other games which do NOT work. Interestingly, the Display Port output is native resolution of my screen at 60 Hz, so the graphics card automatically upscales the resolutions. Raptor does work (not sure whether it would support PC speaker for sound, I just got none) so space shooter bases are covered. Tank Wars (a small MCGA artillery game) basically works, but some areas of the screen are garbled. Maybe a font problem? You may know the genre from Worms and from QBasic Gorillas. Antix (Anti-Xonix) is almost playable in spite of not reaching a graphics mode. Maybe it was meant to be text mode anyway, but the font is off and the game runs too fast. Xonix basically works, just custom chars end up wrong, maybe the VGA BIOS simply provides an incomplete font charset here. Konggame (meant to use CGA 160x100 text graphics) and Pacman just end up in some sort of garbled text mode, not playable. Sint Nicolaas (MCGA Jump and Run) works, with PC speaker. Digger (DigDug clone) also works. Maybe MCGA instead of CGA/EGA? Squarez also works, as does the WOW tracker (MOD player) when you switch it to PC speaker output. Probably MCGA as well :-) Jill of the Jungle does work, MCGA with PC speaker sound. The tiny Super Mario clone "Mario" by Mike Wiering works, althought there is some tearing in the animations. Claims to be 256 color VGA, but probably just uses MCGA graphics? It is interesting that many CGA and EGA games fail to enter graphics mode and fail to detect that they failed. I guess the hardware just supports a subset of VGA and games think VGA support implies support for everything older than VGA. Some games do detect the failure, though! I wonder whether some games would be troubled by the less flexible bytes-per-line with this hardware, but I assume EGA still would not work if you were to use N * 256 bytes per line for it. I expect VESA games to be smart enough to respect the bytes per line of the BIOS in
Re: [Freedos-user] 7zip for dOS?
Hi! According to https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html you can download http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/archiver/p7zip.zip for 7zip. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Some USB-Stick problems
Hi again, see the new, separate thread for more USB-printer solutions :-) A new thought: I got a VERY good suggestion for the problem of FAT filesystems and file contents getting corrupted by those power outages when the drivers restart the engines of the trucks. You remember, I wondered whether running DOS in some emulator in Windows or Linux would be better or worse, given that those use other filesystems like NTFS or EXT3, not FAT. The suggestion is A LOT easier: Buffer those 12 Volts before you send them to the inverter! No more crashes, thus no more worries which filesystem or operating system suffers most or least from those crashes. I should have come up with THAT. Given that the outages are very short, various solutions are possible. Maybe even something trivial like charging a cap from the 12V through a diode and connecting the inverter to the cap instead of directly to the car battery. Or, for more stability for longer interruptions, charging a small 12 Volts battery, of course. I assume the printers also need 230 Volts? If not, a solution without the inverter might be possible. The Thin Client may even work directly from 12 Volts, but this is out of specs. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Using USB printers with a parallel port adapters or software tricks
Hi again, somebody in another DOS forum pointed out that you can get ready to use LPT2USB online, although expensive, from various shops: https://www.future-x.de/rotronic-secomp-parallel-adapter-usb-ieee-1284-schwarz-p-7343484/ https://www.profishop.de/p/ak-nord-adapter-lpt-lpt2usb-v2-nt-202573 https://www.secomp.de/de/item/konverter-kabel-parallel-nach-usb/12021074 I also got the suggestion (once more) to use LAN for printing, either with the evil MS CLIENT or by any other means. I guess depending on the printer, a bit of NETCAT, CURL, WGET etc. may be sufficient, or using a library like wattcp or (I forgot the other names) directly in the DOS app. Regards, Eric Hi! Moving this topic to a new thread: Next problem: I tried to get printer support via USB (currently they use classic LPT, but those printers get very rare). Asking around and looking around a bit, people have suggested to run DOS inside vDOSplus, DOSBOX-X, DOSEMU2, VirtualBox and so on with a Linux or Windows host operating system. I think when you run DOSBOX-X on DOS as host, it would not support USB printers. But it could support HDA, AC97 soundchips and simulate SB16 for the DOS inside? Sounds very nice! :-) Also, I wonder how Windows and Linux would react to those frequent power loss related crashes of the whole computer. Probably not very amused? Either way, I stumbled over a cool microcontroller based solution by Henrik Haftmann, with free EAGLE PCB data and circuit diagram and the corresponding firmware. Even an ultra low cost RS232 firmware install method is part of the project :-) https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/lpt2usb.de.htm https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/lpt2usb.en.htm Of course this is less superpowered than https://www.retroprinter.com/ mentioned earlier, based on a complete computer and able to convert old DOS printer data to output even for GDI printers if I got that right? The page also links some alternatives from other sources, but I found ALL of the linked products in the Gibt's schon / re-invented section to be no longer available. So better make some backup of Henrik's USB2LPT. Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDLE HALT=1 is working on my laptop?
Hi Ramon, If I use FDAPM APMDOS in my fdauto.bat I get the following message: Performing action: APMDOS If APMDOS slows APM not available, skipping APM setup. Going resident. This is because I have freedos poorly configured or because my hardware does not support it. (My laptop is about 12 years old) As you see, it goes resident nevertheless. Your BIOS does not offer APM support, so FDAPM uses a generic fallback instead. You could play with the FDAPM SPEEDn options (example: SPEED4) as additional trick. This will throttle the system by halting it half of the time in a fast rhythm, but be prepared that it may fail in bad ways, so do not put it in your fdauto until you have tested it interactively. It is possible that SPEEDn does not work at all, because FDAPM does not sufficiently understand your ACPI BIOS, or it is possible that it crashes the computer in some way. If that happens, you will have to hard reset it (if you have a reset button) or even power cycle it (for example by keeping the power button pressed for several seconds). Of course you do not need to use SPEEDn at all if normal FDAPM APMDOS already reduces energy consumption, heat and fan activity sufficiently. It is just an additional thing you COULD try. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] R-Alt does not act like L-Alt
Hi Aitor, I would assume that right alt DELIBERATELY does not act like a generic ALT key in EDIT: In German, for example, you need that right "Alt Gr" key for some accented characters, so it must not act as a function shift key. I remember not being able to use some other editor exactly because it treated any ALT like ALT, making me unable to type "@" because it wanted to treat it like "ALT-Q" or "ALT-@" with a special meaning for the ALT status instead of as an ordinary character. Maybe it would be useful to make this configurable in EDIT, but in a minimalist way, for example a checkbox whether R-ALT counts as ALT (for hotkeys) or is not to be interfered with. Regards, Eric Hello, Sounds like it could be a bug in Edit, I'll see about it when I have a little time. Now for the original question: is it possible to make R-Alt work like L-Alt? It should be possible to do that with FD-KEYB.The idea is to intercept Right-Alt and then emit Left-Alt, and get back to the BIOS driver. This trick is unlikely lo work in a pre-AT-class machines, but in this older machines, you can try and run FD-KEYB with the /9 and see if it works. The trick is like this: R-Alt is an E0-prefixed L-Alt, so you should define a new plane for the E0: [PLANES] ... ... E0 Then, make a new mappings sections that would just catch the R-Alt and emit a L-Alt (the scancode for Alt is 38h = 56 [KEYS:ralt] 5656/#0 Finally, add this new mapping to your Submappings section, at the end, so that it works as a fallback for the other cases (change the codepage for whatever you desire): [Submappings] ... ... 437 ralt If someone wants to give it a try and works, let me know, should be interesting stuff. You can apply the same trick to make "extended" keys work as non-extended. Aitor ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Using USB printers with a parallel port adapters or software tricks
Hi! Moving this topic to a new thread: Next problem: I tried to get printer support via USB (currently they use classic LPT, but those printers get very rare). Asking around and looking around a bit, people have suggested to run DOS inside vDOSplus, DOSBOX-X, DOSEMU2, VirtualBox and so on with a Linux or Windows host operating system. I think when you run DOSBOX-X on DOS as host, it would not support USB printers. But it could support HDA, AC97 soundchips and simulate SB16 for the DOS inside? Sounds very nice! :-) Also, I wonder how Windows and Linux would react to those frequent power loss related crashes of the whole computer. Probably not very amused? Either way, I stumbled over a cool microcontroller based solution by Henrik Haftmann, with free EAGLE PCB data and circuit diagram and the corresponding firmware. Even an ultra low cost RS232 firmware install method is part of the project :-) https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/lpt2usb.de.htm https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/lpt2usb.en.htm Of course this is less superpowered than https://www.retroprinter.com/ mentioned earlier, based on a complete computer and able to convert old DOS printer data to output even for GDI printers if I got that right? The page also links some alternatives from other sources, but I found ALL of the linked products in the Gibt's schon / re-invented section to be no longer available. So better make some backup of Henrik's USB2LPT. Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Some USB-Stick problems
Hi Woody, Unfortunately, using the internal IDE is out of question, since the whole process in that company is used to take that stick after the salestour, go into the office and plug it into a transfer PC, where some other software reads in all sales data, then updates the stick with new tour-data and maybe App- and Freedos updates. Well, you probably have a lot of control over the software, so you could modify it to just use the USB stick as vessel to transport sales data, tour data and updates while the software installation resides on the internal disk. Those sticks could boot into a tool which updates app and tours, checks the filesystem and creates a flag/lock file when done. Booting from the stick again would instead update sales data on the stick. In the office, people could have a tool (maybe a simple batch script) which gathers sales data from the stick, puts new updates and tour data on it and clears the flag/lock file again for the next tour etc. Still pondering non-USB and non-stick solutions: You may also install "extension cords" so people can plug CF cards as IDE storage. My PC has a Wechselrahmen which does let me connect a CF card with a mechanical adapter. I have stopped using it years ago, but you get the idea. There also are adapters with controller, for CF on SATA. Think about Delock 91687 or 91624 which only need a free slot bracket. Unfortunately, the T510 does not have any space for it, even a SATA cable would need a custom hole. Neither CF as IDE nor USB sticks are hot-pluggable in the DOS and BIOS scenario you are using, so there is not hot plug ability to lose, but getting rid of USB complexity still feels like a good thing to try out. Another possibility would be to replace the USB sticks by something which is less sensitive to power outages. Server SSD with supercaps come to mind, connected by SATA or via a simple USB enclosure if you must stick to using USB. Or you could improve the power supply hardware infrastructure. That 4Mb XMS limit was just because FoxPro doesn't need more. There are few apps which get confused when they get too much XMS (for example more than 32 MB of XMS 2.0, or more than 2 GB of XMS 3.0) but I would not manually set any limit unless you really have to to "protect" old apps. Windows 3 also does not like too much RAM, by the way. As said, I suggest that you do not use EMM386 style drivers unless you actually want EMS or UMB. If not, it reduces complexity to only use HIMEM style drivers. mediumtypes for the USB: Floppy, Zip and Harddisk. Those are basically predefined sets of CHS geometry. Floppy goes up to 2.88MB, ZIP is more like harddisk. You usually stick to harddisk and hope that BIOS and OS will use LBA instead of CHS anyway, to avoid any confusion about which geometry would be the best. You can also boot read-only CD/DVD or their images. Most FreeDOS bootsectors (SYS) and kernel autodetect LBA support of the BIOS, but for the FAT32 bootsector, some fixed choice is made when you run SYS, no boot autodetect. The issue of caches, crashes and power outages: You do not have to worry about the read-caches available in DOS, so you should be safe if you close files AND call those disk reset and cache flush calls after that as long as you only get crashes between flushing and the beginning of the next write. You can try to postpone writes during periods when crashes (engine restarts) are likely. This will protect you from getting half-written broken data. As said, DOS itself is barely able to cache anything in the sense of delayed or pooled WRITES. You can actually improve performance using READ caches like LBACACHE. It should not impact your data corruption problem. Only a WRITE cache would make your problem larger. Unfortunately, basically ALL storage media apart from floppy disks have intrinsic write "caching" in the sense that your data will get converted and sent to the actual disk or flash chip AFTER it got sent by the computer. So if your computer crashes while working on your files, unsaved or partially saved data gets lost or, worse, corrupted for obvious reasons. But if POWER to your drive is lost, MORE data can get lost. Some drives use backup energy (supercap or, for harddisk, using their mechanical energy) to mitigate that extra loss. USB sticks, however, are not in that category. Neither are CF cards. Their advantage is just having fewer interface and data conversion layers in the pipeline. Drives also tend to be configurable concerning whether they are allowed to pool or cache written data. Other people here may be able to recommend tools for this, but I would say it is hard to control those settings from DOS for USB drives and more feasible for SATA or IDE drives. In Linux, you would use HDPARM for this. Some drives (in particular some flash models, both SSD and USB sticks can suffer from this) also corrupt more data than necessary or even get completely bricked if a sudden power loss interrupts internal bookke
Re: [Freedos-user] Some USB-Stick problems
Hi Woody! You probably mean a HP t510 thin client, with VIA Eden X2 U4200 CPU, VIA VX900 Chipset, 2 GB RAM, some flash storage, VIA ChromotionHD graphics (DVI/VGA), audio, GB-LAN, Atheros WiFi, 6x USB2, 1x RS232, 1x LPT, 2x PS/2, 65W 19V power brick: https://support.hp.com/us-en/document/c03260067 According to this site, you can connect IDE storage, so a compact flash card with a suitable adapter indeed sounds like a great idea. CF usually support IDE I/O, which means that a simple mechanical adapter with a power regulator is sufficient, no extra controller or card reader necessary: https://www.parkytowers.me.uk/thin/hp/t510/ Depending on the model, the flash may also be SATA instead of IDE DOM (Disk On Module), which is even easier, but the mechanics can be problematic given the small housing of the whole computer. Also, the website says that using SATA SSD may somehow interfere with and damage the network interface (LAN, Broadcom NIC). There also is a tiny Mini-PCIe 1x slot, for WiFi extensions etc. The app itself was first on a 256Mb CompactFlash Card, which was attached with a USB cardreader to that PC. Why the extra step with the USB cardreader? The software booted from that Flashcards with a regular MSDOS6, no USB drivers etc necessary, seems all is handled by BIOS. When a BIOS can boot from USB, it will often be able to present USB storage as harddisk (or sometimes floppy or CD-ROM), yes. But it will usually not support changing "disks" on the fly. I then changed those Flashcards to real USBSticks and formatted them with RUFUS and FreeDOS (Kernel 2043), recompiled their App and now some "funny" things happen Using USB adds an extra layer of complexity and a BIOS with USB boot support at that time may have been very minimalistic, so for example you may only get USB 1 speed or writes would not be supported or only in slow and convoluted ways. I remember I once managed to boot DOS with Windows 3 from an USB stick on an old PC , but it was no fun to use and not really stable. Also note that certain brands of USB sticks seem allergic to power glitches or getting unplugged at the wrong moment, which can lead to data loss or even bricked USB sticks. Likely a problem with the extra complexity of the firmware running on the stick itself which prefers a clean shutdown. ... when they restart the engine, the 12V will get powered off for a short time, thus the PC just crashes and reboots. Nobody likes that, not even DOS. And USB sticks like it less than compact flash cards. Would it be possible to use a compact flash card connected directly to the IDE port of the thin client? Or some SATA device, assuming that LAN damage would not be a problem? there seems to be some caching involved. I am not aware of any free open source delayed write cache for FreeDOS, but I am not sure whether BUFFERS can pool writes to some small extent? You already call FDAPM FLUSH when the app ends, but you probably want to modify your app itself, so it can call the flush things itself (no need to use FDAPM then) each time when you close your files after using them. Would it be an option to improve power supply stability? If you boot DOS from USB, you are stuck with the BIOS USB drivers, so you cannot update DOS drivers to solve things. You should probably avoid USB storage completely, given that the thin client supports internal IDE or SATA disks. Even if you need some adapters and even if the - probably not used in the trucks - LAN or WiFi interface breaks, internal disks (CF, SSD, DOM etc.) are protected from the rough street life and are probably more rugged in terms of unplanned power loss or reboot than USB sticks. You could for example use USB just to install one of the computers (I also assume our USB images are meant more as installers than as live images for everyday use) and then clone the internal disk of that PC to create more internal disks for more thin clients :-) That also gives you full flexibility regarding whether to use FAT16 or FAT32 and whether to use only a part of the available disk space etc. With boot images, you could always get unwanted complexity such as embedded boot floppy or CD-ROM images, which you will not suffer from when installing to an internal medium. That said, you can probably just "dd" one of our USB images to a stick in Linux, keeping extra space empty. There must be Windows tools which allow you to just do a dumb 1:1 transfer of our boot stick image to USB. Other people on this list will know other boot stick creator tools for the Windows version you are bound to. Using DOSBOX as a tool for installation feels like at least three extra layers of unwanted complexity. Another recommendation: If you only need XMS and UMB space is no problem, avoid JEMMEX, JEMM386 etc. and consider using only one simple HIMEM or XMGR style driver. Yet another way to reduce complexities. As you have already found out, when you load DOS USB drivers (for USB printers) you will
Re: [Freedos-user] IDLE HALT=1 is working on my laptop?
Hi Ramon! I have IDLE HALT=1 in my fdconfig.sys and in config.sys - FreeDOS 1.3 FullUSB You probably mean IDLEHALT=1 without space. How can I know if IDLE HALT=1 is working on my laptop? because the fan starts up very frequently at full power. You could try IDLEHALT=-1 for a stronger effect, but you probably want to load FDAPM instead, using for example, in your autoexec: FDAPM APMDOS That will use less than 1 kilobyte of DOS memory and allows more energy saving than the built-in IDLEHALT. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] HIMEMX zip file dates
Hi Mercury and Jerome, I typically do modify the times to reflect the version number. Of course that's not necessary by any means, but it's a habit I started doing as a quick and easy contingency to help me in the event of files becoming crossed, e.g. if I were to accidentally drop files into the wrong version folder or some such errantry. Is the preferred behavior to not touch the times? If so, I can certainly refrain from doing so in future packages. :) Please preserve the timestamps of the original ZIP content. Good to know that Jerome has a tool for that, bad enough that GIT defaults to break timestamps without that tool? When handling files outside GIT, timestamps stay as-is. As you already add the LSM file, the handling date is preserved as timestamp of the LSM in the ZIP. You can even use ZIP -o to make the timestamp of the ZIP itself match the timestamp of the newest file inside the ZIP. In addition, I would still love the "release-cli" of our GITLAB repository to create actual release notes. At the moment, I only see WHICH packages got updated when, but need manual "research" to find out WHY. Regards, Eric PS: I think DJGPP should stay available as separate download. Most OTHER compilers are small enough to stay on the main CD. (https://github.com/Baron-von-Riedesel/HimemX/releases) was released Nov 21, 2022 and has file contents like this: $ unzip -l HimemX338.zip Archive: HimemX338.zip Length Date Time Name - -- - 6056 11-21-2022 13:01 HimemX.exe 6056 11-21-2022 13:01 HimemX2.exe 1954 04-16-2020 06:38 Readme.txt 4871 11-21-2022 13:01 History.txt 81855 11-21-2022 13:01 HimemX.asm 296 03-24-2020 01:56 Make.bat 529 03-24-2020 01:58 Makefile - --- 101617 7 files It looks like you modify the zip files when you mirror them. Your version looks like this: $ unzip -l 3.38/himemx338.zip Archive: 3.38/himemx338.zip Length Date Time Name - -- - 0 09-23-2023 03:38 APPINFO/ 568 09-23-2023 03:38 APPINFO/HIMEMX.LSM 0 09-23-2023 03:38 BIN/ 6056 09-23-2023 03:38 BIN/HIMEMX.EXE ... ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] languages
Hi! FreeDos need's update in the keyboard and languages, there is support for that in open-source environments, but I don't know how to implement them. For example I'm using a portuguese keyboard and it doesn't support it, so Iam in trouble's Actually FreeDOS has no problems with Portuguese keyboards. Even the tiny MKEYB driver supports them. If you run MKEYB /? you will see that MKEYB /L shows a list of supported keyboards, which does include Portuguese. So you could run MKEYB PO to activate keyboard support in Portuguese style, or you could add a line saying MKEYB PO to your autoexec.bat or fdauto.bat, depending on which of the two you are using. Our other keyboard drivers also support your layout, you just have to read the documentation to find out how to activate it, as they are a bit more complicated to set up :-) Best regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] CD driver
Hi! I just installed Freedos 1.3 via USB. It works OK, but will not load the UDVD2 driver (it gets a #255 error). Will UIDE work instead? Or is the problem a bad HDD sector? The problem probably is not a bad sector in your harddisk. If you want to access a CD/DVD after booting from that same boot CD/DVD, then you could also use the ELTORITO driver. For most other cases, you can use drivers like UDVD2. It might also make a difference whether you boot from USB or from harddisk (or SSD) as well. UIDE is newer than UDVD2. The newest versions of the drivers available with source are probably here: http://mercurycoding.com/downloads.html http://mercurycoding.com/downloads/DOS/drivers/2021-10-30/2021-10-30.zip This contains a 2015 rdisk (with rdiskon) and UDVD2, 2020 UIDE and xmgr (himem alternative), 2021 UHDD and a 2022 readme text file. UIDE supports both optical and non-optical drives as well as a cache. UHDD only does non-optical disks. UHDD contains a cache, too. UDVD2 only supports optical drives. UDVD2 can share the cache of UHDD if you load UDVD2 after UHDD. Note the readme regarding which drivers are best in which situation. Also note that depending on where you got that 255 error, it may mean XMS memory error! If that is what happened for you, then you may want to try different combinations of memory drivers such as JEMMEX, JEMM386, HIMEMX, XMGR etc. By default, your FreeDOS installation will already offer a few combinations in your boot menu. Try those :-) If your mainboard supports AHCI, it may belp to disable AHCI mode in your BIOS / CMOS settings. Alternatively, you can use AHCICD by the late R. Loew: https://rloewelectronics.com/distribute/AHCICD/1.1/ You can ignore the warning about the expired HTTPS. Japheth has created an unreal mode variant of it, too: https://github.com/Baron-von-Riedesel/AHCICDU You can also find updates for JEMM and HIMEMX on Japheth's GitHub "Baron von Riedesel", even his HIMEMSX to use more than 4 GB RAM :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Candyman?
Hi! Does anybody here know the user nicknamed Candyman? There is a strange thread on BTTR started by that account, maybe somebody could contact Candyman via another channel and ask what has happened. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How do I change screen resolution?
Hi! Assuming that you just want to have MORE text on your screen, without actually wanting to use graphics mode, you can select quite a few modes with MODE CON or with various VESA tools. For example in dosemu2, the following works just fine: MODE con cols=132 lines=60 This will search for 132x60 character VESA mode and use it. In dosemu2, VESA text modes 80x60, 132x25, 132x43 and 132x60 are available, but others can be available on other graphics cards or in other emulators or virtual computers, dosbox, bochs, qemu, vmware, and so on. For non-VESA modes, you can for example use: MODE con co80,50 That will select a VGA compatible 80x50 text mode. Sometimes MODE will get modes wrong depending on from which mode to which you transition. For example it may end up in 80 column modes when asking for 132 columns, depending on how many lines you want and had before. It helps to experiment: Often, you can help mode to get into the desired mode by first selecting a similar, easier mode, so it can find out how more easily to go further. For modes with more than 132 columns, you need VESA tools which make fewer assumpions about things than MODE does. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A Couple of USB Device Issues
Hi Damon! I have an old Dell Optiplex 745 I'm trying to "FreeDos" and am having a couple of issues. I have yet to get the USB Laser mouse to work properly. Try enabling USB legacy support in your BIOS. The mouse should then be visible to drivers like CUTEMOUSE as if it would be a PS/2 mouse. The other issue is PCI sound cards. I have an Aureal Vortex2 and also a Soundblaster Audigy 4. Vortex 2 = AU8830, Alsa for Linux would use AU88X0 drivers which do not seem to be AC97 or HDA. No SoundBlaster compatibility either? Audigy 4 with CA10300 DSP, also sounds sounds quite far away from DOS, but the original Audigy with EMU10K chipset was closer to SB PCI and SB PCI which came with DOS drivers. Those drivers were quite unusual because they provided a simulation of a DOS compatible ISA SoundBlaster for those non-ISA devices. If you just want to listen to media files such as OGG or MP3, then you can get a more or less generic HDA or AC97 compatible soundcard for PCI, maybe even PCIe, or mainboard with sound, and use those with MPXPLAY for DOS: https://mpxplay.sourceforge.net/ IF you want old DOS games to work with sound, then you will have to find a soundcard specifically designed for that, including the examples mentioned above. As the Optiplex 745 with Core2Duo CPU is probably too modern (!) to still support ISA features on PCI, soundcards from early PCI days with some HARDWARE compatibility ISA SoundBlaster will only work in very limited ways, for example without DMA or interrupts. Some games might be able to deal with that, or at least provide AdLib sound, but I have tried a whole collection of those on a dual core AMD board with little success. Games rarely support installing modern sound drivers later and DOS is not designed to help games with sound either, so FreeDOS will not be asked by the games. In theory, VESA/AI drivers might exist. Another option is to use drivers which create simulations of DOS compatible soundcard. Check out the recent SBEMU progress: https://www.bttr-software.de/forum/board_entry.php?id=20131&page=0&order=time&category=0 The goal here is to support modern hardware, such as generic HDA or AC97 cards on the hardware side and create the illusion of classic SoundBlaster hardware on the software side visible to your old games :-) A classic way to do this can be running your games in a virtual DOS system inside another operating system, such as DOSBOX in Windows or Linux or DOSEMU2 in Linux (later MacOS and Android?) For DOSEMU2, you have to first add their PPA to your config: If you have for example Ubuntu 20.04, then you would add a file /etc/apt/sources.list.d/dosemu2-ubuntu-ppa-focal.list with the line deb http://ppa.launchpad.net/dosemu2/ppa/ubuntu focal main to add DOSEMU2 and their repository to your software sources. You can then simply use Synaptic to install components of it and you will automatically get regular updates, too. If you have different versions of Ubuntu, you do roughly the same, but replace the word FOCAL by the name of your Ubuntu version. Of course you can also use Synaptic or other tools to enter the location of the PPA repository using a graphical menu. The mouse driver(s) (I've tried many) load without error. But the mouse moves only to the right. No up, left, or down. I assume it does work okay with other operating systems? Have you tried enabling or disabling wheel support? For CuteMouse, you can compare driver 1.9.x, 2.0.x and 2.1.x which all have different advantages and disadavantages. The aureal card claims to initialize but there is no sound from any of the midi player apps (e.g. Cubic player). Maybe a mixer problem? Or you need some specific init tool? Or the sound ends up coming from the wrong connector? MIDI music can mean two things: It could be rendering of the music using canned instruments to create a stream of PCM samples. It could also mean that the sequence of tone commands gets sent to a MIDI port or synthesizer chip you may have to connect to or init and support separately. Given that OpenCP also is a MOD Tracker player, I expect it to use the first style (MOD files are bundles of tone sequences and canned instrument data, so OpenCP already has the engine for that and will probably include canned generic instrument data for MIDI playing - MIDI files do not include instrument data themselves. Originally, OpenCP supported ISA SounBlaster, ESS688 and 1688, GUS and similar, in Windows also WSS and DirectX drivers. The current version uses TIMIDITY to "render" MIDI files: https://github.com/mywave82/opencubicplayer You could try whether it works better with MP3 or OGG, in case you have a problem with the rendering module. It can also play AdLib files and SID files and more :-) However, I do not see information about DOS ports there? Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/f
Re: [Freedos-user] USB serial & DOSBox
Hi! Have you tried using dosemu2? They have active development and support, so even if it does not work out of the box, they should still be able to give you advice on how to make it work :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] the freedos 1.3 floppy install edition.
Hi! The CPU detection utility used by the installer has compatibility issues with some processors. For example, there are some 486 systems that are detected as a 186. This has been a known issue for a while. Unfortunately, I just have not had the time to resolve that. As a stop gap, if the installer is told the system is less than a 386, it assumes it is incorrect and installs the 386 package set. So, there should be no need to override the detected CPU on 386+ systems. That will just break the complete install on pre-386 systems. If you insist on not trusting your tools, at least ASK the user whether they want to override the detection. Or better: If the tool detects a pre-386, make sure that you install an 8086 compatible kernel. You can still let the config/autoexec keep a boot menu item a la "if you are sure that your CPU can actually do it, select this item to try to load EMM386 and HIMEM at your own risk." For systems with less than a 386, you will want to override it to ensure the 8086 compatible kernel is installed. This should be the other way round. If you know what you are doing, you MAY override the detection result that you have no 386. If you do NOT know for sure, then the installer should NOT give you an install which would require 386. Of course if the INSTALLER is sure that the CPU is 386 or newer, the whole problem does not occur. So my proposal only annoys a small number of people with exotic 386+ CPU, but rescues all the users with actual 286 or older CPU or emulators from getting an un-usable install due to overly optimistic automated overrides. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Can FreeDOS Be Installed On A Logical Slice? The Answer Remains Unknown
Hi Jay! I tried to do the same thing with a logical slice of disk but FreeDOS failed to see it. If it is possible to install FreeDOS onto a logical slice of disk, inside of the extended slice, the technique for doing so is unknown, or, at least, unknown by me. DOS can not be installed on a logical partition, it has to be a primary partition. The problem is that the boot sector of a logical partition contains, as far as I remember, relative instead of absolute position information. So the boot sector code / program will fail to find the DOS kernel if booting from a logical partition. You will either have to use a primary partition, manually mess around with the boot sector without breaking other aspects of it, or use some type of boot manager which can load the kernel in some other way. You could even use a virtual floppy image with the help of GRUB or LILO and MEMDISK, I guess. FreeDOS in general has no problems with C: being a non-primay partition as far as I know, and it supports fdconfig.sys or config.sys pointing to the bulk of the DOS system on other drives than C: However: If you cannot load the kernel, DOS will be a lot less useful and at least your fdconfig.sys and some type of driver which makes it able to access other drives also have to be on a FAT formatted C: drive. In theory, you could load a virtual boot floppy with NTFS drivers, kernel and config sys and then install the rest of FreeDOS even on a NTFS drive, but that would involve significant manual trickery. Long story short, you could try the virtual boot floppy method and I recommend that your DOS drive is FAT, but I think a LOGICAL FAT partition could be good enough AFTER you boot from virtual floppy. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] gitlab change notifications lack commit messages
Hi! Today I have gotten more than 60 notifications about packet updates, NONE of which mentioned why the affected package got updated. I would REALLY like those notifications to include more details and metadata. This would also allow looking up update details in the archives later. In this context I remember that this is a bug in some sort of an automated package update script: It lacks the feature to pass ANY information about the update reason, so there is none. But this would be valuable information, so please improve that process :-) Thank you! Regards, Eric PS: Below is an example of an update notification, current style. A new Release v6.00a for unzip was published. Visit the Releases page to read more about it: https://gitlab.com/FreeDOS/archiver/unzip/-/releases Assets: - unzip - v6.00a for FreeDOS: https://gitlab.com/FreeDOS/archiver/unzip/-/jobs/4679018030/artifacts/file/package/unzip.zip - Download zip: https://gitlab.com/FreeDOS/archiver/unzip/-/archive/v6.00a/unzip-v6.00a.zip - Download tar.gz: https://gitlab.com/FreeDOS/archiver/unzip/-/archive/v6.00a/unzip-v6.00a.tar.gz - Download tar.bz2: https://gitlab.com/FreeDOS/archiver/unzip/-/archive/v6.00a/unzip-v6.00a.tar.bz2 - Download tar: https://gitlab.com/FreeDOS/archiver/unzip/-/archive/v6.00a/unzip-v6.00a.tar Release notes: Created using the release-cli (the linked release website does not provide ANY details either) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Confusing details about SET and redirection in FreeCOM
Hi! To bump this thread and wish FreeDOS a happy birthday, I would like to point out that this: >set "KEY=value|dir >echo %"KEY% ... will run the DIR command! may be an instance of the 5th most dangerous software weakness: https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html Regards and happy anniversary, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Unicode and codepages in apps already bundled with FreeDOS?
Hi all, as part of a mail with Vacek, I made a list of apps from https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html which MIGHT have some sort of Unicode and codepage awareness: By that, I mean that those apps can process input and/or output which are encoded using Unicode or some codepage and then show or otherwise process it either in Unicode or using the current codepage (which could get autodetected), or graphically, maybe including a custom non-codepage font. It surprises me that there are more than 30 suspects, but only a fraction of those will ACTUALLY have the features I hope them to have. Maybe you can help me to make the list more exact :-) HTMLHELP shows input (HTML with Unicode and entity support) using awareness of which chars exist in the current codepage. DN2 (DOS Navigator file manager, Ritlabs and Necromancer forks) may be able to handle file names or view files beyond simple "treat as 8-bit, assume it fits codepage". Same for the DOSZIP file manager and PGME (which even comes with fonts, I think). The SQLITE database engine may still contain Unicode support even though it may be of limited use in DOS. Like file managers, some archivers may be aware of filenames supporting encodings beyond the current codepage: 7ZIP just distinguishes DOS, WIN and UTF, whatever that means. 7ZDEC may just assume that Unicode chars 0 to 255 are your codepage? CABEXTRACT seems to rely on ICONV for Unicode? ZIP and UNZIP may or may not support encodings in their Infozip DOS ports? I do not expect any of the other archivers to ponder encodings. Some of the larger programming languages, often ports using 32-bit compilers for DOS, could support Unicode in some way: DOJS (JavaScript), Euphoria, FreeBASIC (FBC), FreePascal (FPC), Lua, Regina Rexx, Perl, OpenWatcom C, OpenWatcom Fortran maybe? I suspect filesystem drivers to have Unicode or codepage awareness, suspects are: DOSLFN, LFNDOS, NTFS, USBDOX :-) Among text editors, MinEd seems to be as Unicode- and codepage- aware as HTMLHELP: http://towo.net/mined/term-dos.png Blocek even comes with a graphical Unicode font. SETEDIT, ELVIS and VIM are powerful enough to possibly support various encodings? The FOXTYPE viewer explicitly supports Unicode. GNUCHCP is a bit of an alternative to the DISPLAY/MODE/CPI font ecosystem. UNRTF converts RTF to other text formats. Likewise, internet apps such as Arachne, Dillo, Lynx, Links, SSHDOS and SSH2DOS could support Unicode and other encodings? Media player MPLAYER probably does, too. Maybe also OPENCP? Last but not least, the OPENGEM GUI distro could contain encoding-aware apps or infrastructure? What are your thoughts? There might be more Unicode in FreeDOS than I had intuitively expected. Even when support is minimal, it would be cool to know that multiple apps grasp the concept of, say, UTF-8 and codepages being able to show a tiny subset of Unicode space and that a few apps even come with fonts with far more than 256 different chars already :-) Thanks for your insights! Regards, Eric PS: For all things NOT mentioned above, I expect no support for Unicode or conversions at all. I expect those to just assume an 8-bit encoding in text (and file names) matching your codepage. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Confusing details about SET and redirection in FreeCOM
Hi fellow users :-) I have been wondering which chars are special in SET in FreeCOM and whether they can be escaped or similar. As with most DOS commands, < | > are normally special. Any other characters which tend to be special in shells seem to be okay in SET. So far for the good news. But: You can do SET KEY=VALUE as expected as long as none of the 3 special chars are in there. You can also use double quotes in surprising ways: SET KEY="VALUE allows you to use any character in the value, but the double quotes will become part of the value. You do not need closing quotes and you can use more quotes anywhere in the value. SET "KEY=VALUE however is sort of evil, check this: >SET "KEY=valuebar|stuff >echo %KEY% ECHO is on >echo "%KEY% ECHO is on >echo %"KEY% Cannot redirect input from file "foo" >SET | tail -1 "KEY=valuebar|stuff >set "KEY=value|dir >echo %"KEY% ... will run the DIR command! I guess you can use this either as a feature or as a nasty security hole. Again, you can safely use >set KEY="value|dir >echo %key% "value|dir but that will always have the " as a part of the value. Are there other ways to deal with < | > in SET commands and then use the values in ECHO and other commands? Regards, Eric PS: Tests done in DOSEMU2, but with classic FreeCOM installed: C:\>ver /r FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:32:15] DOS Version 6.22 FreeDOS kernel build 2038 [version May 16, 2009 compiled May 16 2009] ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installation with Grub already installed
Hi! If I understand you correctly, Windows XP is NOT on that FAT partition, so every OS already has a separate partition? In that case the answer for MANUAL install would be: Simply skip the FDISK and FORMAT steps, it is enough to use SYS to make the FAT partition bootable. If your XP also has a FAT partition, make sure to not apply DOS SYS to the XP drive. The problem is that I do not know what the AUTOMATED install will do. Whether there is a risk that it would run FDISK or FORMAT without your consent? That question can be answered by others who are more familiar with the workflow. Regarding GRUB, you can use the Linux update-grub tool or grub-mkconfig to refresh the boot menu configuration after you have done the SYS step. It will detect DOS on the FAT partition and add a boot menu item for that :-) Then you can reboot, select booting DOS, and proceed with the remaining steps of installing DOS, if you have some DOS installation steps left to do after SYS. Regards, Eric Hi there I would like to install FreeDos 1.3 on my hard drive. I have Windows XP and Lubuntu 18.04 installed, both bootable from the Grub boot manager. The first partition is FAT and 2G in size and where I would like to install FreeDos. Is it possible to install FreeDos without destroying Grub and the current installation and how would I do this? Thanks John Ritchie ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Question about xFDisk and a multiboot setup
Hi Gabriele, Hi Eric I have partition magic for dos this can create partition for freedos? I guess it can, given that it is a partition editor :-) I do not know whether the DOS version can create LBA partitions or FAT32 partitions, so if this is an old DOS software, it may be better to use modern tools such as GPARTED for Linux or something similar for Windows or maybe even a tool shipping with FreeDOS? In any case, it should not make much difference for the multiboot question. For that, the trick will be to sort partitions in a way that each OS calls their own partition C: because the partitions of the other OS either are in formats not supported by the OS, for example FAT32 will be invisible to MS DOS 6.22, or are after the own partition of the OS. And you should make sure that installing one OS does not format or otherwise damage the partition of another. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Question about xFDisk and a multiboot setup
Hi! Let me get a bit more verbose in my installation thoughts. If you want to hide FreeDOS and MS DOS from each other, at least a bit, you could use filesystem choice for that: Install Linux on a Linux filesystem. Install XP on some NTFS filesystem. Install FreeDOS on a FAT32 filesystem. Install MS DOS on a FAT16 filesystem. By putting them in an appropriate order, XP can be C: while it sees the other 2 DOS versions as D: and E: and FreeDOS can be C: while seeing MS DOS as D: and last but not least MS DOS can be C: while not using any other partitions. Be aware that MS DOS can only use CHS partitions within the first 8 GB of the drive. Regarding the boot menu question, you can manually edit the GRUB menu.lst file after letting whatever automatic menu.lst generation offered by your Linux distro create entries for Linux, XP and MS DOS. This would let you add a FreeDOS entry when MS DOS and FreeDOS share the same partition. For that, you would manually run the FreeDOS SYS, after booting MS DOS, in the special style SYS C: freedos.bin bootonly this will create a freedos.bin boot sector file. You then copy the menu.lst section about MS DOS, but edit the "chainloader +1" line and make that something like "chainloader (hd0,1)/freedos.bin" if (hd0,1) would be your MS DOS partition. But given that you want 4 separate partitions for your 4 operating systems anyway, you can let the automatic menu.lst generation of GRUB do EVERYTHING, without the need for special SYS commands or manual menu.lst edits if you make sure that the 4 partitions all use different filesystem types :-) I recommend that you start by installing XP, because it is more likely to damage existing installs of other OS. Next, install Linux. Depending on the distro, it will provide a wizard to install a dual-boot which keeps XP working and gives you a boot menu. Add one FAT32 and one FAT16 primary partition either during this step or later, using a graphical Linux partitioning and formatting tool such as GPARTED. Boot MS DOS from a floppy or similar and install it manually to the FAT16 partition, without formatting or partitioning anything. Maybe you just use a boot disk and run SYS and copy some files, instead of running some automated installer at that point. Take similar steps for FreeDOS. I am not sure whether it will automatically skip formatting and partitioning, but do make sure to skip those. Also, make sure that your FAT32 partition is before the FAT16 one. That way the FAT32 partition will be C: and the MS DOS FAT16 partition will be D: for FreeDOS, while MS DOS will only see the FAT16 partition and call it C: :-) Boot Linux and let the GRUB menu.lst generator tool do magic to add menu entries for the two DOS partitions. I expect all DOS systems to require extra tricks if their boot partition is not a primary partition, but you can only have 4 primary partitions in total, or 3 if you also need additional non-primary partitions. In the latter case, I think you can boot at least Linux from non-primary partitions. Not sure about XP. You may have to tell Linux to install GRUB in the MBR, not in the boot sector of your Linux boot partition, for this to work. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Question about xFDisk and a multiboot setup
Hi! You could try metakern: FreeDOS SYS has command line options to write the boot sector to a file instead of to the boot sector. You can use either DEBUG or Linux or simple or fancy DOS tools of your choice to harvest the boot sectors of MS DOS and XP. If FreeDOS finds the file fdconfig.sys, it will use that and ignore config.sys, so you can tell FreeDOS to use a different command.com than MS DOS in the SHELL line, which you can also use to tell our freecom shell to use a different file instead of autoexec.bat :-) In short, you can use metakern as a boot menu to install FreeDOS and MS DOS on the SAME C: drive, both visible to each other. Of course it will take a bit of copying files around and making backups before one installer overwrites files of the other DOS, but as experienced DOS user, you can do it :-) You can also add XP to the equation if you manage to keep config files separate, but it is probably easier to install XP to a NTFS partition which both DOS versions will simply ignore. You can use for example your Linux boot manager to boot either Linux or XP or the DOS partition and then use metakern to boot either FreeDOS or MS DOS. Or even easier: Copy the harvested boot sectors of both MS DOS and FreeDOS to your Linux boot manager directory and manually add boot menu items for the two DOS versions directly to your Linux boot menu without using metakern. Regards, Eric I and trying to get a multiboot setup 1. MSDOS 6.22 + Win 3.11 2. FreeDos 1.3 3. I was going to do XP but annoying so no... 4. And a Older laptop friendly Linux that runs on XFCE... ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Interesting BTTR threads: hwinfo and astra, ranish with lba, fdisk bug fixes, soundcards
Hi! To forward some recent bookmarks for other DOS fans to enjoy, I would like to share some links to the DOS ain't dead BTTR forum: *Diagnostics software for DOS* https://www.bttr-software.de/forum/board_entry.php?id=16853&page=0&order=time&category=0 ASTRA 6.91: http://www.sysinfolab.com/ HWiNFO 6.2.2 by Martin Malik: https://www.hwinfo.com/download/ System Analyser by Hans Niekus https://sysanalyser.com/ (2011) NSSI https://www.navsoft.cz/products.htm (2010) In particular, ASTRA and HWiNFO are actively maintained and received several updates discussed in the BTTR thread :-) *FDISK 1.3.4 off-by-one CHS versus LBA bug and fixes for it* https://www.bttr-software.de/forum/board_entry.php?id=19762&page=0&order=time&category=0 This also links to https://gitlab.com/FreeDOS/base/fdisk/ Most recent conclusion is that if LBA is active in BIOS and FDISK and a partition ends on a cylinder boundary < 8 GB, then the end is wrongly rounded to the next cylinder. A similar bug exists for the end of the whole disk. *Ranish partition manager revived* https://www.bttr-software.de/forum/board_entry.php?id=19691&page=0&order=time&category=0 As the source code of Ranish Partition Manager is public domain now, https://codeberg.org/boeckmann/ is working on updated versions made with fresh compilers and with added LBA support. Cool news :-) *Soundcard emulation ponderings* https://www.bttr-software.de/forum/board_entry.php?id=19549&page=0&order=time&category=0 This thread discusses the possibilities for soundcard emulation on modern hardware. The original idea being vdmsound + hx dos. There are no code or working recipes there yet, but the thread could inspire others who want to dive into the possibilites. I suggest to change the subject when replying to one of the good news listed above, so we can discuss it in a separate freedos-user thread for clarity. But I hope it was okay for you that I bundled them all in this single "announcement", or overview email. Regards, Eric PS: Thanks for sharing the news about UPX 4.0.1, Jim! https://sourceforge.net/p/freedos/news/2022/12/upx-401-released/ Checking the milestone lists, this fixes FreePascal 3 compresssion (fixed in 3.99) etc., while many other updates are not DOS related. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
