[Freedos-devel] Network Associates Webshield - e-mail Content Alert
Network Associates WebShield SMTP V4.5 MR1a P0803.345 on av0011 intercepted a mail from <[EMAIL PROTECTED]> which caused the Content Filter *.pif to be triggered. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] PCI BIOS
On Fri, Oct 30, 2020 at 8:28 PM Eric Auer wrote: > > Also, you do not want to write a DOS driver for AC97 > or HDA sound, because sound drivers are not part of > DOS: They are part of the games and very few games > let you replace their sound drivers with your own. > Actually, there are actually quite a few DOS games that used sound drivers that you could replace, notably Miles (AIL), DIGIPAK/MIDPAK, etc. There is also the VBE/AI standard, which is an extension to he VESA VBE (int 10h) API to offer a hardware-indepenent audio interface. Unfortunately, this standard never gained any traction, since it arrived on the market too late (in 1994), but there are shims/wrappers available to allow VBE/AI drivers to be used by games that use AIL2 or DIGPAK/MIDPAK drivers. My goal has been to use Jeff Leyda's Intel ICHx AC'97 audio player code as a basis for developing an open source VESA VBE/AI sound driver that could be shipped with FreeDOS, as a way to kickstart the adoption of VBE/AI as "the" audio driver standard for FreeDOS, going forward. An audio driver standard has been on the FreeDOS wishlist for quite some time now: http://wiki.freedos.org/wiki/index.php/(Free)DOS_development_wishlist Anyway, if anybody would like to help me out with my driver, I would appreciate that. I'm still working on the first "phase", namely adding compatibility with more on-board AC'97 devices, before building a VBE/AI driver around it. Link to the project page: https://github.com/volkertb/ich2player If this successful, perhaps we can start developing a VBE/AI driver for Intel HDA (and compatible) devices, as well as other more modern and common sound devices. Speaking of VBE/AI, do any of you happen to know who has the source code of the released VBE/AI drivers (for Adlib, Sound Blaster, Pro Audio Spectrum and Disney Sound Source), and has the rights ro release them as open source? That way, we would start out with a list of already supported sound card and audio devices to ship with FreeDOS. ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] PCI BIOS
On Sat, Oct 31, 2020 at 4:43 PM Eric Auer wrote: > > While you are creating that very promising VBE/AI AC97 > driver, do you have a list of games which support that > interface or which support miles / ail / digipak / midipak > replaceable sound drivers or docs about the driver format? > > Thank you :-) Someone posted a fairly extensive list on the VOGONS forum here: https://www.vogons.org/viewtopic.php?f=24&t=39270&p=358631&hilit=bristlehog+miles#p357303 The list is grouped in sub-lists per modular audio driver standard. The first one, "*Audio Interface Library and MIDPAK - ADV drivers*", is the list of games that (at least in theory) can be made to work with VBE/AI, using the aforementioned shim/wrapper drivers. As you can see, it's quite an extensive list. I've successfully tested this with Dune II a while back. (NOTE: AIL2 and ADV are the same driver standard, both by John Miles of Miles Design.) Also, back in the '90s, I used the same trick to add Gravis Ultrasound support to games that didn't support that card out-of-the-box. Gravis actually made the Miles/AIL and DIGPAK/MIDPAK drivers available on their FTP site, so customers could "patch" existing games with those drivers themselves. Usually you'd have to replace the Sound Blaster (DAC) and General MIDI (music) drivers and then select those in the setup program. Although in the came of DIGPAK/MIDPAK, I think you could also just load the drivers before starting the game, since they were TSRs, not unlike how VBE/AI works. One current challenge is that I don't know who has the source code to the shim/wrapper drivers that allow those games to work with VBE/AI drivers. That's a shame, since it would be really nice to have those shipped with FreeDOS as well. John Miles released the source code to his AIL2 drivers years ago and you can still download them from his page, but unfortunately the VBE/AI shim/wrapper drivers aren't included in those sources. Those drivers were written a few years later. I emailed John Miles about it, and he was quick and friendly in his reply, but unfortunately he had no idea who wrote those drivers. I'm specifically talking about the source code to VESADIG.ADV and the VESAMID.ADV. My guess would be that someone at Media Vision wrote those driver, since thatś company was the main backer of the VBE/AI standard, obviously in an attempt to break Creative Lab's dominance over the DOS sound card market. The VBE/AI specification can be found in a PDF document on-line, and in one of the first pages it lists a committee of members from different companies who worked on this standard. I'm not sure what the status of that document is, since the VESA organization usually charges money for specification documents. On the other hand, this is a defunct standard, so that may not apply to this particular document. If anybody reading this happens to have any information on this topic (the VBE/AI standard in general, the source code of the wrapper drivers for other more popular DOS audio driver models, etc), please chime in! ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 1.3-rc3: should give meaningfull error message on AHCI (SATA) only system
Wouldn't that effort be better spent on actually adding AHCI support to UDVD2? One cool thing about AHCI is that it has considerably lower emulation overhead than legacy IDE. So that would be an additional argument in favor of adding full native AHCI support to FreeDOS. On Fri, Oct 30, 2020 at 4:56 PM Paul Dufresne via Freedos-devel < [email protected]> wrote: > If I had: '-M q35' to qemu to enable a SATA only machine, when booting in > live mode 1.3-rc3: > UDVD2: Nothing to use; UDVD2 not loaded. > I hope UDVD return an error code we could use to give a more meaninful > message like: > Your computer is running in SATA only mode, so I cannot access the CD-ROM. > You might try to see if your BIOS support Legacy IDE mode. > My newer BIOS does not have this compatibility option anymore, sadly. > I see: https://sourceforge.net/p/freedos/bugs/266/?limit=25 (about > this)... oh we do have bugs list, I should maybe use it more! > > If I boot with a normal PC to do the fdisk, then reboot in SATA only mode > and select install, installation will go until: > "Unable to locate the installation packages. > A reboot may help." > Maybe where "A reboot may help" should be replaced by: "Reboot, and try to > enable Legacy IDE mode in your BIOS before trying again." > > > > > ___ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Dreidl game
Aw, man. Now I have Kyle's Dreidl Song from that South Park holiday episode repeating in my head. 😅 Thanks for sharing this with the world. Can you double-check that link, though? It's giving me a 404. On Tue, Oct 27, 2020 at 11:16 PM Jim Hall wrote: > It's kind of early for Hanukkah, but a friend suggested a little dreidl > game. It looked easy to do, so I wrote it. This is a VERY SIMPLE dreidl > game. > > The rules are in the dreidl.c file. This is under the GNU GPL v2. > http://www.freedos.org/jhall/dreidl/ > > I wrote it on Linux but it should compile under FreeDOS just fine. It's > not doing anything weird. I might later update it to support DOS conio or > DOS graphics mode or Linux ncurses, but right now it's just using puts() > and printf(). The code has a few "stubbed in" functions that I'll use later > to support graphics mode. > > If you know the dreidl game, you know this is basically a simulator, so > it's not really a game. More than anything, this is probably a demo about > writing a simple program. You spin the dreidl, and you automatically do > stuff based on the spin that comes up. > > Jim > ___ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] GEMMIS support in JEMM386 for FD 1.3? (for Win3.1 and Win9x compatibility)
Hi, Is Japeth the only one maintaining JEMM386? A few months ago, I opened a feature request to have support for GEMMIS added to JEMM386: https://github.com/Baron-von-Riedesel/Jemm/issues/5 GEMMIS stands for *Global EMM Import Specification* and is a mechanism for handing over memory management control from EMM managers such as EMM386 and QEMM386 to Windows, allowing Windows 3.1 to run in 386 Enhanced mode even if a supported EMM manager is loaded. Even Windows 95/98/Me can be started from DOS using the same mechanism. Unfortunately, JEMM386 currently lacks this support, so Windows 3.1/9x can only be started from FreeDOS when JEMM386 isn't loaded. It would be great if this limitation could be removed. DOSBox has integrated support for GEMMIS, so perhaps some code could be copied from there to implement this in JEMM386. Is it too late to push for this feature to be delivered as part of FreeDOS 1.3? And could other experienced DOS/assembly developers perhaps work on this as well, or are we completely dependent on a single developer for this? I understand that I may be underestimating the level of complexity involved in adding this feature. But FreeDOS releases don't happen often, so it would be nice to have this included with 1.3. Thanks for considering this. ☺ _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: GEMMIS support in JEMM386 for FD 1.3? (for Win3.1 and Win9x compatibility)
(Sorry for posting it to freedos-users earlier as well, I should have posted this question here directly.) Hi, Is Japeth the only one maintaining JEMM386? A few months ago, I opened a feature request to have support for GEMMIS added to JEMM386: https://github.com/Baron-von-Riedesel/Jemm/issues/5 GEMMIS stands for *Global EMM Import Specification* and is a mechanism for handing over memory management control from EMM managers such as EMM386 and QEMM386 to Windows, allowing Windows 3.1 to run in 386 Enhanced mode even if a supported EMM manager is loaded. Even Windows 95/98/Me can be started from DOS using the same mechanism. Unfortunately, JEMM386 currently lacks this support, so Windows 3.1/9x can only be started from FreeDOS when JEMM386 isn't loaded. It would be great if this limitation could be removed. DOSBox has integrated support for GEMMIS, so perhaps some code could be copied from there to implement this in JEMM386. Is it too late to push for this feature to be delivered as part of FreeDOS 1.3? And could other experienced DOS/assembly developers perhaps work on this as well, or are we completely dependent on a single developer for this? I understand that I may be underestimating the level of complexity involved in adding this feature. But FreeDOS releases don't happen often, so it would be nice to have this included with 1.3. Thanks for considering this. ☺ _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Introduction and Help in OS dev, FreeDOS
Hi Everyone, I am Aniket, I know C but I didn't make any meaningful project in it. As I saw a video playlist from Jim Hall, based on C programming language, I thought I will refresh my knowledge by watching it and then help or contribute in FreeDOS development. In this way I can solidify my knowledge regarding C as well as I will dive into OS dev. But the main concern is what are the prerequisites I should be familiar with? Like shall I read Minix book etc. or something like that to get into OS dev? Or shall I start hacking without any prior knowledge and eventually pick up the stuff while building something? Also in what way I can contribute to FreeDOS with my existing knowledge? Please let me know. Regards, Aniket Patil Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS runtime library format
> Was there ever any "official" format for a shared runtime library under > MS-DOS? > ... > Any constructive feedback would be appreciated! :D > Here is no any standard. I can purpose few way: Experimental library format in msa2 - https://github.com/DosWorld/msa2/tree/master/original/examples/OVL-TP7 Way, described into Turbo Pascal 3. Here is example, how to use GRAPH.BIN library (from TP3) into other languages. Imho, here is no problem link it static or dynamic. https://github.com/DosWorld/pl2/blob/main/EXAMPLES/TP3GDEMO.PL2 https://github.com/DosWorld/pl2/blob/main/LIB/TP3GRAPH.PL2 Also, we have BGI - this is about graphics, but it is shared library. And next way - "everything is a file" (this is unix way) - write library as device driver (.sys) One more - load unix a.out format (it is easy and well documented). And last way, (more hard) - dynamic loading .obj file. .obj contains all required info. ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Adopting the DIGPAK sound driver sources for inclusion in FreeDOS
Hello FreeDOS developers, For quite a few years, DOS drivers for sound cards have been on the FreeDOS development wishlist <http://wiki.freedos.org/wiki/index.php/(Free)DOS_development_wishlist>. I've had a conversation with John W. Ratcliff, who as many of you know used to develop and maintain the DIGPAK and MIDPAK sound drivers under the company name "The Audio Solution". The DIGPAK driver model has been used in many DOS games back in the '90s and has a well-documented API, which can be accessed from most popular programming languages, as well as from assembly language through Interrupt 66h calls. There are DIGPAK drivers for many different sound cards, including all the popular ones, as well as a number of more obscure ones. A little known bonus feature of DIGPAK drivers is that they can also be used as drop-in replacements for Miles Design AIL2 (ADV) drivers, as a result of a cooperation between John Ratcliff and John Miles. John Ratcliff has given his blessing for people to freely use the source code of his DIGPAK drivers. He told us that "we can do anything we want with it", although he did add the caveat that the sources of some of the drivers contain third party code that was contributed by various sound card manufacturers, and that he did not own the rights to those specific portions of the source code. He specifically mentioned Creative Labs. Also, he made it clear that he was completely disinterested in any further cooperation or involvement w.r.t. further maintenance and development of this DOS era source code. Naturally, I respect that. Personally, I think it would be great to have FreeDOS bundle at least the DIGPAK drivers that are free of such third party sources, as well as to use the DIGPAK driver model as a standard and basis from which to develop drivers for more modern sound devices. Not only can they be used to develop new DOS games and other DOS software with support for newer sound devices, but support for such newer devices could be patched into older games that already rely on DIGPAK or AIL2 drivers. And the list of such games is actually a lot higher than many people may realize. Now most of the third party companies (aside from Creative Labs) of which there are copyrighted portions in the existing DIGPAK driver sources are defunct: Media Vision and Advanced Graphics and Forte Technologies. Turtle Beach and Creative Labs still exist as companies of course. If the FreeDOS developers and maintainers are indeed interested in adopting the DIGPAK sources, there are a few options we can consider: - Adopt and bundle only the sources of drivers deemed safe: Covox Speech Thing, Disney Sound Source, the NOSOUND dummy driver, the VBE/AI wrapper driver, and the Microsoft Windows Sound System driver (since that is an open sound card specification anyway, and Microsoft is quite open source friendly these days) - Adopt and bundle the sources of the above "safe" drivers *plus* the sources containing third party code of companies that no longer exist - Adopt and bundle all of the sources, assuming that no company will bother coming after us for such obsolete and niche source code One third party contributor to the DIGPAK drivers is John Miles, who not only has already released the source code to his AIL2 drivers years ago, but recently also explicitly gave his blessing for the release of any of his contributions to John Ratcliff's DIGPAK drivers. One additional thing to bear in mind is that the drivers are written in the TASM Ideal mode assembly language dialect. That means that some work would have to be done to port the source code to open source assemblers (NASM, FASM, WASM, JWASM, etc). What do you all think? Can FreeDOS adopt these drivers and include them in the distribution? And perhaps some of you know people who have worked (or currently work) at some of these sound card companies, and could vouch for the release of the drivers that partly contain code from those companies? I really hope we can give the DIGPAK drivers a new home within the FreeDOS project! Not just to solve the current lack of any hardware-independent sound support, but also to preserve this source code for its historic significance. Thank you all for your input on this matter. ☺ ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] digipak drivers
Hi Eric, I searched for copyright notices in the code and this is what I found: Copyright notices we don't have to worry about: - ✔️ The Audio Solution -> John W. Ratcliff himself, who has given permission to "do whatever we want" with his code - ✔️ Miles Design, Inc. -> John Miles, who has also permission for his AIL2 code and DIGPAK/MIDPAK contributions to be used freely Copyright notices that are probably not problematic (although IANAL): - ❓VESA, Inc -> VBE/AI specification and SDK, can now freely be downloaded from VESA (upon free registration) Copyright notices of now defunct companies, the rights of which could still be in the hands of other companies: - ⚠️Media Vision -> out of business, not sure what company (if any) would own the IP to their DIGPAK contributions - ⚠️Forte Technologies -> Gravis Ultrasound SDK files, no redistribution permitted, but where is Forte Technologies now? Copyright notices and possible IP from companies that still exist: - ⚠️Turtle Beach Systems -> company still exists - ⚠️Missing from any copyright notices is Creative Labs, although John Ratcliff explicitly mentioned receiving code contributions from them, which he explicitly does not claim ownership (or sublicensing rights) to. Copyright notices from other contributors: - ⚠️Scott E. Sindorf -> contributed a secondary screen debugger and some tweaks to the Sound Blaster driver code So if we wanted to be safe, we would have to leave out the source code for the following drivers and tools: - ⚠️all the Sound Blaster and compatible drivers (including the Sound Blaster Clone and Media Vision Thunderboard drivers) - ⚠️all of the Media Vision drivers (Pro Audio Spectrum) - ⚠️all of the Turtle Beach drivers (such as the Multisound, not sure if there are others from this company) - ⚠️The Gravis Ultrasound (GF166) driver - ⚠️The secondary screen debugger (it's a separate single file that doesn't seem to be included by any of the other sources) The rest I'm not so worried about. We could inquire with VESA if they are okay with the VESA AI Include file (with service definitions and such, but no source code) could be included with these sources. I think it's highly unlikely that they were to object to that, since it's an obsolete standard that sadly didn't even gain seriou adoption back in the day. Here's the thing with all these drivers, though: most of them (except for the Gravis Ultrasound driver, the Turtle Beach drivers and the later Sound Blaster model drivers) are built from a single assembly source file, with all the device-specific parts placed inside IFDEF statements. So I think a practical approach would be to write a script that would filter out the potentially legally problematic driver code by their device-specific IFDEFs, before publishing the resulting sanitized code on GitHub. We could then worry about porting the remaining drivers to another assembler dialect later. What do you guys think? On Sat, Feb 13, 2021 at 9:22 PM Eric Auer wrote: > > Hi Volkert, > > if you ask me, unless you can convince Creative otherwise, > we should really omit any third party sources in that digipak > driver source code release. Any other third parties involved? > > I remember that there is a NoMySo (not my source) script to > convert ASM sources to more free dialects, you could try how > well that works on digipak sources :-) I am not sure whether > it has TASM, MASM or both as input. Output was NASM or JWASM > as far as I remember. > > Regards, Eric > > PS: Feel free to reply as part of the freedos-devel thread. > > ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS as a unikernel?
Yep, you pretty much described the dosemu2, which was already mentioned here. Itś a continuation of the old DOSEMU project. The original DOSEMU relied on the V8086 virtualization mode that was introduced in the 386 CPU, but V8086 mode isn't available in 64-bit (Long) mode. So instead, dosemu2 (optionally) leverages KVM, the hardware-assisted hypervisor in built into the Linux kernel, to virtualize a DOS environment. And yes, it can emulate Sound Blaster cards as well. By the way, the dosemu2 developers are also developing fdpp, a 64-bit DOS kernel that aims to provide a DOS-compatible userspace and that can run in Dosemu2. (Not sure if it always uses fdpp by default.) Since it's a 64-bit process, I'm not sure how fdpp and dosemu2 handle the running of 16-bit code without some kind of software emulation. But regardless, they run on Linux and leverage its virtualization features. On Wed, Mar 3, 2021 at 1:24 AM Liam Proven wrote: > On 3/1/2021 10:42 AM, Pablo Pessolani wrote: > > > > Hi Guys. > > I am working on several unikernels on Linux (not over QEMU, KVM, > XEN or any other emulator/hypervisor) using Linux system calls and the > virtualization facilities offered by the Linux kernel. > > Would there be any interest in modifying freedos so that it can run > on Linux and its virtual devices instead of running on real hardware (as > User Mode Linux does) ? > > Are you aware of DOSemu? > > https://en.wikipedia.org/wiki/DOSEMU > > V1 is in most distros' repositories. > > V2 is in development. > http://dosemu2.github.io/dosemu2/ > > Most DOSes run under it, and the Ubuntu version comes bundled with FreeDOS. > > It is in essence a FOSS version of Locus DOS/Merge, which I was using > in the late 1980s. > https://en.wikipedia.org/wiki/Merge_(software) > > -- > Liam Proven – Profile: https://about.me/liamproven > Email: [email protected] – gMail/gTalk/gHangouts: [email protected] > Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven > UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 > > > ___________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] VBE/AI SDK released on GitHub, to celebrate the Google vs. Oracle SCOTUS decision 🥳
Hi everyone! Thank Goodness the US Supreme Court ruled in favor of common sense today. The copying of APIs for the purpose of implementation in original work is considered Fair Use! 🥳 Also today, as coincidence would have it, someone at VESA responded to my inquiry on the current legal status of the VBE/AI SDK that has been floating around the internet. Their response was that VESA no longer supports VBE/AI and that it is in the public domain, and that we are free to do with the sources whatever we want. ☺️ I therefore unpacked the ZIP file from cd.textfiles.com and published it to GitHub, with the exception of one subfolder: MIDI/OPL2/TOOLS/. The repo can be found at https://github.com/volkertb/vbe-ai-sdk The reason why I left that one subfolder out of the repository is because it contained files copyrighted by The Fat Man, with non-free terms of use. Specifically, those are thimbres for OPL2 and OPL3 FM synthesizer chips as found in many sound cards back in the '90s. I've emailed George Sanger (a.k.a. "The Fat Man") with the question of whether he would be open to releasing those files as open source. If he agrees, I'll add that subfolder to the repository in a later commit. However, those files shouldn't be required when you're writing new VBE/AI sound drivers. As far as I understand it, you might only need those thimbres when you want to support the VBE/AI Adlib driver in your game and have a properly sounding instrument mapping when your game music is composed according to the General MIDI specification. But I digress. I also added the VBE/AI 1.0 specification document in PDF format <https://github.com/volkertb/vbe-ai-sdk/blob/main/VBEAI100.pdf> to the repository, so it's a one-stop shop for anybody here who'd like to take a stab at writing standard open source DOS audio drivers and/or applications/games making use of such drivers. The SDK also contains some existing VBE/AI drivers for Sound Blaster, Adlib, Disney Sound Source and MPU-401 MIDI. Those are binary-only, however. But if those are now public domain as well, perhaps we'll be able to reverse-engineer the COM files using something like Ghidra. (I've asked this in a follow-up question to VESA. I'll let you know if I get a more specific answer on that as well.) I hope all of this will be a useful piece of the puzzle w.r.t. scratching off the "*Drivers for modern, unsupported hardware*" item from the (Free)DOS development wishlist <http://wiki.freedos.org/wiki/index.php/(Free)DOS_development_wishlist>. ☺️ I've been working on the development of a VBE/AI driver for Intel ICHx AC'97 devices in my spare time, but I'm not very experienced in low level assembly and C development, so progress has been slow. Any help is welcome, though! 😃 It would be nice to see VBE/AI drivers for modern sound devices such as these: - AC'97/ICHx (like what I've been working on) - Intel HD Audio - USB Audio - VirtIO (paravirtualized) Sound Driver <http://VirtIO Sound Driver> - Popular PCI sound cards (SB Live, Audigy, etc) - OPL2LPT/OPL3LPT - MIDI over RS-232 - Some other cool stuff that I'm undoubtedly missing here Note that the VBE/AI sources currently include the "far pascal" keyword that gcc-ia16 doesn't support yet. That's being looked into, though. <https://github.com/tkchia/gcc-ia16/issues/45#issuecomment-812819327> (Help with that is welcome too, of course!) Anyway, I hope this is useful to at least some of you. have a great day/evening/night, everyone! 🤗 Volkert _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] VBE/AI SDK released on GitHub, to celebrate the Google vs. Oracle SCOTUS decision 🥳
A follow-up to my previous announcement: I got a reply from The Fat Man, and he graciously allowed free use of his FM timbres, on the condition that his copyright notice is included in any software in which they are included. Seems very reasonable to me. ☺️ I therefore added the MIDI/OPL2/TOOLS/ folder that I left out earlier, and added a LICENSE.md file that contains the copyright notice that he proposed. The FM timbres are useful when you are developing a DOS game for which you have music assets in General MIDI format, but you also want to support sound cards or sound devices with OPL2/OPL3 FM synthesizer chips, such as Adlib, Sound Blaster, etc. A similar mapper for the Roland MT32 synthesizer appears to be included in the VBE/AI SDK as well, but I'm not sure if that is also developed by The Fat Man. Again, I hope any of this is useful in some way to you retro DOS game developers out there. 😃 By the way, we could use some help "porting" the C/C++ code in the VBE/AI SDK so that it can be compiled by Open Watcom. Right now, the code contains "far pascal" keywords, which unfortunately are specific to Borland (Turbo) C/C++. Here's a link to the GitHub repo again: https://github.com/volkertb/vbe-ai-sdk On Mon, Apr 5, 2021 at 10:23 PM Volkert wrote: > Hi everyone! > > Thank Goodness the US Supreme Court ruled in favor of common sense today. > The copying of APIs for the purpose of implementation in original work is > considered Fair Use! 🥳 > > Also today, as coincidence would have it, someone at VESA responded to my > inquiry on the current legal status of the VBE/AI SDK that has been > floating around the internet. Their response was that VESA no longer > supports VBE/AI and that it is in the public domain, and that we are free > to do with the sources whatever we want. ☺️ > > I therefore unpacked the ZIP file from cd.textfiles.com and published it > to GitHub, with the exception of one subfolder: MIDI/OPL2/TOOLS/. > > The repo can be found at https://github.com/volkertb/vbe-ai-sdk > > The reason why I left that one subfolder out of the repository is because > it contained files copyrighted by The Fat Man, with non-free terms of use. > Specifically, those are thimbres for OPL2 and OPL3 FM synthesizer chips as > found in many sound cards back in the '90s. > > I've emailed George Sanger (a.k.a. "The Fat Man") with the question of > whether he would be open to releasing those files as open source. If he > agrees, I'll add that subfolder to the repository in a later commit. > However, those files shouldn't be required when you're writing new VBE/AI > sound drivers. As far as I understand it, you might only need those > thimbres when you want to support the VBE/AI Adlib driver in your game and > have a properly sounding instrument mapping when your game music is > composed according to the General MIDI specification. But I digress. > > I also added the VBE/AI 1.0 specification document in PDF format > <https://github.com/volkertb/vbe-ai-sdk/blob/main/VBEAI100.pdf> to the > repository, so it's a one-stop shop for anybody here who'd like to take a > stab at writing standard open source DOS audio drivers and/or > applications/games making use of such drivers. > > The SDK also contains some existing VBE/AI drivers for Sound Blaster, > Adlib, Disney Sound Source and MPU-401 MIDI. Those are binary-only, > however. But if those are now public domain as well, perhaps we'll be able > to reverse-engineer the COM files using something like Ghidra. (I've asked > this in a follow-up question to VESA. I'll let you know if I get a more > specific answer on that as well.) > > I hope all of this will be a useful piece of the puzzle w.r.t. scratching > off the "*Drivers for modern, unsupported hardware*" item from the (Free)DOS > development wishlist > <http://wiki.freedos.org/wiki/index.php/(Free)DOS_development_wishlist> > . ☺️ > > I've been working on the development of a VBE/AI driver for Intel ICHx > AC'97 devices in my spare time, but I'm not very experienced in low level > assembly and C development, so progress has been slow. Any help is welcome, > though! 😃 > > It would be nice to see VBE/AI drivers for modern sound devices such as > these: > >- AC'97/ICHx (like what I've been working on) >- Intel HD Audio >- USB Audio >- VirtIO (paravirtualized) Sound Driver >- Popular PCI sound cards (SB Live, Audigy, etc) >- OPL2LPT/OPL3LPT >- MIDI over RS-232 >- Some other cool stuff that I'm undoubtedly missing here > > Note that the VBE/AI sources currently include the "far pascal" keyword > that gcc-ia16 doesn't support yet
Re: [Freedos-devel] video FreeDOS running Windows 3.1
Great work Jeremy! 😃 Watching your YouTube video, I noticed the FreeDOS VM booting with Microsoft EMM386. And that makes sense, since JEMM386 currently doesn't support GEMMIS, a standard required for by Win3.x and Win9x for memory management handover from the EMM manager to the Windows kernel as it starts up from DOS. (That's necessary when you want to start Windows 3.x in 386 Enhanced mode while having an EMM manager loaded.) There is an outstanding feature request for GEMMIS in JEMM, but the JEMM maintainer has expressed a disinterest in adding such support: https://github.com/Baron-von-Riedesel/Jemm/issues/5 That's unfortunate, since GEMMIS support in JEMM, in addition to Jeremy's FreeDOS kernel patch, would result in full support for Windows 3.x (and even Win9x) by the FreeDOS distribution. Would any other developer here with the necessary expertise be willing to work on GEMMIS support in JEMM? Or perhaps on adding GEMMIS to another open source EMM386 alternative? For instance, wasn't there an older EMM386 alternative that used to ship with FreeDOS before it was replaced with JEMM? Apparently, there is a GEMMIS implementation integrated in DOSBox, so this code could perhaps be copied or used as an example, when implementing GEMMIS in JEMM or in another open source EMM386 alternative. And in addition to that, another question for Jeremy: I also noticed how that DOS window within Windows 3.11 still seemed to "boot" an instance of MS-DOS as opposed to FreeDOS. Would it be possible to have the DOS windows inside Windows launch FreeDOS instead as well? Or would that require patching Windows itself? Thanks again! On Sat, Jul 24, 2021 at 12:43 PM Eric Auer wrote: > > Hi Jeremy, > > does that mean the unstable kernel already supported Win 3.1 386enh? > > Cool to know :-) How about Windows for Workgroups in 386 mode, which > is "non safe mode" there, so features are lost without it in WfW 3.11? > > Thanks for cherry-picking all the relevant patches! I guess the FDPP > kernel of DOSEMU2 will have some more of those for you ;-) > > Checking your video, it says kernel 2043 build Jul 24 2021, > but the copyright messages says 1995-2012, probably a typo. > > Do you have a link to the relevant patchsets for proof-reading > in case there is a risk of regressions? > > I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft > EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually > necessary? I would expect things to also work with HIMEMX or XMGR, > as long as no free EMM386 is loaded at all? Why do you use 4DOS in > the DOS window inside Windows? Any special system.ini [386enh] items? > See my notes below :-) Is setting VERSION=6.0 required, too? > > Cool that WIN, WIN /3 and WIN /S apparently all work :-) > > Some custom (un-)settings from an old system.ini [386enh] of mine: > > ; device=lanman10.386 > ; mouse=lvmd.386 > ; network=*dosnet,*vnetbios > ; old version: device=*vtd new version: device=vtda.386 (in "WW0981" fix) > device=vtda.386 > FileSysChange=0 > PagingFile=C:\WINDOWS\WIN386.SWP > MaxPagingFileSize=1024 > ; also: PermSwapDOSDrive=... PermSwapSizeK=... > ; disable swapfile stuff: > Paging=0 > ; prepare for more than 200 breakpoints, 150 is minimum useful: > MaxBPs=768 > ; better if lots of RAM: > PageOverCommit=1 > ; equivalent of /D:FSVX > 32BitDiskAccess=No > SystemROMBreakPoint=No > VirtualHDIrq=No > ; *** EMMEXclude=A000- > NoEmmDriver=1 > IgnoreInstalledEMM=1 > WinExclusive=1 > ; > TimerCriticalSection=1 > DMABufferSize=64 > XlatBufferSize=128 > KeyBoostTime=.005 > MinUserDiskSpace=5120 > PageBuffer=32 > Com1Buffer=512 > ComBoostTime=20 > Com1AutoAssign=-1 > ScreenLines=50 > ; > InDOSPolling=1 > ; P.V.F.: 10, or 0 if share installed > PerVMFILES=0 > ReflectDosInt2a=1 > INT28Critical=1 > ; I.V.W.U.T.: 1/2/4/*8*... seconds: how often to pump int 8/1c into idle > VMs > IdleVMWakeUpTime=1 > ; D.P.E.I.: enable to get explanation how to leave DOS box when starting > one > DOSPromptExitInstruc=0 > ; force DMA buffers to be in 1st 1MB range: > DMABufferIn1MB=1 > > For standard mode, I also had those settings: > > [standard] > ; Stacks=12 (8..64) StackSize=384 - Settings for DOSX DOS Extender > ; Int28Filter=0,1..*10*..: only let through every Nth int 28 ... > Stacks=16 > StackSize=512 > Int28Filter=1 > DOSPromptExitInstruc=0 > > Note that Windows 3.x all have issues when you have too much > RAM. There are binary patch files for that, but the obvious > other workaround is telling your EMM386 or HIMEM or similar > to not let Windows know how much RAM you really have ;-) > > Cheers, Eric > > > https://youtu.be/35OQjLYdvJ0 > >
Re: [Freedos-devel] video FreeDOS running Windows 3.1
> > I think Windows' 386 mode is pretty heavily tied into undocumented > features of EMM386 when it is active, so it wouldn't surprise me if a free > version of EMM386 made it go down in flames. > See my earlier reply about the lack of support for the GEMMIS spec in JEMM386. Windows 3.x in 386 Enhanced mode should work with any EMM386 alternative that supports GEMMIS, such as QEMM386, and I believe also 386MAX. Unfortunately, there are currently no Free and Open source EMM386 alternatives with GEMMIS support, at least as far as I know. Is there anybody here with the knowledge and interest to work on such support? There is documentation available for this. See the GitHub issue link I shared in my earlier reply. On Sat, Jul 24, 2021 at 3:29 PM Steve Nickolas wrote: > On Sat, 24 Jul 2021, Eric Auer wrote: > > > I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft > > EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually > > necessary? I would expect things to also work with HIMEMX or XMGR, > > as long as no free EMM386 is loaded at all? Why do you use 4DOS in > > the DOS window inside Windows? Any special system.ini [386enh] items? > > See my notes below :-) Is setting VERSION=6.0 required, too? > > For what it's worth, Windows 3.x comes with its own versions of HIMEM and > SMARTDRV. I *think* it also comes with EMM386, but I'm not so sure about > that one. Have to check my setup disks. > > I think Windows' 386 mode is pretty heavily tied into undocumented > features of EMM386 when it is active, so it wouldn't surprise me if a free > version of EMM386 made it go down in flames. > > -uso. > > > _______ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
Hi FreeDOS devs, I understand that the EMM manager that currently ships with FreeDOS, JEMM, has several advantages over Microsoft's EMM386. Apparently it is more efficient in memory use and has some additional features and tweakable settings. And that's of course great. However, there are two things that JEMM currently doesn't provide. Firstly, JEMM doesn't have a port trapping API that is compatible with Microsoft's EMM386 memory manager. Yes, JEMM can offer similar functionality using JEMM Loadable Modules (JLMs), but the programming model of JLM is considerably different than the API in EMM386, or even QEMM's QPI. Most notably, JEMM/JLM requires the port trap handler (the emulation code) to be written in 32-bit protected mode code, whereas the EMM386 and QEMM386 APIs allow such handler code to be written as 16-bit code. This is a problem particularly for the popular SoftMPU TSR. The SoftMPU developers don't want to take on the burden of having to develop and support a JEMM version, in parallel to their EMM386/QEMM386 version. They prefer to work with a common codebase. See the comment at https://www.vogons.org/viewtopic.php?p=332252#p332252 To provide some context about this tool: SoftMPU emulates the Roland MPU-401 MIDI interface, including its so-called "Intelligent Mode", on sound cards that support only the UART mode subset of MPU-401, and since more recently, also on the RS-232 serial port, using a MIDI adapter, such as the recently released MPU-232: https://www.serdashop.com/MPU-232 SoftMPU is a popular utility for retro gamers, and it sucks that this software, which is itself an open-source project, currently requires a proprietary/closed-source component (namely EMM386 or QEMM386) in order to work with FreeDOS. The second limitation of JEMM is its lack of support for the GEMMIS specification. This means that it is not compatible with Windows 3.x, at least when we want to run it in 386 Enhanced Mode. (This is actually a second piece of the puzzle, since FreeDOS also requires kernel patches for this to work, as detailed in the recent "video FreeDOS running Windows 3.1" thread in this mailing list.) The GEMMIS standard provides a means to seamlessly hand over control of memory management from the EMM manager to the Windows kernel, and vice versa when exiting back to DOS. It is supported by only a select number of EMM managers, notably by Microsoft's own EMM386 and QEMM. The maintainer of JEMM doesn't consider GEMMIS worth the effort to implement, unfortunately. See this discussion: https://github.com/Baron-von-Riedesel/Jemm/issues/5 Now granted, in the latter case (lack of GEMMIS support), you could argue that since Windows is itself proprietary/closed-source, it's not that big a deal having to rely on a closed-source EMM manager. But having to replace JEMM with EMM386 or some other closed-source alternative would make the overall system less free. And alternatively, switching back and forth between EMM managers with different boot profiles is a hassle. Also, isn't maximum compatibility with MS-DOS the ultimate goal of FreeDOS? Being as much of a drop-in replacement as possible? In that sense, Windows 3.x should be considered just another application to run from DOS. An extensive graphical shell, as opposed to the quasi-OS that Microsoft intended the DOS/Win3.1 combo to be. As an additional argument: it is possible that GEMMIS was adopted by software outside of Windows as well, namely in the demo scene. Apparently, in order to compete in the Assembly'95 demo contest, applicants were required to ensure that their entries would be able to coexist with 386 memory managers. The GEMMIS spec was floated as a possible solution for meeting that requirement. Whether any demos with GEMMIS support were actually developed, I don't know. But that might be worth investigating further. More info on that here: http://dgi_il.tripod.com/gemmis.txt But going back to my main point: there is no full open-source drop-in replacement for EMM386, as far as I know. The ideal solution would be for some developers to enhance JEMM in such a way that support for both these features (GEMMIS and the EMM386 port trapping API) could be added. Perhaps these features could themselves be implemented as JLMs? That would keep JEMM lean, and make these features optional, just for those who need it. I currently lack the experience to implement such support, at least on my own. But nevertheless, I would like to start a discussion about this here. Perhaps others here know of better alternative solutions. For instance, maybe my assumption that there currently is no open-source drop-in replacement for EMM386 (including the aforementioned features) is incorrect? Do any of you know of any such projects that could fit the bill? Thanks. ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
Hi Eric, On Sun, Aug 8, 2021 at 8:20 PM Eric Auer wrote: > > How about letting the SoftMPU maintainers write a patch for JEMM? > If they're not interested in maintaining a fork of their own project, I think it will be very unlikely to convince them to contribute such a patch to JEMM. Also, Japeth (Baron-von-Riedesel on GitHub) expressed skepticism w.r.t. any submitted patches for this, in the same GitHub issue thread I linked to earlier. > This TSR simulates a MIDI device. Other related software includes > VSB, the virtual sound blaster. > VSB doesn't even work with Microsoft EMM386, since it uses QEMM's QPI API for port trapping. It works only with QEMM, or with no 386 memory manager loaded at all. I opened a GitHub issue with a feature request for QPI support in JEMM earlier, but when I was told that would be a non-starter, I closed it again. > Understandable, but fixing JEMM is easier than writing another EMM386. > It turns out that writing another EMM386 reimplementation from scratch might not be necessary after all. Do you remember this thread from 2012? I see you participated in it as well: https://sourceforge.net/p/freedos/mailman/freedos-devel/thread/4F2097D2.5060500%40sudleyplace.com/#msg28740668 In point 4 of his opening post, Bob Smith (sudleyplace on GitHub) mentioned that with enough interest, he would be willing to "release the source code for Qualitas MAX (a.k.a. 386MAX)". In that same thread in 2012, BretJ mentioned that 386MAX supports the same I/O port trapping API as the one offered by Microsoft EMM386. Also, 386MAX supports GEMMIS. So this might be the ideal solution for both these problems! :) I'll try to reach out to him to ask him if he would still be willing to release the source code. > Given that Windows already ships with MS EMM386, this seems to be a > limited problem. Also, I suspect that having GEMMIS compatible state > data structures would make JEMM less able to optimize for modern CPU. > Like I said, it would still be annoying to have to switch between boot profiles, since JEMM offers certain advantages too. It would be great to just have one good open-source EMM manager that would work with all of this. :) As for your suspicion that GEMMIS support would limit JEMM in terms of optimally supporting modern CPUs, I would like to get some clarity about this. Perhaps Japeth and/or others here can confirm whether or not this is the case. > That sounds rather exotic, given that they can more easily > run their DOS extenders on DPMI, VCPI or raw hardware. > Yeah, that was my thought too. Why not just use a DOS extender or something? > > More info on that here: http://dgi_il.tripod.com/gemmis.txt > > Thanks for the link! > You're welcome. :) It's cool to have this spec documented, regardless of whether this ultimately makes it into an open-source EMM386 replacement or not. By the way, DOSBox apparently has built-in GEMMIS support already, so there is at least one open-source implementation out there. As to how suitable that code would be for reuse in a memory manager, that is of course another question. :) > > But going back to my main point: there is no full open-source drop-in > > replacement for EMM386, as far as I know. > > Life is hard. Help to make the existing solution JEMM better ;-) > I'd love to! But as I said before, my low level coding skills are too limited. I'd love to assist and learn, though. Also, we would have to convince Japeth to accept a patch, even if it proves feasible to write one. > > Perhaps these features could themselves be implemented as JLMs? > > At least for I/O dispatch, there might be a chance? > Yeah, I'd like to know this too. Does anybody else here have a clue? > PS: I think JEMMEX and JEMMEX are far ahead of any other open > source EMM386 style drivers. > Yeah, I was aware that there was an older EMM386 replacement that has since been replaced by JEMM(EX). I guess it would be a lot more effort to dust that off and extend it with such functionality, than to enhance JEMM. But how well do you think 386MAX would compete with it, if it were to become open source? _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
On Sun, Aug 8, 2021 at 9:43 PM Steve Nickolas wrote: > > :O > > If 386^MAX could be released under suitable terms (for example the 4DOS > terms are problematic) then that would be something major to add to > FreeDOS. > As you can see in his existing repositories on GitHub ( https://github.com/sudleyplace ), Bob seems partial to the GPLv3, so I guess that would be acceptable to FreeDOS, right? 🙂 Anyway, I opened an issue in his DPMIONE project on GitHub, with a request for a release of the 386MAX source code: https://github.com/sudleyplace/DPMIONE/issues/3 > Isn't it not only a replacement for EMM386, but also for MEMMAKER? > I have no idea. I never used 386MAX back in the day, but if it came with a MEMMAKER-like utility, perhaps that will be included in the source code, should he decide to release it. Perhaps you can ask him in that GitHub thread. On Sun, Aug 8, 2021 at 9:43 PM Steve Nickolas wrote: > On Sun, 8 Aug 2021, Volkert via Freedos-devel wrote: > > > It turns out that writing another EMM386 reimplementation from scratch > > might not be necessary after all. > > > > Do you remember this thread from 2012? I see you participated in it as > well: > > > > > https://sourceforge.net/p/freedos/mailman/freedos-devel/thread/4F2097D2.5060500%40sudleyplace.com/#msg28740668 > > > > In point 4 of his opening post, Bob Smith (sudleyplace on GitHub) > mentioned > > that with enough interest, he would be willing to "release the source > code > > for Qualitas MAX (a.k.a. 386MAX)". > > > > In that same thread in 2012, BretJ mentioned that 386MAX supports the > same > > I/O port trapping API as the one offered by Microsoft EMM386. Also, > 386MAX > > supports GEMMIS. > > > > So this might be the ideal solution for both these problems! :) I'll try > to > > reach out to him to ask him if he would still be willing to release the > > source code. > > :O > > If 386^MAX could be released under suitable terms (for example the 4DOS > terms are problematic) then that would be something major to add to > FreeDOS. > > Isn't it not only a replacement for EMM386, but also for MEMMAKER? > > -uso. > > > _______________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
Hi Eric, On Mon, Aug 9, 2021 at 1:36 AM Eric Auer wrote: > > Hi Volkert, > > which worries does Japheth have regarding accepting I/O trap patches? > He wrote: *"My experiences - so far - with patches from unknown people are "mixed". So I'm rather sceptical."* Source: https://github.com/Baron-von-Riedesel/Jemm/issues/5#issuecomment-770343181 As for my suggestion to implement this in the form of a JLM (and the question whether that would even be possible), he hasn't replied to that yet. > What are the pros and cons of supporting the QEMM API for I/O traps, > compared to the MS EMM386 API? I think SB Live PCI soundcard drivers > only support the MS API? How hard would MS API support for VSB be? > Wasn't there a limitation in the MS API that didn't allow lower I/O ports (under 100 or something?) to be trapped? If so, then EMM386 would not be capable of intercepting I/O to the 8257 DMA controller. Then again, how would the SB Live PCI drivers be able to work without DMA port trapping? 🤔 Assuming that DMA port trapping wouldn't be an issue, my guess is that adapting VSB to EMM386 would be doable, at least for someone with sufficient experience with x86 assembly language programming. After all, SoftMPU supports both MS EMM386 and QEMM without too much trouble. I'd need some serious help to adapt VSB to work with the EMM386 API, though. So far, I haven't even been able to get the code to successfully assemble with the Open Watcom assembler yet. My first priority has been to eliminate the dependence of VSB on TASM. Some assistance or even a remote pair programming session would be cool. I'm sure I would learn a lot from it. Feel invited to convey our interest via his github :-) Some more thumbs-up responses there might help, though. :) > I guess Japheth would not want to spend too much time reading specs, > maybe you can extract possible constraints from the GEMMIS specs and > then just ask Japheth whether those would bother JEMM performance? > I can try. I could use some help with that, though. > > By the way, DOSBox apparently has built-in GEMMIS support already > > At least DOSEMU does not, it supports DPMI instead, which is okay > for Windows. Makes me wonder whether DPMIONE can help to run Win3 > better within FreeDOS, for example with 386enh and multiple DOS > windows at improved stability beyond Jeremy's recent updates? > This other thread on GitHub might interest you: https://github.com/sudleyplace/DPMIONE/issues/1 > I do not know more about it now than in 2012, seems like a not widely > used EMM386 replacement, but if the quality is similar to 386SWAT and > DPMIONE, I would be quite optimistic :-) > Good point. Perhaps we should just play with 386MAX a little, to see how well it works with various stuff. For instance, does SoftMPU even work as-is with 386MAX right now, considering its supposed compatibility with EMM386? That should be easy and fun to try out. Ditto for Windows 3.1 under FreeDOS, combined with Jeremy's patches. On Mon, Aug 9, 2021 at 1:36 AM Eric Auer wrote: > > Hi Volkert, > > which worries does Japheth have regarding accepting I/O trap patches? > What are the pros and cons of supporting the QEMM API for I/O traps, > compared to the MS EMM386 API? I think SB Live PCI soundcard drivers > only support the MS API? How hard would MS API support for VSB be? > > > > In point 4 of his opening post, Bob Smith (sudleyplace on GitHub) > mentioned > > that with enough interest, he would be willing to "release the source > code > > for Qualitas MAX (a.k.a. 386MAX)". > > Feel invited to convey our interest via his github :-) > > > As for your suspicion that GEMMIS support would limit JEMM in terms of > > optimally supporting modern CPUs, I would like to get some clarity about > > this. Perhaps Japeth and/or others here can confirm whether or not this > is > > the case. > > I guess Japheth would not want to spend too much time reading specs, > maybe you can extract possible constraints from the GEMMIS specs and > then just ask Japheth whether those would bother JEMM performance? > > > By the way, DOSBox apparently has built-in GEMMIS support already > > At least DOSEMU does not, it supports DPMI instead, which is okay > for Windows. Makes me wonder whether DPMIONE can help to run Win3 > better within FreeDOS, for example with 386enh and multiple DOS > windows at improved stability beyond Jeremy's recent updates? > > > But how well do you think 386MAX would compete with it, if it were to > > become open source? > > I do not know more about it now than in 2012, seems like a not widely > used EMM386 replacement, but if the quality is similar to 386SWAT and > DPMIONE,
Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
On Mon, Aug 9, 2021 at 2:26 AM Volkert wrote: > > On Mon, Aug 9, 2021 at 1:36 AM Eric Auer wrote: > >> >> Hi Volkert, >> >> which worries does Japheth have regarding accepting I/O trap patches? >> > > He wrote: *"My experiences - so far - with patches from unknown people > are "mixed". So I'm rather sceptical."* > Source: > https://github.com/Baron-von-Riedesel/Jemm/issues/5#issuecomment-770343181 > > As for my suggestion to implement this in the form of a JLM (and the > question whether that would even be > possible), he hasn't replied to that yet. > @Eric Auer Sorry, I confused two things in my answer above: this was in response to my request for GEMMIS support, not for implementing the EMM386 I/O port trapping API. I never created a GitHub issue for that. (I did open a separate feature request for QPI support, namely the I/O port trapping API of QEMM, but I closed that issue when it became clear that this would not be implemented.) But apparently Japeth's is skeptical of third party patches from unknown people in general. I guess it would help if someone who he knows well and trusts would be willing to step up to the plate here. ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
@Eric Auer Basically he was pretty sure that it would simply be too much work. See the discussion in this other GitHub thread: https://github.com/volkertb/temu-vsb/issues/4#issuecomment-703362672 On Mon, Aug 9, 2021 at 2:36 AM Volkert wrote: > > On Mon, Aug 9, 2021 at 2:26 AM Volkert > wrote: > >> >> On Mon, Aug 9, 2021 at 1:36 AM Eric Auer wrote: >> >>> >>> Hi Volkert, >>> >>> which worries does Japheth have regarding accepting I/O trap patches? >>> >> >> He wrote: *"My experiences - so far - with patches from unknown people >> are "mixed". So I'm rather sceptical."* >> Source: >> https://github.com/Baron-von-Riedesel/Jemm/issues/5#issuecomment-770343181 >> >> As for my suggestion to implement this in the form of a JLM (and the >> question whether that would even be >> possible), he hasn't replied to that yet. >> > > @Eric Auer Sorry, I confused two things in my answer > above: this was in response to my request > for GEMMIS support, not for implementing the EMM386 I/O port trapping API. > I never created a GitHub issue > for that. (I did open a separate feature request for QPI support, namely > the I/O port trapping API of QEMM, but > I closed that issue when it became clear that this would not be > implemented.) > > But apparently Japeth's is skeptical of third party patches from unknown > people in general. I guess it would > help if someone who he knows well and trusts would be willing to step up > to the plate here. > > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] DIGPAK sound drivers now open source under MIT license :) Can anybody help me port these from TASM?
Hi everyone, A few months ago, John W. Ratcliff released the sources of most of the DIGPAK DOS sound drivers on GitHub. He wrote those drivers in the '90s and used to license them commercially under the name The Audio Solution. DIGPAK drivers are used in many DOS games, and provide hardware abstraction to software developers through a well-documented INT 66h API. A few days ago, he clarified the license terms under which he was releasing this code. He has chosen to release it under the MIT License. His repository can be found here: https://github.com/jratcliff63367/oldsource It would be great if we could include these drivers in the FreeDOS distribution, and perhaps also use them as a basis for the development of DOS drivers for more modern audio hardware. Unfortunately, these drivers have been written in TASM Ideal mode dialect. To my knowledge, there are currently no open source assemblers in existence that can build such sources. Would anybody here care to help "fully liberate" these assembly sources by porting them to another dialect, such as regular MASM (that can be built with WASM or JWASM) or NASM? I know that VBE/AI is considered a more modern DOS sound API to standardize on for DOS driver development, but at least the DIGPAK drivers are already out there, and now with sources too. Also, one of the DIGPAK drivers in these sources is a wrapper around VBE/AI, which would be particularly useful, since it would allow possible future VBE/AI drivers to be made to work with many existing games. I've gained some experience from trying to port the sources of Virtual Sound Blaster (VSB) from TASM to other assembly dialects, and although I haven't been successful with that, I have gained some experience from it. With some help from other more experienced assembly coders here, I believe I can be more successful porting these drivers. Who's up for helping me with this? Your help would be greatly appreciated. :) ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Any package updates for FreeDOS 1.3?
Hi, ...Just made a merge request to update euphoria to version 3.2.0.5 Thank you, shian https://gitlab.com/rapideuphoria311 February 3, 2022 6:03:30 PM CET Jim Hall wrote: Hi everyone! Since the release of FreeDOS 1.3 RC5, I haven't seen any discussion about outdated or broken packages in RC5. (To be clear, I've seen some discussions about packages, but these seem to have been resolved as either a missed step or a config issue. But more generally, I don't recall any notes about broken or outdated packages.) So as we make the push for the "1.3" official release, I wanted to make one final call: Any issues with packages in RC5? Jim ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Sent with https://mailfence.com Secure and private email___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Update on website redesign
Hi, https://test.freedos.org looks great - two things I noticed immediately: 1. the search box on top is scratching the underline of [About] [News] ... 2. when switching between [About] [News] [Contribute] ... the screen flickers (using Firefox 89.0.2 (64-bit)). It's a very nice and clean design for FreeDOS. 5 stars. shian February 16, 2022 11:31:22 PM CET Jim Hall wrote:Hi everyone! It's been a while since I talked about the website redesign. It's been a slow process, but I finally have an iteration live on the test site: https://test.freedos.org/ This design is definitely an improvement on the current design at https://www.freedos.org/ but it's not perfect. To make it better, I'm asking for your feedback. Please take a look and follow up here to let me know what you think. Not all of the content is on here (more on that in the next email) but the structure and arrangement is all there. I might make changes to the design (layout and colors, etc) but it's good enough to get feedback now. Jim ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Sent with https://mailfence.com Secure and private email___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Update on website redesign
"What do you mean "the screen flickers"? Do you mean you get a "flash" of unstyled content, or something else?" Looks like it happens because the browser renders overlapping layers, first in dark color and then in bright color, (maybe because width or height are not declared somewhere, or because of rendering priorities, etc...) This flickering exists also in www.freedos.org, exactly the same. If you switch between the top menu items quickly then the screen is flickering. (on my i3 PC). It's not so bad and it doesn't happen each time, but it looks like some conflict in the css file that can be solved somehow. Thank you, shian February 20, 2022 1:50:10 AM CET Jim Hall wrote:Thanks for the feedback! I know about the vertical spacing issue. I need to do some tweaks to the layout/design but I figured I'd wait to get usability test results before I did anything there. So yes, that one is on my list too. What do you mean "the screen flickers"? Do you mean you get a "flash" of unstyled content, or something else? I also saw Tom's comments and I'll make a few minor changes to the content. I met with a student group yesterday, and shared an email update with the other groups too, and let them know I'm making a minor tweak to content based on freedos-devel feedback. Sounds like the timing is okay for them (they are designing Personas and Use Scenarios now) but I'll need to "lock in" the website very soon. But I definitely want to make sure we advertise the included dev tools (compilers) on the "programming" page. On Thu, Feb 17, 2022 at 9:11 AM shian via Freedos-devel wrote: > > Hi, > > https://test.freedos.org looks great - two things I noticed immediately: > 1. the search box on top is scratching the underline of [About] [News] ... > 2. when switching between [About] [News] [Contribute] ... the screen flickers (using Firefox 89.0.2 (64-bit)). > > It's a very nice and clean design for FreeDOS. 5 stars. > > shian > > > February 16, 2022 11:31:22 PM CET Jim Hall wrote: > > Hi everyone! > > It's been a while since I talked about the website redesign. It's been > a slow process, but I finally have an iteration live on the test site: > https://test.freedos.org/ > > > This design is definitely an improvement on the current design at > https://www.freedos.org/ but it's not perfect. To make it better, I'm > asking for your feedback. Please take a look and follow up here to let > me know what you think. > > Not all of the content is on here (more on that in the next email) but > the structure and arrangement is all there. I might make changes to > the design (layout and colors, etc) but it's good enough to get > feedback now. > > > Jim > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Sent with https://mailfence.com Secure and private email___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Update on website redesign
Hi, I found the reason why the screen flickers in freedos.org (on my PC): I'm using Firefox 89 on Linux Mint with Dark theme. The screen flickers because Firefox is using the dark system's theme as well. I switched to Bright theme on Linux Mint, restarted Firefox, and the problem disappeared. I guess that the Firefox developers need to address this problem with Dark system themes - not the FreeDOS developers. Thank you, shian February 24, 2022 12:25:01 AM CET Jim Hall wrote:On Sun, Feb 20, 2022 at 12:54 PM shian via Freedos-devel wrote: > > "What do you mean "the screen flickers"? Do you mean you get a "flash" > of unstyled content, or something else?" > > Looks like it happens because the browser renders overlapping layers, first in dark color > and then in bright color, (maybe because width or height are not declared somewhere, > or because of rendering priorities, etc...) > > This flickering exists also in www.freedos.org, exactly the same. > If you switch between the top menu items quickly then the screen is flickering. (on my i3 PC). > It's not so bad and it doesn't happen each time, but it looks like some conflict > in the css file that can be solved somehow. > Ok, thanks for mentioning that. I can write pages in HTML, but I don't consider myself an expert in web page design. I think there are a few possible solutions for this, such as adding a bit of javascript that forces the browser to finish loading everything before displaying it. That could fix the "flash" you mentioned. I'll look into some options. If I can add that to the www.freedos.org website, I will. Otherwise I'll test some things on the test.freedos.org after usability testing is done, and apply the fix after that. Jim ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Sent with https://mailfence.com Secure and private email___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Thinking about FreeDOS 2.0
Just another perspective: I'm using mainly DOS and Linux. DOS about 30 years, Linux about 10 years. But I've used many other OSs for work. I'm mainly a user, not a programmer, but I probably have enough experience to have an opinion... I think that DOS and Linux are very different from any aspect. Just like Assembly and C are very different. While mixing Assembly and C is essential in some areas, they are still completely different and contrary: Assembly works with the machine, C works with the compiler. DOS is obviously similar to Assembly, C is obviously similar to Linux. Different type of people like Assembly and C. You can mix Assembly and C, but you cannot change people's character. DOS users in general are very different from Linux users. Even myself, I use DOS and Linux for completely different purposes: DOS for doing real work, Linux for talking to others. Linux is overwhelmingly complex, DOS is beautifully simple with great freedom. Because they serve completely different purposes. A package manager on Linux is essential, while on DOS it is just a feature. Rolling release on Linux is essential, while on DOS again, it is just a feature. LiveCD or LiveCD on USB is a great way to test, use, maintain and rescue any operating system regardless. As a DOS user, all I need is the Base package, and a handful of applications for my work or hobby. I would prefer an online archive, easy to use, where that last version is on top. There are no shared libraries on DOS. everything is plug-and-play. As a Linux user, I need a package manager because of the complexity and the shared libraries. So, from my perspective, FreeDOS is the BASE packages. This is what it is, and it's more then good. And most of the focus and energy should go to it. Other utilities and applications should be easily available through a FreeDOS online archive. I'm saying this because I assume that Most users don't need more then handful applications anyway. And to download one or two applications from time to time, and copy/install them to some DOS folder, it's a piece of cake. To sum up: Don't use a hammer for doing a surgery, and don't use tweezers for building a house. Use the right approach for the right work. The line now is a bit blurry in FreeDOS, IMHO. Thank you, shian March 5, 2022 11:57:22 AM CET Jim Hall wrote: On Sat, Mar 5, 2022, 3:45 AM Robert Riebisch wrote: Hi Wilhelm, [..] > With an updated fdimples and wget (which also supports no NLS in FD) it > would be possible to find and add new games / files / tools / whatever > from a server - and Jim has the chance to announce it whenever they > appear. So people do not look every day with fdimples but get updates > whenever there is a new tool available. AND: the number of downloads > stays high! The community should not rely on Jim making all the announcements alone. Yes, Jim would prefer this as well. I sometimes get stuck doing things like news announcements because volunteers come and go. We used to have 3 or 4 people posting news items on the website, but right now it's just me. But I mostly repeat announcements on the website that originally appear here on the email list. A few folks email me separately for announcements, probably because they think I'll see them faster - ironically, these get mixed with a bunch of other stuff that goes directly to me (including personal stuff and spam) so it's actually slower to email me off-list. It would be best if everyone just made new version announcements here. (This isn't quite what you were referring to, but maybe this will encourage a few other folks to volunteer.) ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Sent with https://mailfence.com Secure and private email___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] The 386MAX source code has been released :)
Hello FreeDOS developer community! Bob Smith of Sudley Place Software has released the source code of 386MAX and related tools under the GPLv3 license! He'd like this news to be passed on to whomever would be interested in this source code, but he does add that the project has little to no documentation available. See his comment at https://github.com/sudleyplace/DPMIONE/issues/3#issuecomment-1172710414 The reason why this is of particular importance to the FreeDOS project, is because it provides the following two features that JEMM currenty lacks: - 386MAX supports the Global EMM Import Specification (GEMMIS), which allows Windows 3.x to start in 386 Enhanced mode, even when the EMM manager is loaded. (The documentation in the 386MAX source code seems to refer to it as the "Global Paging Import Spec".) - 386MAX supports the same I/O port trapping API through INT 2fh that EMM386 provides. This (at least in theory) should make it compatible with certain emulation TSRs such as SoftMPU and VSB, which currently don't support JEMM, and would require separate non-trivial ports to work with JEMM's JLOAD feature. Anyway, the code is available at https://github.com/sudleyplace/386MAX I would very much like to see 386MAX included in the FreeDOS distribution, with the option for users to choose between it and JEMM. It seems that the assembly code requires MASM, so I guess the first step would be to try getting it to build with WASM or JWASM. Who's up for helping me get this ready for inclusion with FreeDOS? ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] The 386MAX source code has been released :)
Thanks for the quick analysis of the source code, Jim! Perhaps it would be a good idea to open these 3 issues on GitHub, and get the ball rolling that way? https://github.com/sudleyplace/386MAX/issues On Sat, Jul 2, 2022 at 12:31 AM Jim Hall wrote: > This is excellent news! It's great that he has released this under the > GNU GPL. I did a quick review, and I think these are the only issues I > found: > > > Issue 1. Bob needs to take the extra step to review his comments in > his code, to make sure this doesn't conflict with the GNU GPL. For > example, I did a little poking around and found source files like > this: > https://github.com/sudleyplace/386MAX/blob/main/386MAX/LOADALL.INC > > At the top of that file, we have: > > ;' $Header: P:/PVCS/MAX/386MAX/LOADALL.INV 1.0 11 Aug 1995 10:56:06 HENRY $ > ; > ; (C) Copyright 1987-92 Qualitas, Inc. All rights reserved. > ; > ; LOADALL.INC > ; > ; 286 LOADALL and 386 LOADALL structures > ; > > The "(C) Copyright 1987-92 Qualitas, Inc" is fine. I'd recommend that > this get updated to "1987-92, 2022" to represent that the code was > also released in 2022. And it would probably be best for Bob to put > his name in there somewhere, to indicate he has the rights to release > this as GNU GPL. (Maybe Bob would be willing to copy/paste his comment > from > https://github.com/sudleyplace/DPMIONE/issues/3#issuecomment-1172710414 > into a README file in the GitHub project? That would probably get to > the same place.) But as it is, that should be okay. (IANAL) > > But the "All rights reserved" is a problem. This is incompatible with > the GNU GPL. At best, it is confusing. But this really needs to get > cleaned up before we can include it in FreeDOS. (Note we had the same > "All rights reserved" issue with FDNET's Crynwr network drivers a > while ago. That issue was resolved when Russel later confirmed the > extra "All rights reserved" statements were added by an automated > process.[*1]) > > > Issue 2. Bob should also review his GitHub project to ensure that > every binary file included there has source code for it somewhere. For > example, https://github.com/sudleyplace/386MAX/tree/main/CYADISK seems > to be nothing but DLL and EXE files. I think the source is in > https://github.com/sudleyplace/386MAX/tree/main/CYASETUP but I'm not > sure. > > In general, if there's no source code for something, Bob should > consider removing that from the tree. > > > I think those are the only issues I found in doing a quick review of > Bob's GitHub project. In the meantime, I'll post a news item about it > on the website and tweet about it from our Twitter account. > > > Jim > > > [*1] I just realized that Russel's email gave me permission to update > the Crynwr network source code files on Ibiblio and I haven't done > that yet, so I'll do it this weekend > > On Fri, Jul 1, 2022 at 5:03 PM Volkert via Freedos-devel > wrote: > > > > Hello FreeDOS developer community! > > > > Bob Smith of Sudley Place Software has released the source code of > > 386MAX and related tools under the GPLv3 license! > > > > He'd like this news to be passed on to whomever would be > > interested in this source code, but he does add that the project > > has little to no documentation available. See his comment at > > https://github.com/sudleyplace/DPMIONE/issues/3#issuecomment-1172710414 > > > > The reason why this is of particular importance to the FreeDOS project, > > is because it provides the following two features that JEMM currenty > > lacks: > > > > 386MAX supports the Global EMM Import Specification (GEMMIS), which > > allows Windows 3.x to start in 386 Enhanced mode, even when the EMM > > manager is loaded. (The documentation in the 386MAX source code seems to > > refer to it as the "Global Paging Import Spec".) 386MAX supports the > > same I/O port trapping API through INT 2fh that EMM386 provides. This > > (at least in theory) should make it compatible with certain emulation > > TSRs such as SoftMPU and VSB, which currently don't support JEMM, > > and would require separate non-trivial ports to work with JEMM's > > JLOAD feature. > > > > > > Anyway, the code is available at https://github.com/sudleyplace/386MAX > > > > I would very much like to see 386MAX included in the FreeDOS > > distribution, with the option for users to choose between it and JEMM. > > > > It seems that the assembly code requires MASM, so I guess the first > > step would be to try getting it to build with WASM or JWASM. > > > > Who's up for helping me get this ready for inclusion with FreeDOS? > > > ___ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
On 23/10/22 20:46, Jim Hall wrote: I keep meaning to test Rufus <https://rufus.ie/en/> to see if it will successfully create a bootable USB flash drive based on the FreeDOS LiveCD. If it does, I don't think we need to keep either the FullUSB or LiteUSB. Has anyone here used Rufus to create a bootable USB flash drive from the LiveCD image? I think users shouldn't depend on software that's exclusively designed to work on Windows (Rufus). I have used the LiteUSB image to create a bootable flashdrive with dd in the past and it's been quite useful. I suggest not to remove it, or at least keep the FullUSB or some USB image. On 23/10/22 15:44, Jerome Shidel wrote: Although the next major version of FDIMPLES will most likely support online repositories, it is being written %100 in assembly and not coming soon. Even once the new version of FDIMPLES is ready, general networking support under FreeDOS is very limited. This leaves us with providing additional packages on the release media for the near future. Nice! That will be very useful, as the user won't depend on removable media to remove/update/install new software. Tauro ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 386MAX
On Mon, Mar 6, 2023 at 7:45 PM Bret Johnson wrote: > > Or just take some of the important stuff that Bob Smith and Qualitas > discovered about Windows/GEMMIS/EMM386 and import it into something like > JEMM. There's some knowledge embedded in 386MAX about what MS did that you > will never directly get out of MS. I already opened a ticket for this on GitHub <https://github.com/Baron-von-Riedesel/Jemm/issues/5> a few years ago, but Japheth (a.k.a. Baron-von-Riedesel on GitHub) has expressed reluctance to implement this functionality in Jemm, unfortunately. By the way, DOSBox already has an open-source GEMMIS implementation <https://sourceforge.net/p/dosbox/code-0/2601/>, which would likely be easier to port to Jemm than any of the 386MAX sources. I was hoping that 386MAX could ship with FreeDOS as an alternative EMM manager because there appeared to be no near-term prospect of having GEMMIS support (and thus Windows 3.x 386 Enhanced mode compatibility) added to Jemm. Also, since 386MAX implements the same port trapping API as that of Microsoft EMM386, I was hoping that it would offer compatibility with certain drivers and emulators such as SoftMPU, which don't work with Jemm. At least there's some encouraging news on that front, in the form of a Jemm Loadable Module that adds support for QPI (QEMM's port trapping API), or a subset of it. Baron-von-Riedesel recently developed that module, so crazii's recently developed Sound Blaster emulator called SBEMU <http://gitlab.com/crazii/SBEMU> (also a very promising project for FreeDOS!) can work with Jemm. So GEMMIS support appears to be the one missing feature that would make Jemm a complete replacement for all the known EMM managers of old (EMM386, QEMM, 386MAX). But perhaps if someone creates a pull request for adding GEMMIS support to Jemm, Japheth might be persuaded to merge it. (Although he has expressed skepticism towards that as well.) ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
Hi, Over a month ago, I opened an issue on the FreeDOS project on GitLab about the Open Watcom v2 installer being extremely slow in FreeDOS. It takes an hour or more on FreeDOS, while the same installation completes on MS-DOS 7.1 within just a few minutes. I've reproduced this in VM instances, both with VirtualBox and Qemu/KVM on a Linux host. I have not tested this on a bare-metal DOS machine. See https://gitlab.com/FreeDOS/issue-reporting/-/issues/42 But I haven't seen anybody respond to the issue. Is that really the proper place to report FreeDOS bugs these days? With the `issue-reporting` subproject, this is at least implied. To be clear, I used a recent DOS build of the Open Watcom v2 fork <https://github.com/open-watcom/open-watcom-v2> to test this. I did not explicitly test this with the old original v1.9 release, but since the installer runs fine on MS-DOS, it seems unlikely that this issue with FreeDOS was introduced in the forked project. The difference in installation time is extreme, which suggests some kind of bug or inefficiency in the file access routines of FreeDOS. Could somebody maybe take a look at this? Also, I wonder if others have noticed similar poor file I/O performance under FreeDOS with other DOS software. Thanks. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
On Wed, Mar 8, 2023 at 1:40 AM Ralf Quint wrote: > > Well, I know some folks will hate me for that (what else is new) but there > is no MS-DOS 7.1. It's the bootup DOS system of Windows 95SR2 and up. > That's just getting pedantic about things. Whatever you prefer to call it, the "bootup DOS system of Windows 95SR2" doesn't have this problem, but FreeDOS does. At least as of version 1.3. By the way, I'm pretty sure I used FAT32 in both cases. And even if I didn't, the use of FAT32 really shouldn't lead to such an excessive slowdown. I would still consider that a bug that ought to be looked into. > So possible issues at hand could be the use of FAT32 and/or long file > names, which I somehow recall OW2 defaulting to. > Funny you'd mention LFN support, since the maintainer of OW2 disabled it when I initially reported this finding there, before someone else pointed out that it ran fine in "MS-DOS 7.1": https://github.com/open-watcom/open-watcom-v2/issues/1025 Anyway, disabling LFN support in the installer did not resolve the issue, so it's not that. > The last time I installed OW was on one of my physical laptops, which are > currently in storage, so I can't easily test this right now, and I am > pretty sure that I installed the v1.9 from openwatcom.org. Not sure if > both 1.9 and 2.0 are actually using the same installer... > I would guess they do, since it doesn't look like the DOS installer was touched much since the project was forked. ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?
You might want to take a look at the VMusic project by javispedro <https://git.javispedro.com/cgit/vmusic.git/about/>. It's an open-soure extension pack for VirtualBox that enhances sound emulation support, notably adding high quality OPL3 FM synthesis emulation and MPU-401 emulation with MIDI passthrough to the host. It only supports Linux hosts, though. Perhaps this extension pack could be further improved by having it include an alternative SB16 emulation option that would implement the fixes suggested in that VirtualBox ticket. On Fri, Jan 27, 2023 at 6:24 PM Ben Collver wrote: > On Fri, 27 Jan 2023 at 16:42, tom ehlert wrote: > > > any reason you don't download VirtualBox for your platform, select > > > proper devices (there is even a Soundblaster16 emulated), install DOS > > > on it and go. > > VirtualBox SoundBlaster16 emulation doesn't actually work with DOS. > VirtualBox developers have gaslit DOS users about this in their forum. It > is a known problem and VirtualBox developers rejected fixes for it. For > technical details, see the following support ticket. > > https://www.virtualbox.org/ticket/14883 > > _______ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
On Wed, Mar 8, 2023 at 2:02 AM Ralf Quint wrote: > Well, I just download both v1.9 and the latest 2.0 and the later is 1.75x > as big as v1.9 (143MB vs 81MB), so there must be some more than trivial > difference between the installers... > I was referring specifically to the DOS installer code within the sources. The side of the payloads may (the stuff being installed by the installer) may indeed have changed considerably. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
On Wed, Mar 8, 2023 at 11:35 AM tom ehlert wrote: > > > Over a month ago, I opened an issue on the FreeDOS project on > > GitLab about the Open Watcom v2 installer being extremely slow in > > FreeDOS. It takes an hour or more on FreeDOS, while the same > > installation completes on MS-DOS 7.1 within just a few minutes. > > either you report your config.sys and autoexec.bat for both tests > or your report is basically useless. > > write caching smartdrv (which freedos is known not to have) makes a > HUGE difference for installers, so you are comparing apples to oranges. > > of course running both without autoexec/config.sys would place them on > an equal playing field. OK, that's a fair point. When I have time again, I'll try to do more of an apples-and-apples comparison between the two, and then I'll share my findings here. An installation time of an hour still seems excessively slow though, even when no disk cache is loaded. What added value does that issue reporting project on GitLab have over this mailing list, by the way? Is it actively used, or is it expected to in the future? Thanks. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 386MAX
Thanks for figuring out how to build this at least in some way, and sharing the results of that work, Rodrigo! It's unfortunate to read that you discovered binary blobs in the code base that are apparently needed to build 386MAX. Could anybody here maybe shed some light on the feasibility of replacing these blobs with open-source alternatives, or barring that, a legally sound way of reverse-engineering them? The Windows compatibility is exactly the feature that made 386MAX so interesting in the first place. On Mon, Mar 20, 2023 at 5:14 AM Rodrigo Morette wrote: > Hey all, > > I have been playing around with these sources, a minimal "working" build > is possible with 386MAX.SYS and 386MAX.VXD. > > But there is a problem who inviabilizes an OSS build: 386MAX.VXD > statically link 3 proprietary objects who seems to be from a development > kit made by Microsoft: LOADHI.OBJ, INSTINIT.OBJ and INSTSWAP.OBJ. A quick > search shows these files are related to EMM386, looks like the Windows > compatibility comes from these libraries. > > There are also some files from Windows DDK in the include directories. > > I plan to keep my attempt to rebuild MAX just for fun as it cannot be > considered reliable for any major OSS project... I left the sources (no > proprietary files included) for this minimal build with the serial code > verification disabled here: https://github.com/rmorette/MAX > > Rodrigo. > > On Tue, Mar 7, 2023 at 6:56 PM Volkert via Freedos-devel < > [email protected]> wrote: > >> >> >> On Mon, Mar 6, 2023 at 7:45 PM Bret Johnson wrote: >> >>> >>> Or just take some of the important stuff that Bob Smith and Qualitas >>> discovered about Windows/GEMMIS/EMM386 and import it into something like >>> JEMM. There's some knowledge embedded in 386MAX about what MS did that you >>> will never directly get out of MS. >> >> >> I already opened a ticket for this on GitHub >> <https://github.com/Baron-von-Riedesel/Jemm/issues/5> a few years ago, >> but Japheth (a.k.a. Baron-von-Riedesel on GitHub) has expressed >> reluctance to implement this functionality in Jemm, unfortunately. >> >> By the way, DOSBox already has an open-source GEMMIS implementation >> <https://sourceforge.net/p/dosbox/code-0/2601/>, which would likely be >> easier to port to Jemm than any of the 386MAX sources. >> >> I was hoping that 386MAX could ship with FreeDOS as an alternative EMM >> manager because there appeared to be no near-term prospect of having GEMMIS >> support (and thus Windows 3.x 386 Enhanced mode compatibility) added to >> Jemm. Also, since 386MAX implements the same port trapping API as that of >> Microsoft EMM386, I was hoping that it would offer compatibility with >> certain drivers and emulators such as SoftMPU, which don't work with Jemm. >> >> At least there's some encouraging news on that front, in the form of a >> Jemm Loadable Module that adds support for QPI (QEMM's port trapping API), >> or a subset of it. Baron-von-Riedesel recently developed that module, so >> crazii's recently developed Sound Blaster emulator called SBEMU >> <http://gitlab.com/crazii/SBEMU> (also a very promising project for >> FreeDOS!) can work with Jemm. >> >> So GEMMIS support appears to be the one missing feature that would make >> Jemm a complete replacement for all the known EMM managers of old (EMM386, >> QEMM, 386MAX). >> >> But perhaps if someone creates a pull request for adding GEMMIS support >> to Jemm, Japheth might be persuaded to merge it. (Although he has expressed >> skepticism towards that as well.) >> _______________ >> Freedos-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freedos-devel >> > ___ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Happy 29th anniversary to FreeDOS!
Hi, On Thu, Jun 29, 2023 at 12:46 PM Jim Hall via Freedos-devel wrote: > > In 1994, several of us got together around a pretty neat idea. > > We liked DOS, but Microsoft was clearly moving completely to Windows. "The > next version of Windows," they said, "would do away with DOS." > > We wanted to keep DOS around, so we decided to write our own. That project, > announced 29 years ago TODAY on June 29 1994, was the FreeDOS Project. > > Thanks to EVERYONE who is (or has been) part of FreeDOS! 29 years is a long > time for any open source project, and I'm looking forward to more years to > come. Congrats to my favorite operating system. (In fairness, there are other great OSes too, not just the obvious ones.) My own birthday was yesterday, and 1994 was when I got my first IBM PC (with MS-DOS 6.00 and Windows 3.1). You've done great work, keeping the legacy alive. There was so much cool stuff for DOS over the years (not just games). I'm particularly fond of compilers and utilities myself. I will forever think that some people are geniuses for their work on FreeDOS like Eric Auer. It's just amazing what some people accomplished. I was only able to contribute very small stuff, but hopefully it helped anyways. The spotlight may have faded for DOS over the years, but that doesn't diminish their hard work. Dedicated fans like us will never forget all the cool stuff that was accomplished with it. May it live forever in emulation. ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
On Sun, Jul 23, 2023, 7:54 AM Liam Proven via Freedos-devel < [email protected]> wrote: > On Sun, 23 Jul 2023 at 02:52, Paul Edwards via Freedos-devel > wrote: > > > > My main interest is using Freedos+HX as a substitute for Windows 95. > > AFAICS you never explain. What is "HX"? > > > -- > Liam Proven ~ Profile: https://about.me/liamproven > https://www.japheth.de/HX.html HX DOS-Extender is a free DOS extender with built-in Win32 PE file format support Jeremy ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
Hi, On Sun, Jul 23, 2023 at 7:08 AM perditionc--- via Freedos-devel wrote: > > On Sun, Jul 23, 2023, 7:54 AM Liam Proven via Freedos-devel > wrote: >> >> AFAICS you never explain. What is "HX"? > > https://www.japheth.de/HX.html > > HX DOS-Extender is a free DOS extender with built-in Win32 PE file format > support Note that HX 2.16 is a much-older version, and Japheth no longer updates the website. Newer releases (e.g. 2.20) are all on Github: * https://github.com/Baron-von-Riedesel/HX/releases _______________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK 1.3.8 released
I can translate FDISK to Spanish. Native Spanish speaker, very good English knowledge and working command of German. Sent from Yahoo Mail on Android On Mon, Jul 24, 2023 at 12:56, Bernd Böckmann via Freedos-devel wrote: Today I released FDISK 1.3.8 into the wild: https://github.com/FDOS/fdisk/tree/v1.3.8 The FDISK user interface is now translatable. Version 1.3.8 ships with translations for German, French and Turkish. Translation into Polish is in the works, and I also would like to have it available in Spanish, but have not found a translator yet. The SvarLANG library is used to implement the translation functionality. The last month, I worked with Mateusz Viste on improving the library, namely speeding up the string lookup by slightly changing the binary file format to use sorted lookup tables instead of linked lists. The modifications got incorporated into upstream: http://svn.svardos.org/listing.php?repname=SvarDOS&path=%2Fsvarlang.lib%2Ftrunk FDISK now builds wich IA16-GCC, at least under Mac OS. (As a side-note: IA16-GCC runs under Mac OS and is able to build the FreeDOS Kernel). Continious integration is setup for the FDISK Github repository. When a new commit is pushed to the master branch, an automatic build is triggered using Open Watcom v2 (Linux). Build artifacts may be downloaded from: https://github.com/FDOS/fdisk/actions Apart from that, the usual bugfixing occured: Version 1.3.8 (2023-07-24) -- Bugfixes: - HIGH: Fix a bug preventing FDISK to work if ext. INT 13 support is reported by the BIOS, but actual support for functions 42, 43 and 48 is non-existant (mainly 486 systems and early LBA support era). - HIGH: Fix a bug preventing FDISK from working correctly, if BIOS returns garbage in AH for INT 13 function 2 or 3 and CF is zero (mainly some buggy XT/AT era INT 13 implementations). - HIGH: Fix FDISK not returning an error code if partition table can not be written. (since <= v1.2.1) - MEDIUM: Fix FDISK not letting the user delete the last existing logical drive until program is restarted, if the first logical drive in EMBR chain is not the last to be deleted. (since v1.3.5) - MEDIUM: Fix FDISK wrongly informing the user that no space in the extended partition is left after deleting the last logical drive, until program is restarted. (since v1.3.5) - LOW: Fix a display bug showing the extended partition a few MB smaller than it actually is while creating logical partitions. - LOW: Prevent FDISK from using different rounding schemes for displaying partition sizes, confusing the user by showing slightly different values in some situations. Greetings, Bernd ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Virtual get-together?
Hi, On Sun, Jul 30, 2023 at 11:03 AM Gregory Pietsch via Freedos-devel wrote: > > Wasn't a virtual get-together supposed to happen about now? -- Gregory Maybe Jim is still under the weather? _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
Hi, On Fri, Jul 28, 2023 at 11:51 AM Liam Proven via Freedos-devel wrote: > > For me, when I worked with, supplied and supported DOS in the late > 1980s and early 1990s, the chronology went like this: > > [2] DOS 4 came along. It was a memory hog, but it had big-disk support > (over 32MB) and DOSShell, so it caught on. DOSShell was *much* better > than batch files, and quicker and easier too. It also obviated the > need for things like Xtree for file management. DOSShell, like most > other DOS menu apps, could swap itself out of memory so it only took a > tiny bit of space, like a single-digit number of kB. Nobody minded > that. I never used DOSShell much. I always used other file managers (in limited ways because it hides the cmdline, which is much easier to use for utilities and programming), e.g. Tutordo, Dos Controller, Necromancer's DOS Navigator, Doszip. Some people frown upon the "hard to use" cmdline, but it's scriptable and you can automate so much. The "interface" can be arcane, but I don't see the speed advantage to "add graphical widgets and mouse support". I find the mouse "mostly" redundant for most tasks. I personally find GUI overrated, TUI underrated, and cmdline (usually) easy enough to use. > [3] Windows 3.0 started to catch on. That meant HIMEM.SYS and XMS as > standard; LIM-spec EMS started to fade. Apps like 1-2-3 r3 used DOS > extenders routinely. Memory management really got important but > everyone was buying 386SXs so you could sell them QEMM even if they > didn't want Windows. VCPI was a superset of EMS, right? That was co-designed by QuarterDeck (DesqView company), right? It was meant to make multitasking more stable, but DPMI (later invented for Windows 3.0 but also implemented elsewhere) was much better designed and more popular. Before Win95, all you had was 32-bit DOS extenders. By the time Vista (and its DPMI "limit") came out, nobody cared anymore. The other complication was the different versions (e.g. XMSv2 versus the bigger 386 variant v3) and whether your EMM386 could share XMS and EMS at the same time. There were various complications there. Since the XMS standard and support was so "late", several compilers (e.g. Turbo C) only enabled "use EMS" by default. In fact, quite a few apps and games were "EMS only", even 386+ programs. (It was only DJGPP v2 in 1996 where they went "DPMI only".) > [4] DR-DOS 5 bundled the memory management of QEMM and for a while it > sold really well, even for people who did want Windows. DR-DOS 5 was their equivalent to MS-DOS 3.3. (Version numbers were a marketing ploy.) > [5] MS-DOS 5 copied all the good bits from DR-DOS 5, and DOSShell got > even better. Now it did task swapping: you couldn't multitask, but you > could pause any standard DOS app, switch back to DOSShell, *and launch > a new app*. I believe "task swapping" was one of the main benefits of a 286. For instance, DR-DOS 7.03 supports "task swapping" on 286s but only "multitasks" on 386s. (This probably also goes back to IBM's own TopView, which predated DesqView.) The DesqView/X SDK used DJGPP v1, but I don't know much about that (or DesqView in general). > Anyone who wasn't booting straight into Windows, and who still used > DOS apps, I configured the PC to boot straight into DOSShell instead. > I made menu entries for all their DOS apps, and one for Windows 3.x > too. Clearly OS/2 and/or Windows were considered the future. (Novell's attempt at improving DR-DOS failed against Win95.) > [6] By 1993-1994 most PCs booted straight into Windows 3.1 but I made > launchers for their DOS apps in Program Manager, and in the > background, I hand-optimised their RAM with EMM386.EXE so there was > lots of free RAM for those big power-user DOS apps. Win95 was better. (I still have my overformatted "upgrade" Win95 floppies.) > Then Win95 came along and it all went away. :-) I didn't care because > I'd switched to NT 3 at work and OS/2 2 at home. NT was not aimed at DOS software. It was incomplete in DOS support in many ways (and had a much higher footprint). NT also wasn't (at that time) intended for gaming. OS/2 2.x (and up) was the 32-bit OS after IBM and MS parted ways. So IBM was handling it all themselves. > > Years ago, I thought DOS GUIs were interesting. I liked that folks > > were writing GUIs like SEAL and oZone, and continuing to work on > > OpenGEM. But of those, only OpenGEM really has much application > > support. Even so, there aren't many GEM apps to run in it. But there > > are a ton of regular DOS apps. > > The thing is this, IMHO. > > There are 2 conflicting goals here: > > [a] a GUI that has its own GUI apps > [b
Re: [Freedos-devel] dosshell and task swapping, was: dir issues
Hi, On Sun, Jul 30, 2023 at 12:19 PM Eric Auer via Freedos-devel wrote: > > VCPI was a small interface added to things like EMM386 which gave other > apps access to things they would normally no longer reach after DOS gets > locked up in a VM86 task by EMM386. While it is nice that it is small, > it is not so nice that it basically lets you kick out other protected > mode things to use them yourself. DPMI is significantly larger, but it > lets you use protected mode in s far more cooperative way. Which is why > protected mode hosts like DOSEMU and Windows would typically only offer > DPMI, not VCPI, because VCPI is too raw metal, too little cooperative. DPMI could run in ring 3 and also optionally supported 286s (as well as 386s) while VCPI was ring 0 and 386 only. > itself, so your app only has to deal with ONE interface: DPMI :-) When the host OS' DPMI (e.g. Windows Vista) is buggy, there is no escape. > > In fact, quite a few > > apps and games were "EMS only", even 386+ programs. (It was only DJGPP > > v2 in 1996 where they went "DPMI only".) > > Are you sure you mean apps? Maybe specific DOS extenders? Which? Scream Tracker 3 (for sound samples) and Blackthorne (game) come to mind. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
Hi, On Mon, Jul 31, 2023 at 8:38 PM Paul Edwards via Freedos-devel wrote: > > Yes, if you're prepared to add a curses layer, then you can > support both the standard, plus non-standard things like > a PC BIOS. But neither fullscreen application that I actually > used and care about (microemacs and msged) added that > layer (both added their own layer though). Yes, curses (lib) is what most *nix use. Wikipedia says originally the first curses library's code was borrowed from Bill Joy's vi (a famous full-screen editor, twice as popular as emacs). DOS also got ports of Stevie, XVI, Calvin, and VIM. There is still a DOS port of PDcurses, at least for DJGPP (386/DPMI). It was used in Hesseling's THE editor (among other things). Note that there were several so-called "microemacs" by different people, and different forks and versions. The VILE editor (vi clone) is based upon Daniel Lawrence's MicroEmacs, IIRC. (There is a DJGPP port.) I think there was some dispute over some of Conroy's code (later on). And OpenBSD used to bundle "mg2a" Emacs (no GNU regex by default). Minix 2 had Elle. DJGPP still has GNU Emacs (26.1 or such). Don't forget Freemacs (and FreeDOS). > > Shooting for platform independence is admirable. > > Sure. At some level I am trying to answer "what went wrong?". > And perhaps demonstrating what we could have had instead > if people had simply followed the standards. Although C90 > came a bit late for people to be in a position to follow. Scott Franco is a big fan of ISO 7185 "classic" Pascal. I built a version of (updated) P5 Pascal for FreeDOS back in 2013. That dialect predates both UCSD and Turbo Pascals. But he was hard set on only bootstrapping it with a similar "classic" Pascal compiler (e.g. GNU Pascal / GPC), which is rare. However, with Scott's work, I was able to salvage P4 (circa 1976), reuse p2c, and get that to build with either OpenWatcom or GCC. P4 isn't nearly the full standard nor nearly as efficient as P5, but it's better than nothing (IMHO). Both of those are "public domain". However, most people don't care about standards, and even the ones who do don't really think anything "useful" can be written in them. Which is untrue and a shame. There are way too many competing languages, too. Something else is always "newer", shinier, more practical, more elegant, more popular, etc. I know I've mentioned some of this before. Just wanted to give you some idea. > If you do setvbuf NBF to switch off buffering of stdin, it is assumed > that by default that the C library will switch into raw mode and > switch off line buffering, so that all the platform-specific code > that would otherwise need to be done to achieve that (all the > tset stuff on Unix e.g.) is hidden away in the C library. Libraries like curses just hide (or build atop of) termcap and/or terminfo on *nix. It's a big mess. Even the OpenWatcom installer on Linux relies on terminfo, IIRC. > But in reality there is no requirement for the C library to actually > do that that I am aware of, and I'm not aware of anything other > than PDPCLIB that does that. So if using an arbitrary C library > your application would be forced to add platform-specific code > after all. It takes two to tango. Most people don't care about ultimate or theoretical portability. While I 100% agree with and sympathize with you, it's not interesting to them. They only care about "modern" systems (which still ship commercially and are fully supported). Most sympathy with DOS went away after WinXP (unsupported in 2014) or Win9x (unsupported in 2006). AMD64 didn't help. Even VT-X took forever and only helped emulators. I think a lot of people underestimated how hard it would be to fully emulate (properly) in software. > I'm not stating that Microsoft is embracing the exact same > concept that I am (not saying they're not either), but I don't > think it is so black and white that the microemacs that I just > released as source and DOS binary is inherently useless. Windows 11 is 64-bit only and doesn't have NTVDM anymore. > Of course you can say that UC8086 itself is inherently useless > too. Definitely not. But I haven't tried it yet. "A poor carpenter blames his tools." Most people lack imagination (or hope). > But I'm expecting to burn the latest UC8086 onto a CF > and boot it on my Book 8088 later today. I don't think I can > even do that with the Freedos distribution I use as I think it > has a dependence on an 80386 processor. So for an > alternative to UC8086 I will be using MSDOS 6.22 and > ANSIPLUS. The kernel should have an 8086-friendly build. The latest shell might be 8086-friendly too (although the old
Re: [Freedos-devel] ANSI for DOS
Hi, On Tue, Aug 1, 2023 at 3:24 AM Paul Edwards via Freedos-devel wrote: > > > However, most people don't care about standards, and even the ones who > > do don't really think anything "useful" can be written in them. Which > > is untrue and a shame. > > It is only recently - perhaps only a few hours ago - that I started > to have confidence that it was untrue. > > Ok, so an entire toolchain plus OS plus fullscreen editor can be > written - what definition of "useful" is being used? That's enough > to quite literally rebuild the world. I don't know, some people are never satisfied. I'm happy with Space Invaders or Tetris or Doom. Others prefer Minecraft or Fortnight or whatever modern Unreal or Unity game. I'm also happy with a simple 386 assembler, but others demand x64 with AVX-512, a full preprocessor, structs, unions, macros, HLL-compatible calling conventions, etc. My favorite utility is probably *nix Sed (which is related to Ed and Grep). So those are super useful to me. Others prefer a full HTML5 web browser with Javascript v5 (or whatever). I used to chide my brother with his quote "but it doesn't burn DVDs", so I think that's an unreasonable expectation for computers. But I'm not huge on multimedia (although I enjoy YouTube and Twitch). I like "simple" compilers. I like text editors. I like text manipulation tools. > > There are way too many competing languages, > > too. Something else is always "newer", shinier, more practical, more > > elegant, more popular, etc. > > Yeah, I'm not really trying to compete in that field either. You know what I mean. Pascal vs. Modula-2 vs. Oberon vs. Ada vs. Delphi C vs. C++ vs. ObjC vs. C# vs. D vs. Go AWK vs. Perl vs. Ruby vs. Python Or even C++11 vs. C++20 vs. whatever. It never ends. > Once I have the entire toolchain (just the C compiler is sort of missing - > SubC is only a subset of C90), then I am happy, in principle, to > start again from scratch in Pascal or Rust or whatever. But so > far I haven't even completed the "C venture" - even to the point > of answering the above question about migrating from one bitness > to another. C is a bit of a red herring. (Isn't everything?) ISO C alone isn't enough for POSIX 2008 (requires mmap). A lot of code depends on deleting open files (POSIX file system), for instance. And there's no (inherent) subdir support. I'm not complaining. Just saying, others' expectations and demands are much heavier than yours (and ours). > > It takes two to tango. Most people don't care about ultimate or > > theoretical portability. While I 100% agree with and sympathize with > > you, it's not interesting to them. > > Sure. I'm not really attempting to corner the mass market. Maybe > that will happen later, but it isn't priority at the moment. I'm more > interested in an 8080 (8-bit) OS, now that I have a NEC V20. Check out David Given's attempt at CPMish on Github: * https://github.com/davidgiven/cpmish > >> But I'm expecting to burn the latest UC8086 onto a CF > >> and boot it on my Book 8088 later today. > > It does work, but there was an anomaly. Clearing the > screen doesn't work. I took a look at how that is done, > and it is done by doing a scroll up. I suspect the bios > in the Book 8088 doesn't support that. I haven't yet > confirmed it. Isn't there an ANSI escape for that? Or does that not work either? "[2J" or something? (I think DR-DOS' shell did that for CLS.) > >> I don't think I can > >> even do that with the Freedos distribution I use as I think it > >> has a dependence on an 80386 processor. So for an > >> alternative to UC8086 I will be using MSDOS 6.22 and > >> ANSIPLUS. > > > The kernel should have an 8086-friendly build. The latest shell might > > be 8086-friendly too (although the old 2006 stable one was 186). > > I didn't really understand this comment, FreeDOS should run on 8086, both kernel and shell. If it doesn't, that's a bug or omission. I know I have some old floppy images that I ran under 8086tiny (and derivatives) and Joris' Retro. I never preferred a "386" kernel for FreeDOS because it was very minimal improvements and not worth it. We're talking a few minimal cycles shaved due to better instruction use (in real mode), that's all, no added features. Same with 186, usually not worth it. (Doesn't mean there isn't still room for improvement.) > so I simply burnt my > Freedos 1.3 onto a CF. It said "Loading FreeDOS" and then it > beeped continuously for 1-2 minutes, then it started makin
Re: [Freedos-devel] tree 3.7.2/3.7.1
I will look into it. Jeremy On Wed, Aug 2, 2023, 12:07 PM Wilhelm Spiegl via Freedos-devel < [email protected]> wrote: > Hi all, > > I just worked on checking tree 3.7.2 - it is a little bit tricky. The > source code of 3.7.2 seems to be identical with 3.7.1, but the .exe is > identical > with 3.7.0. > I found information about 3.7.1 at archive.org, see: > > https://web.archive.org/web/20011212151852/http://www.darklogic.org/fdos/projects/tree/ > This > text that says that the options /s, /d and (according to nls: /v, version, > works) are added at 3.7.1. They work with 3.7.1, from root, > but they do not work correct at subdirectories, and, as Jerome Shidel > reported, there are problems with HD serial number in dosbox. > > Is there anybody out there who can check / fix this as I am no programmer. > > Thanks > > Willi > _______ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
Hi, On Wed, Aug 2, 2023 at 2:29 AM Paul Edwards via Freedos-devel wrote: > > > FreeDOS should run on 8086, both kernel and shell. If it doesn't, > > that's a bug or omission. > > Are you sure? I thought I was told that the standard > distribution relied on an 80386. Jerome's work on the distribution overall (and a lot of software packages) requires 386. But the basics should still run on 8086. > > ke20xx_32.zip : binaries for 8086, FAT16, FAT32 > > I got this, and then renamed my kernel.sys to kernel.old, > > Regardless, I then burned the image onto the CF and > booted on the Book 8088 and I got the same problem. > "loading freedos" followed by incessant beeping. It's probably something else, but I don't know what. > > The very bare minimum (besides boot sector) is kernel and shell. What > > other pieces of DOS software did you need or want? > > Oh I see - thanks. I need fdisk and format and more > and doslfn and possibly xcopy, but it doesn't support > lfn, and zip and unzip. DOSLFN is 386. (You could maybe reassemble StarLFN for 8086 and use LONGNAME.DAT files to store the LFNs, but it'd be slow.) Zip and Unzip do have 16-bit versions, but I think FreeDOS normally ships the 32-bit versions. Check here for 16-bit versions (if needed): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/info-zip/ _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
Hi, On Mon, Aug 7, 2023 at 7:45 AM Liam Proven via Freedos-devel wrote: > > On Sun, 30 Jul 2023 at 17:55, Rugxulo via Freedos-devel > wrote: > > > I believe "task swapping" was one of the main benefits of a 286. > > It's not a 286 hardware feature, no. > > It's a feature of DOS-compatible OSes of the 286 era. It's a software > feature not a hardware one. But it was enabled by XMS memory > management, something that a DOS could only do on a 286 or later. Wikipedia says the 286 "was designed for multi-user systems with multitasking applications". OS/2 1.x targeted it. > > For > > instance, DR-DOS 7.03 supports "task swapping" on 286s but only > > "multitasks" on 386s. > > Yes, because it uses 386 hardware features to do multitasking. > > > (This probably also goes back to IBM's own > > TopView, which predated DesqView.) > > I don't think TopView did much multitasking at > all, but the thing here is that the DesqView style of multitasking is > done in software and everything has to fit into conventional memory: > all apps share the base 640kB of RAM. Wikipedia says "TopView is the first object-oriented, multitasking, and windowing, personal computer operating environment for PC DOS developed by IBM". > The later 386 type of multitasking doesn't: it's using hardware to do > it it and the software is running in protect mode and has up to 4GB of > virtual address space to play with. > > It's a really big important difference. I'm sure you're more familiar with OS/2 1.x than I am. But clearly that multitasked apps on a 286 in protected mode. > > > Anyone who wasn't booting straight into Windows, and who still used > > > DOS apps, I configured the PC to boot straight into DOSShell instead. > > > I made menu entries for all their DOS apps, and one for Windows 3.x > > > too. > > > > Clearly OS/2 and/or Windows were considered the future. (Novell's > > attempt at improving DR-DOS failed against Win95.) > > Clearly according to whom? OS/2 was "a better DOS than DOS". Originally it was even codenamed "DOS 5", right? The so-called "European MS-DOS v4 that multitasks" used NE format in real mode. That's similar to OS/2 (which also used NE, as did Win 3.x). DOS was never their top priority, but it made them money. Compatibility was important (for a time). I doubt they originally intended to sell multiple OSes, but when you try to support 8086, 286, 386 ... what can you do? Ever-increasing memory amounts needed newer OSes and APIs. > > > [6] By 1993-1994 most PCs booted straight into Windows 3.1 but I made > > > launchers for their DOS apps in Program Manager, and in the > > > background, I hand-optimised their RAM with EMM386.EXE so there was > > > lots of free RAM for those big power-user DOS apps. > > > > Win95 was better. (I still have my overformatted "upgrade" Win95 floppies.) > > That seems a bit like saying that the wheel is better than fire. > > It's a different thing that happened at a later time. They are not comparable. As far as DOS compatibility goes, Windows 3.1 and 95 had a lot in common. > > NT was not aimed at DOS software. It was incomplete in DOS support in > > many ways (and had a much higher footprint). Win95 had DOS features (FAT32, LFNs) that NT didn't get until Windows 2000. > > > DOSShell was a great DOS app launcher and file manager, but didn't have > > > apps. > > > > Apparently "Visi On" in 1983 was the first (and yes, it did allow > > third-party apps in "restricted subset of C" for its VM.) > > I don't really see any connection here, TBH...? Wikipedia says "VisiCorp Visi On was a short-lived but influential graphical user interface-based operating environment program for IBM compatible personal computers running MS-DOS". ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
Hi, On Tue, Aug 8, 2023 at 10:46 AM Kirn Gill via Freedos-devel wrote: > > On Mon, Aug 7, 2023 at 7:24 PM Rugxulo via Freedos-devel > wrote: >> >> Wikipedia says the 286 "was designed for multi-user systems with >> multitasking applications". OS/2 1.x targeted it. > > Multitasking requires no special hardware whatsoever. Cooperative > multitasking simply requires an API > designed to yield control to the next task upon a system call. Preemptive > multitasking only requires a timer > that generates a hardware interrupt with sufficient regularity. I have never used Desqview nor Desqview/X (DJGPP v1 SDK), so I don't know how those worked. But I have used DR-DOS 7.03's 386 multitasking. To me it was nice but limited use (to my usage scenario) because it was limited to 64 MB per task and required their DPMI (and their EMM386) to always be enabled. (DR-DOS also can run Windows 3.x but not quite run Win95 although allegedly comes close.) > ELKS - the Embeddable Linux Kernel Subset - performs preemptive multitasking > on an 8086. I never got around to trying ELKS. The lack of obvious releases (back in the day) confused me. I can't remember if they used a FreeDOS boot disk or not. They claimed networking and LFNs. It sounded interesting, but I was never sure what apps were precompiled for it (IIRC, using BCC/dev86). QEMU Advent Calendar had an image for it, but I don't think I ever got around to trying it. Comparatively, I've (rarely) run the 16-bit Minix 2.0.x a few times. They used segmentation to share static code between processes, I think (e.g. multiple instances of the same executable). Several caveats but still a cool OS. >> > > For >> > > instance, DR-DOS 7.03 supports "task swapping" on 286s but only >> > > "multitasks" on 386s. >> > >> > Yes, because it uses 386 hardware features to do multitasking. Its proprietary EMM386 doesn't need a separate HIMEM.SYS and has embedded VXDs (or something weird like that which I don't understand) and a built-in DPMI server. Although it reports "XMS 3.0", it really caps out at 64 MB. >> OS/2 was "a better DOS than DOS". Originally it was even codenamed >> "DOS 5", right? The so-called "European MS-DOS v4 that multitasks" >> used NE format in real mode. That's similar to OS/2 (which also used >> NE, as did Win 3.x). >> >> DOS was never their top priority, but it made them money. >> Compatibility was important (for a time). >> >> I doubt they originally intended to sell multiple OSes, but when you >> try to support 8086, 286, 386 ... what can you do? Ever-increasing >> memory amounts needed newer OSes and APIs. > > The original plan was to let Windows fade away after 2.x; there was an > engineer at Microsoft that mostly > improved Windows by himself enough to run all of the Microsoft Office > components at the same time > (a difficult, if not impossible feat under Windows 2.x of any flavor) and got > an executive's attention shortly > after the OS/2 launch with his experimental Windows build that it caused > Microsoft to repivot around DOS > and Windows again. Gordon Letwin had a long post explaining his view of the MS split from IBM: * https://groups.google.com/g/comp.os.ms-windows.misc/c/-iNeep60eVE/m/Xl5ddAtJENcJ?hl=en > My understanding is that OS/2 is a direct descendant of Multitasking MS-DOS > 4.10 (an even rarer update > to the already-rare multitasking 4.00) with a LOT of reengineering behind the > scenes. Limited analysis with > Ghidra, however, can neither confirm nor deny this hypothesis at this time. Most of the work on the 1.x (16-bit) versions of OS/2 was done by Microsoft. Supposedly their 32-bit "portable rewrite" is what became NT. (However, Win95 could still barely run atop a 386 with 4 MB of RAM, so it stuck around on the consumer side.) >> > > NT was not aimed at DOS software. It was incomplete in DOS support in >> > > many ways (and had a much higher footprint). >> >> Win95 had DOS features (FAT32, LFNs) that NT didn't get until Windows 2000. > > But back to DOS, NT's support for DOS is cruddy on purpose. It's meant as a > developer compatibility tool > to keep old compilers working, it wasn't really meant for consumer use. On > i386, it's uses the Virtual 8086 > Mode to implement a fresh DOS environment. Windows 3.0 and Windows NT 3.1 both had many DOS bugs that were only fixed later. Heck, Win95 had various bugs. Even XP (which "mostly" worked) had bugs. NT wouldn't run Quake because of its DJGPP's nearptr usage while Win95 could (with help from CWS of CWSDPMI). Some bugs in XP were w
Re: [Freedos-devel] CD-ROMs was ANSI for DOS
Hi, On Sun, Aug 6, 2023 at 9:05 PM Michael Brutman via Freedos-devel wrote: > > Just an opinion, but it's bad software design to assume that the presence or > a peripheral implies > a certain class of machine. The presence of a CD-ROM should not imply a 386 > or better machine; > it's orthogonal. Not sure this example helps your case, but Dragon's Lair (1983) was LaserDisc on a Z80! ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting FreeDOS kernel without a 386
Hi, On Fri, Aug 11, 2023 at 5:28 AM Paul Edwards via Freedos-devel wrote: > > Sorry for the delay. I've been sick recently (possibly Covid) > plus had other stuff to deal with. No fun, get well soon. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Ré : Ré : T2308 invalid partition signature after format
Hi, On Sat, Sep 16, 2023 at 10:21 PM Paul Dufresne via Freedos-devel wrote: > > Sorry, the address was in octal, > > with -Ax to have the address in hexa it feels ok to me: Most people prefer "hexdump" these days: * https://man7.org/linux/man-pages/man1/hexdump.1.html * https://man.freebsd.org/cgi/man.cgi?query=hexdump&manpath=FreeBSD+13.2-RELEASE+and+Ports * https://man.openbsd.org/hexdump.1 _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Interim Build T2310
Hi, On Mon, Oct 2, 2023 at 2:07 PM Jim Hall via Freedos-devel wrote: > > Jim wrote: > > I want to compile some things using IA-16 GCC in the new Interim Build > > T2310, but neither the LiveCD or BonusCD have the DJGPP Environment > > package on it. We had this on previous FreeDOS installs; to compile > > with IA-16 GCC, you need to set the DJGPP environment variable to a > > DJGPP.ENV file. > > > > Or is the DJGPP Environment package on one of the ISOs, and I've > > missed it somehow? > > > Jerome wrote: > > The DJGPP are massive. There is not enough room on the CDs for > > everything else when DJGPP is included. Off-hand I think those packages > > require something like 350Mb. > > > > Plus… there have been “complaints” that the DJGPP needed updating > > and some other tools/packages should also get included. > > > > I’m not a DJGPP user and don’t want to break those packages. So, > > I’m not updating them. > [..] > > Yes I saw the discussion about DJGPP being out of date and really big. > No problems there. I know the distro is getting really big (see also > below) and we should try to trim some things. I just wanted to compile > something with IA-16 GCC (not DJGPP) and found I couldn't because > something was missing in T2310 that IA-16 GCC needed. > > I wonder what the mininum extra stuff is needed from DJGPP to get > IA-16 GCC to work. I haven't tried, but I guess that's a project I'll > try to tackle soon. If it's a matter of crafting an ENV file, then > that's one thing. If IA-16 GCC really needs a bunch of stuff from > DJGPP, that may preclude IA-16 GCC if we don't have DJGPP. T.K. Chia's Gitlab site says this (untested by me): "Alternatively, if you do not wish to install DJGPP, just set a DJDIR environment variable thus: set DJDIR=c:\devel\djgpp" * https://gitlab.com/tkchia/build-ia16/-/releases Off the top of my head, I don't know of any hard requirements that I16GCC.EXE (etc.) needs from DJDEV205.ZIP. (The 386 COFF libraries are useless, for instance, presumably all of the headers too. The rest is mostly just misc. utils and info files.) ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Phishing attack - warning!
Hi, Gmail caught one with its Spam filter. It doesn't show any prior emails from this person. author: [email protected] subject: Re: [Freedos-user] TASM under an emulator? link: urdirec.com On Thu, Nov 2, 2023 at 11:07 AM Mercury Thirteen via Freedos-devel wrote: > > ...as did I. Mine was as follows. > > From: [email protected] > Subject: Re: [Freedos-devel] Logger v0.3-BETA > Content: > Hi There, > Please look into the the document in the web-link down the page. > LINK BUTTON > Enjoy a good afternoon! > _______________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi, On Wed, Nov 8, 2023 at 1:42 PM Bernd Böckmann via Freedos-devel wrote: > > has anyone recently played around with the FreePascal 8086 cross > compiler to generate DOS executables? I try to convert a near pointer to > a far pointer while working under the small memory model, but that is > not as trivial as it should be, because I have not found a language / > library feature for it. > > I came up with the following solution, but I am wondering if I have > overlooked something built-in? Try reading this: * https://wiki.freepascal.org/DOS#New_pointer_types Yes, I sometimes play around with FPC i8086-msdos, but I've never really messed with mixed memory model programming. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi, On Wed, Nov 8, 2023 at 2:21 PM Bernd Böckmann via Freedos-devel wrote: > > the tests I did showed that FreePascal is perfectly capable of producing > reasonably small binaries fitting the small memory model, if you do not > require the full language feature set (stay away from ObjFpc / Delphi > modes). SysUtils and exception handling pulls in a significant amount of > code, so you either stick with plain FPC or TP modes or have to live > with large memory model. FPC mode is the default and (I believe) allows function overloading and structured return values (with slightly different function pointer syntax). > I am not that interested in Turbo Pascal compatibility, so I can not say > anything about it. For me, FreePascal provides some benefits over Turbo > Pascal, taking my specific use case into account: e.g. 64-bit arithmetic > in 8086 real mode. I believe int64 was originally from Delphi. (Isn't there also "long long" support in OpenWatcom via "-za99"?) > To the specific problem: I have to provide a FAR pointer to the BIOS as > a member of an INT13 device access packet. That pointer shall point to a > 512 byte array, for which I get a near pointer via the @ address > operator. This near pointer has to be converted to a far pointer. > Because this operation is clearly defined for the small memory model, I > asked if someone knows that a built-in solution exists. But perhaps this > question is better addressed to the FreePascal community. In the > meantime, I will use the function from my last mail. Dunno, directly ask FPC guys MarcoV or NickySn. Sometimes they frequent the BTTR Forum too. ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Error compiling FreeDOS Kernel
Hi, On Wed, Nov 8, 2023 at 2:21 AM Walter Oesch via Freedos-devel wrote: > > I want to build the FreeDOS Kernel. Kernel 2043? Any particular reason to not use the stock build? Did you modify anything or add any patches? Just curiosity? > I use Dosbox in Ubuntu Linux and watcom comiler from FreeDOS, version 1.9. Which version of DOSBox? 0.74-3? Which Ubuntu? 20.04 LTS 64-bit? OpenWatcom can also run natively atop Linux. The old 1.9 installer had a bug where it needed "export TERMINFO=/lib/terminfo" first. You could also probably unzip it and manually install. (I assume it has a Linux makefile somewhere. It also had a MinGW makefile, IIRC.) You also need NASM and UPX. (You might need one older [or newer??] than 2.16.01.) > I changed config.b to use watcom and copied to config.bat, then start with > buildall.bat. > The compilation hangs in BOOT/boot.asm:437 Warning Must update constant > offset (17Bh)... > > What did i wrong? I don't know, but I'm not sure DOSBox is recommended (or even supported) for this kind of task. The only times I really rebuilt the kernel were atop FreeDOS itself (under QEMU or VirtualBox). _______________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Error compiling FreeDOS Kernel
On Wed, Nov 8, 2023 at 3:21 AM Walter Oesch via Freedos-devel < [email protected]> wrote: > I want to build the FreeDOS Kernel. > I use Dosbox in Ubuntu Linux and watcom comiler from FreeDOS, version 1.9. > > I changed config.b to use watcom and copied to config.bat, then start with > buildall.bat. > The compilation hangs in BOOT/boot.asm:437 Warning Must update constant > offset (17Bh)... > > What did i wrong? > > Freundliche Grüsse > Walter Oesch > > That error means that neither ISFAT12 or ISFAT16 was defined during the assembly of the boot sector or the boot sector file did not assemble such that the expected offset to patch by sys is at the same place [either changes were made, possibly assembled differently, or something else happened]. You will want to use BUILD.BAT not BUILDALL.BAT as the 1st will build a kernel as you have configured whereas the second is used to build the kernel multiple times with different options and compilers. If you have Ubuntu, it will probably be easier to build directly in Linux as that is how the CI builds are done on GitHub. I have never tried building in DOSBox, but that should not affect the build of the boot sector unless it is somehow causing build options to not be passed to Nasm. I will try to replicate this weekend. Jeremy _______________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi, On Thu, Nov 9, 2023 at 4:39 PM Bernd Böckmann via Freedos-devel wrote: > > > Could you please post the exact message you got from the compiler? > > For something like this "FarPointer(@Buffer)" I get the following error > message: > > "Error: Illegal type conversion: "Pointer" to "FarPointer"" > > My opinion is that this should be supported by the compiler, because it > is well defined for the small memory model I am working in. I had thought @ was just an alias for the built-in Addr() function. (In classic / ISO Pascal, you can't get the address of anything, and '@' is a character substitute for '^'.) A quick search shows this: * https://wiki.freepascal.org/FPC_New_Features_3.2.0 FarAddr internal function Overview: There's a new i8086-specific internal function, similar to Addr(), called FarAddr(), which always returns a far pointer to the address of its argument. Notes: The built-in Addr() function and the @ operator return a pointer type (near or far), that depends on the memory model. When interfacing with DOS, BIOS and other 16-bit APIs, it is sometimes useful to be able to obtain a far pointer to a pascal variable or procedure/function, regardless of the selected memory model. Previously, you would have to use ifdefs, or do something like Ptr(Seg(x), Ofs(x)). Now, this can be replaced with the much nicer FarAddr(x). svn: r37629 ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi again, On Fri, Nov 10, 2023 at 7:56 AM Bernd Böckmann via Freedos-devel wrote: > > > > > I believe int64 was originally from Delphi. (Isn't there also "long > > long" support in OpenWatcom via "-za99“?) > > Yes, Watcom C supports 64-bit integer arithmetic, in contrast to Turbo C 3.1, > which to my knowledge does not, > but silently interprets „long long x“ as „long x“, yielding a 32-bit integer > type. Would something like this (assembly, 8086 and 386) help? "Fast 64-bit Signed Integer Arithmetic Routines (Roger Moser)" * http://cd.textfiles.com/ems/emspro1/ASMUTIL/QMATH0.ZIP Or how about this (32-bit assembly)? "Efficient [Unsigned] 64-Bit Integer Arithmetic in 32-Bit Mode (AMD)" * http://web.archive.org/web/2020110100*/https://sites.google.com/site/rugxulo/32math64.txt?attredirects=0 _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi, On Sun, Nov 12, 2023 at 5:46 AM Bernd Böckmann via Freedos-devel wrote: > > On 12.11.2023 02:44, Rugxulo via Freedos-devel wrote: > > But I still have not found an elegant solution yet to do a widening > conversion of an untyped pointer from near to far. > Should be rarely needed though. For a typed pointer FarAddr(thing^) does the > trick. You can get the current code segment or data segment with the CSeg and DSeg functions. * https://www.freepascal.org/docs-html/rtl/system/seg.html Also see the "absolute" keyword: * https://wiki.freepascal.org/Absolute ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] VME broken on Ryzen CPU, autodetection useful?
Hi, On Mon, Nov 13, 2023 at 7:44 AM Eric Auer via Freedos-devel wrote: > > > Hi! I just got reminded that (2017 news) > > http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/ > > VME is broken on AMD Ryzen of that time Ryzen (Zen 1) was brand new in 2017, redesigned from scratch. I doubt the current Zen 4 (2022) has that bug, but who knows. (Now that the BIOS and CSM are dead, they may not care to fix it. And the whole "x86-S" rumors imply legacy is going away.) > That sounds like > something which would be relevant for JEMM386, because it > could automatically activate NOVME mode for affected CPU. It's faster with VME (on Pentium and up), right? > Does anybody remember whether it does? * https://github.com/Baron-von-Riedesel/Jemm/releases v5.79 (Oct 31, 2020) "VME (virtual mode extensions) is now off by default; there exist CPUs that claim to support VME but actually don't." > And whether AMD has fixed the issue in later Ryzen or other CPU versions? Not sure. I'll search Google. * https://wiki.gentoo.org/wiki/Ryzen "Broken VME (Virtual-8086 Mode Enhancements) on 1st gen Ryzen 1st Ryzen processors generation had a broken VME implementation: 16-bits VM86 tasks within a 32-bits protected mode OS crash. This has been fixed by a later microcode revision" * http://www.os2museum.com/wp/vme-fixed-on-amd-ryzen/ Odd, the fix was mentioned on OS/2 Museum (in 2017, again). "The fix is shipped in the form of a microcode patch as part of AGESA 1.0.0.6, currently being rolled out by OEMs as part of a BIOS update. The patch level for the fixed microcode is 8001126 or higher. The older microcode revision 800111C (part of AGESA 1.0.0.4a) is known to have trouble with VME." But looking at this VOGONS thread, I'm unsure: * https://www.vogons.org/viewtopic.php?t=53952&start=20 ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] VME broken on Ryzen CPU, autodetection useful?
Hi, On Mon, Nov 13, 2023 at 9:19 PM Steve Nickolas via Freedos-devel wrote: > > I think there may be a point where if one's going to run DOS on > a modern machine, it'll have to be through some degree of emulation. > Whether that be a KVM/QEMU-on-metal approach, or a 64-bit "DOS" which can > emulate a Pentium MMX or so, VESA SVGA, SB16, etc. for legacy apps... > > (Actually, I'd be interested in something of this ilk if I knew more, > having run a stripped-down Apple //e emulator on bare-metal from UEFI and > then giving up because I couldn't read the damned Alt keys...) Just for comparison, for Raspberry Pi (ARM), *not* running atop Linux (or any other host OS): One guy emulates the old 8-bit CP/M OS (and Z80 cpu) via Ultibo (written in Free Pascal), thus allowing him to run Turbo Pascal 3 for CP/M : * http://www.projekte.daleske.de/prog/11_EMUZ80_RPI/prog_EMUZ80_RPI_en.htm Another guy tried porting Project Oberon (compiler and OS) to Ultibo : * https://github.com/MGreim/ultiboberon _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Regarding Edlin in Chinese
Hi all, French and Turkish translation contributor to FreeDOS here. While browsing the archive of freedos-devel, I stumbled upon the thread about Edlin in Chinese and wanted to bring a few pages to your attention. Firstly, you may see that some people are asking for CJK (Chinese, Japanese, Korean) support for FreeDOS on <https://github.com/shidel/fd-nls/issues/149>. The discussion may be interesting as there seems to be a solution but it's not free software :/ Secondly, please note that for some reason, edlin remains in English in FreeDOS. More information on that on <https://gitlab.com/FreeDOS/base/edlin/-/issues/1>. Thirdly, someone provided a simplified Chinese translation for edlin on <https://github.com/FDOS/edlin/pull/3>. Finally, I noticed that there was a Japanese translation for edlin on <https://github.com/shidel/fd-nls/blob/master/edlin/nls/edlin.ja> but as you can see, its content is a bit... disappointing and currently it's not possible to use that language in FreeDOS. Well, that's all. Whenever Jerome pulls the the tree new messages for edlin on FD-NLS, I'll translate them. _______________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Question about USBDOS license
On 30.11.2023 20:22, Bret Johnson via Freedos-devel wrote: They can voluntarily contribute if they want, but nothing is required. Hi Bret, I would have another question regarding USBDOS' license: what about manufacturers that sell computers with FreeDOS preinstalled to avoid the Windows tax? For instance in the Middle-East, many local manufacturers do that, and even big names like HP because the Windows license fee isn't negligible in local currencies and licenses like GNU GPL allow it. Can they include USBDOS? _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Learning DOS assembly programming
A86. Sent from Yahoo Mail on Android On Tue, Dec 26, 2023 at 13:49, Jim Hall via Freedos-devel wrote: I actually never learned DOS assembly programming, but decided I'd like to start. What assembler do you recommend, and where is a good place to start learning about DOS assembly programming? Start with a "Hello world" program and eventually move up to writing an assembly version of TYPE and CHOICE, things like that. I was thinking about NASM, since it's open source and we include it in the distribution. Looking around, I found a bunch of tutorials on https://asmtutor.com/ that look easy enough to follow, although it's for Linux. Any similar tutorials to learn DOS assembly programming? Or would you recommend a different DOS assembler (and how-to guide) as a place to start? ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Is there an open source fmt clone for DOS?
This seems to be exactly what you're looking for. https://www.bttr-software.de/freesoft/unix.htm Under "GNU Textutils", you will find fmt. Here's a direct link for a 16 bit version: ftp://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/dos_only/tut111ax.zip On 24/1/24 20:10, Jim Hall via Freedos-devel wrote: I'm looking for a way to keep my text files (like README.TXT) tidy and easy to read. One problem is that if I modify a plain text file in a regular text editor, and change the line length in the middle of a paragraph, now I have to fix all the lines around it so the lines are all about 77 characters wide. On Linux, I'd use the BSD 'fmt' command to do it. This is a trivial program to write (and I just did) if you don't want cool features like preserving indents. But there are probably lots of similar existing programs to do the same thing - so I wondered if anyone knows of an open source DOS version of 'fmt' (or something like it)? ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
On Sun, Feb 4, 2024, 6:32 AM Eric Auer via Freedos-devel < [email protected]> wrote: > > Hi Jim, > > > I'm glad you're bringing this conversation back to freedos-devel .. > > because this is a good place to discuss FreeDOS things. > > In related news, the dosemu2 people also find the problem interesting. > > Their discussion mentions that FDPP, a port of the FreeDOS kernel, > > https://github.com/dosemu2/fdpp > > fixes plenty of issues listed in our kernel bug lists. So maybe > somebody feels like backporting those to FreeDOS. However, as far > as I remember, the diff is huge, nothing easily cherry-picked. > > Regards, Eric > FDPP is a great project and has done a wonderful job of helping when porting fixes to fd kernel.sys. If I had more time I'd love to be able to help there more as I see it as the future for DOS as more and more computers are UEFI only. I ordered a book8088 (hopefully) so i can test directly, but coming from China so at least 2 months before delivery. Based on what I've read it sounds like the drive is booting using CHS and the disk layout doesn't match what the kernel thinks it is. That said, that specific spot is where boot time memory corruption usually is noticed and anything the kernel did up to then could be the culprit. There has been several fixes to the startup (boot code and initialization) that may or may not be related. (I had hoped to publish an updated kernel over Christmas but that didn't happen because I didn't get all the changes and testing I would like done. I hope to put out an updated kernel for testing next weekend.) Jeremy > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
Hello, perditionc--- via Freedos-devel wrote: > > On Sun, Feb 4, 2024, 6:32 AM Eric Auer via Freedos-devel > wrote: >> >> >> Hi Jim, >> >> > I'm glad you're bringing this conversation back to freedos-devel .. >> > because this is a good place to discuss FreeDOS things. >> >> In related news, the dosemu2 people also find the problem interesting. >> >> Their discussion mentions that FDPP, a port of the FreeDOS kernel, >> >> https://github.com/dosemu2/fdpp >> >> fixes plenty of issues listed in our kernel bug lists. So maybe >> somebody feels like backporting those to FreeDOS. However, as far >> as I remember, the diff is huge, nothing easily cherry-picked. >> >> Regards, Eric > > > > FDPP is a great project and has done a wonderful job of helping when porting > fixes to fd kernel.sys. If I had more time I'd love to be able to help there > more as I see it as the future for DOS as more and more computers are UEFI > only. I ordered a book8088 (hopefully) so i can test directly, but coming > from China so at least 2 months before delivery. Based on what I've read it > sounds like the drive is booting using CHS and the disk layout doesn't match > what the kernel thinks it is. That said, that specific spot is where boot > time memory corruption usually is noticed and anything the kernel did up to > then could be the culprit. There has been several fixes to the startup > (boot code and initialization) that may or may not be related. (I had hoped > to publish an updated kernel over Christmas but that didn't happen because I > didn't get all the changes and testing I would like done. I hope to put out > an updated kernel for testing next weekend.) You don't need a real Book8088 for testing. 86Box "Xi8088" machine with XT-IDE(CHS=1006/16/63) can reproduce this bug. > > Jeremy > Regards, Roy ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
On Sun, Feb 4, 2024, 7:39 AM roytam--- via Freedos-devel < [email protected]> wrote: > Hello, > > perditionc--- via Freedos-devel > wrote: > > > > On Sun, Feb 4, 2024, 6:32 AM Eric Auer via Freedos-devel < > [email protected]> wrote: > >> > >> > >> Hi Jim, > >> > >> > I'm glad you're bringing this conversation back to freedos-devel .. > >> > because this is a good place to discuss FreeDOS things. > >> > >> In related news, the dosemu2 people also find the problem interesting. > >> > ... > > You don't need a real Book8088 for testing. 86Box "Xi8088" machine > with XT-IDE(CHS=1006/16/63) can reproduce this bug. > > > > > Jeremy > > > > Regards, > Roy > Thank you. I will try that out, I need to test the cpu check logic anyway. (It was more my excuse to get one :-) as my 808x hasn't been powered on in so long I'm afraid it might need some work beyond the hard drive which died long ago) Jeremy > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
perditionc--- via Freedos-devel wrote: > > On Sun, Feb 4, 2024, 7:39 AM roytam--- via Freedos-devel > wrote: >> >> Hello, >> >> perditionc--- via Freedos-devel wrote: >> > >> > On Sun, Feb 4, 2024, 6:32 AM Eric Auer via Freedos-devel >> > wrote: >> >> >> >> >> >> Hi Jim, >> >> >> >> > I'm glad you're bringing this conversation back to freedos-devel .. >> >> > because this is a good place to discuss FreeDOS things. >> >> >> >> In related news, the dosemu2 people also find the problem interesting. >> >> >> ... >> >> You don't need a real Book8088 for testing. 86Box "Xi8088" machine >> with XT-IDE(CHS=1006/16/63) can reproduce this bug. >> >> > >> > Jeremy >> > >> >> Regards, >> Roy > > > Thank you. I will try that out, I need to test the cpu check logic anyway. > (It was more my excuse to get one :-) as my 808x hasn't been powered on in so > long I'm afraid it might need some work beyond the hard drive which died long > ago) and as discussion in http://www.bttr-software.de/forum/board_entry.php?id=21061, FreeDOS can boot on Book8088 once FreeDOS' LBA support is disabled. This may because of XT-IDE BIOS and/or Xi8088 BIOS handling when Int 13h,AH=41h running twice by FreeDOS kernel. > > Jeremy > > ___________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Tree v3.7.3 Was: Re: Xcopy 1.5
On Sat, Feb 17, 2024 at 9:09 AM Wilhelm Spiegl via Freedos-devel wrote: > > Hi Jim, > thanks for your response. Xcopy is not the only thing, maybe you remember > tree 3.72 in this forum? > ... > > tree: do not know the actual situation, I got a promise that someone will > check whats the matter. > ... Good evening, Please see http://server.fdos.org/fdos/tree/TREE373.zip for an update to the tree program that should fix the issues (sorry for the long delay). Changes from tree v3.7.1/3.7.2 - reverted argument processing back to code from v3.7 [.0], the changes to use getopt were really broken - minor tweaks to included cats to default NLSPATH to ".;.\NLS", a future version will update tree to kitten - added extra check so if no serial# returned, assumes call failed and doesn't print invalid serial# (note, the way it calls int21h is a bit funky, in pdTree the carry flag is forced set before the call as I recall some kernels don't set it on error for the called function, but this version just clears struct and assumes if still clear then call failed as I'm not sure how to set the flags register prior to the int86 call (it's not the standard version, no regs struct passed) and don't have all the compiler variants easily available anymore to test changes to it. - included in the zip is all the current? message catalogs, note: these are straight from the FreeDOS nls archive on gitlab, hopefully didn't miss/mess any up. - some documentation updates to reflect that I no longer have @computer.org email address. A version 4 will be released eventually, but I'm not making any commitments for when. In the meantime, if anyone has any issues with this version, please let me know and I'll try to push out an update a little quicker. :-) (ps a new test kernel release is pending, but I'm trying to figure out/fix a driver hang during load issue first). Thanks, Jeremy ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: lspci (pciutils) for freedos
Eric Auer via Freedos-devel wrote: > > > Hi! > > LSPCI relies on a rather large list of known PCI ID, > which is why I made PCISLEEP long ago: It just has > a small list of known vendors and types, to keep the > installation small :-) It also experiments with PCI > based standby and suspend modes, including VGA ones. > > But of course, having a full LSPCI for DOS would not > hurt either, for more detailed information :-) PCI.IDS is so large that can't even able to put it on a standard 1.44MB floppy uncompressed! > > Eric > > PS: PCISLEEP is written in Assembly language. For a > DOS version of LSPCI, I suggest using BIOS calls or > raw I/O and keeping the rest in original LSPCI style. > > > > > Hi Pali, > > > > I will forward your message regarding lspci to the FreeDOS mailinglist. > > Thanks for sharing this information! > > > > Greetings, Bernd > > > >> Anfang der weitergeleiteten Nachricht: > >> > >> Von: Pali Rohár > >> Betreff: lspci (pciutils) for freedos > >> Datum: 9. März 2024 um 12:49:53 MEZ > >> An: Bernd Boeckmann > >> > >> Hello, > >> > >> I read the freedos wiki page contribute > >> https://freedos.sourceforge.io/wiki/index.php/Contribute > >> > >> and I would like to let you know that the "lspci" tool known from the > >> linux which lists and prints information about all PCI devices connected > >> in the system, works also on freedos and the last version now has > >> pre-compiled binaries in the pciutils project page. They are in windows > >> download section, but are compiled with DJGPP toolchain. > >> http://mj.ucw.cz/sw/pciutils/ > >> > >> I saw more questions from users if there is a lspci-like tool for > >> freedos to list PCI devices, so I think that the original lspci can be > >> useful for freedos. Would you consider including it into distribution CD? > >> Note that pciutils library is used by flashrom which is already present. > >> > >> Pali > > > > > > ___ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DX-FORTH?
Hi, On Wed, Mar 20, 2024 at 8:19 PM Bruce Axtens via Freedos-devel wrote: > > I stumbled over DX-FORTH this morning which purports to be "... a > Forth language compiler and development system for MS-DOS and CP/M-80 > operating systems. It is intended to be a complete, easy to use, > programming tool for the creation of turnkey applications." Is this a > language used at all in FreeDOS development? I have previously mirrored several versions of it to iBiblio for us. It's written in TASM and the bulk of it is public domain. However, I don't really grok Forth, so I've never used it much, but it looks fairly useful. * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/forth/dxforth/ Ed used to have a website, but I think he just dumps files to his Google Drive nowadays. I vaguely remember finding a newer version (two Januarys ago??). * https://groups.google.com/g/comp.lang.forth/c/Qx4GK4oJIpI/m/e4apQkQqAwAJ "ANN: DX-Forth 4.54" (Apr 29, 2023) * https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw Actually, that Drive link also shows DXDOS455.ZIP (Oct. 31) download: * https://drive.google.com/file/d/1CqIOOQ9uuenEIL-8BH3-kraxGP485GGN/view?usp=drive_link Enjoy. ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FETCH4FD
Hi, On Sat, Mar 23, 2024 at 2:14 PM Jim Hall via Freedos-devel wrote: > > And years ago, we used to include COMPINFO in a previous FreeDOS > distribution, but I don't remember why we stopped including it. If I had to > guess, probably it was the same question of "usefulness." I'd have to double check to be sure, but I believe it was old (limited) info and also had the TP7 Runtime 200 bug. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Tools for building old FreeDOS EMM386?
Hello, In freedos/files/dos/emm386/emm/2.2/emms226.zip, its makefile shows it need to use sy2pack.exe or sy3pack.exe to pack just-compiled emm386.exe. But where is sy2pack and/or sy3pack? Tried to search in the web finds only some posts in FreeDOS ML. Regards, Roy ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Tools for building old FreeDOS EMM386?
Hello, tom ehlert via Freedos-devel wrote: > > Hello, > > > In freedos/files/dos/emm386/emm/2.2/emms226.zip, its makefile shows it > > need to use sy2pack.exe or sy3pack.exe to pack just-compiled > > emm386.exe. > > sy2pack/sy3pack used to be the only compressor that was able to compress > binaries > that act both as drivers (device=himem.exe) and executable (c:>himem.exe > /test) I think it can benefit other hybrid drivers (for example JEMMX/JEMM386). > > Bart Oldemann looked at it and disassembled/reengineered it for UPX. I wonder if the effort is backported to UPX or not? > > > > But where is sy2pack and/or sy3pack? Tried to search in the web finds > > only some posts in FreeDOS ML. > > sy2pack/sy3pack is my private invention and can't be found in the wild. I wonder if they can be released (at least, binary-only) so people can use them on other things? Since it is listed in EMMS*.ZIP's makefile, reproducible builds can't be built without them. > > Tom > Regards, Roy ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license
Paul Dufresne via Freedos-devel wrote: > > Thank you ECM for the infos! > > I think my build did not finished normally. > After about 1h build time on my i3-8100, dosbox finished with: > Object Modules [.OBJ]: MAP DMA > Run file [MEM386.EXE]: EMM386.EXE > ... > del emm386.sys > File emm386.sys not found > D:\SRC > > At some point, was making some beeps while doing codepages. > But was not seeing error messages then. > > Quite interesting that the release seems to include the build tools (masm + > assembler) > > I'll try to resume what I done: > > Using DOSBOX on Linux (Following Bryan Lunduke article) > > Installed DOSBOX > git config --global core.autocrlf > Note the value because we will temporarily break git > git config --global core.autocrlf true > cd > git clone https://github.com/microsoft/MS-DOS.git > git config --global core.autocrlf [previously noted value] I think you can just break clone and checkout process into separated commands, without changing git's global options (in windows git bash prompt): $ git clone -n https://github.com/microsoft/MS-DOS.git Cloning into 'MS-DOS'... remote: Enumerating objects: 1859, done. remote: Counting objects: 100% (220/220), done. remote: Compressing objects: 100% (123/123), done. remote: Total 1859 (delta 104), reused 97 (delta 97), pack-reused 1639 Receiving objects: 100% (1859/1859), 117.41 MiB | 6.35 MiB/s, done. Resolving deltas: 100% (288/288), done. $ cd MS-DOS $ git config core.autocrlf true $ git checkout Your branch is up to date with 'origin/main'. $ cd v4.0 $ file LICENSE LICENSE: ASCII text, with CRLF line terminators > ... to fix git for future projects > sed -i -re 's/\xEF\xBF\xBD|\xC4\xBF|\xC4\xB4/#/g' > MS-DOS/v4.0/src/MAPPER/GETMSG.ASM > sed -i -re 's/\xEF\xBF\xBD|\xC4\xBF|\xC4\xB4/#/g' > MS-DOS/v4.0/src/SELECT/SELECT2.ASM > sed -i -re 's/\xEF\xBF\xBD|\xC4\xBF|\xC4\xB4/#/g' > MS-DOS/v4.0/src/SELECT/USA.INF > > paul@fedora:~$ git diff MS-DOS/v4.0/src/SETENV.BAT MS-DOS/v4.0/src/SETENV2.BAT > diff --git a/MS-DOS/v4.0/src/SETENV.BAT b/MS-DOS/v4.0/src/SETENV2.BAT > index 0a67782..928044f 100644 > --- a/MS-DOS/v4.0/src/SETENV.BAT > +++ b/MS-DOS/v4.0/src/SETENV2.BAT > @@ -6,7 +6,7 @@ set MASM= > set COUNTRY=usa-ms > set BAKROOT=d: > rem BAKROOT points to the home drive/directory of the sources. > -set LIB=%BAKROOT%\src\tools\lib > +set LIB=%BAKROOT%\src\tools\bld\lib > set INIT=%BAKROOT%\src\tools > -set INCLUDE=%BAKROOT%\src\tools\inc > -set PATH=%BAKROOT%\src\tools > +set INCLUDE=%BAKROOT%\src\tools\bld\inc > +set PATH=%BAKROOT%\src\tools;%PATH% > paul@fedora:~$ > > dosbox > mount d /home/paul/MS-DOS/v4.0 > keyb us > (needed for me... because for me it pass to french keyboard) > d: > cd src > SETENV2.BAT > nmake > > > > ___ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo
Hi, On Wed, May 22, 2024 at 11:17 AM tom ehlert via Freedos-devel wrote: > > am Mittwoch, 22. Mai 2024 um 13:14 schrieben Sie: > > it seems that no knowledgable person finds zoo interesting enough to fix it. > and those who care about zoo have no clue. > I regret that I have to say this. We had a discussion on BTTR a few months back with no obvious consensus: * https://www.bttr-software.de/forum/board_entry.php?id=21046 Do we want ZOO 2.10 (Cygwin sources) or 2.01 (public domain??) or Booz (unextract only, no subdirs) or Unzoo (new compression method only, subdir support)? If we need a Turbo C++ makefile, I can write one (since I did the same for NASM16 and NASMLITE back in 2019). _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] prog lang. year for watcom compiler/programming book list?
Hi, On Thu, May 23, 2024 at 2:02 AM Bernd Böckmann via Freedos-devel wrote: > > C in general and Open Watcom in particular are good choices for DOS > programming. > > The other free options supporting more recent C versions are GCC as part of > DJGPP targeting 32-bit DPMI, and, > despite being somewhat experimental, IA16-GCC, a port of GCC for the DOS > 16-bit real mode target. Most DOS compilers never supported C99. Although I can appreciate parts of C99, you don't really "need" it for DOS. * https://en.wikipedia.org/wiki/C99 > Not exactly with examples, but for documentation specific to Open Watcom I > recommend their PDFs and / or > the printed manuals. At least the Open Watcom C Language Reference (it is > basically ANSI C with some but > not all features of C99 and implementation specific addons) and the > programmers guide would be a good idea > to have a look at after aquiring some knowledge of the C language. The DOS reader is "whelp cguide", IIRC. Not PDF but readable in plain DOS without third-party tools. _C in a Nutshell (2nd)_ is also a good book and even covers C11: * https://www.amazon.com/Nutshell-Definitive-Reference-Peter-Prinz-dp-1491904755/dp/1491904755/ref=dp_ob_title_bk _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo
On 23.05.2024 13:56, Wilhelm Spiegl via Freedos-devel wrote: a) fdtui - a mixture between dosshell and an NC clone - please check it, I am sure you will confirm, (sorry, Berki) [Now that I have seen Jim's mail showing list services are working again, I'm sending my messages that got bounced] Just for the record, Ercan started his Ph.D. in computer science (how I envy him!), and told me that he currently doesn't have time to work on FDTUI. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo just needs packaging
On 23.05.2024 21:20, Eric Auer via Freedos-devel wrote: Apparently people somehow failed to come to a conclusion which version of ZOO to package under which license in January 2024. Zoo is in the public domain, with no strings attached. Years ago someone from Debain had sent an e-mail to Rahul Dhesi, the author of zoo, asking to relax the licensing terms a bit so it could be moved to main from non-free, and the answer was that zoo was put in the public domain. I'm unable to find that thread now, but you may want to take a look at <https://tracker.debian.org/news/244279/accepted-zoo-210-11-i386-source/>. Heh, after some time, I found a copy of the exchange: <https://launchpad.net/ubuntu/xenial/+source/zoo/+copyright>. Yet, for me, that does NOT sound like a reason to drop the whole package from our collection. Even if "nobody" uses ZOO :-p I mean barely anybody uses RUNTIME, either. But it is nice to have :-) +1. Its generations feature is nice :) _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo just needs packaging
On 23.05.2024 21:29, Bernd Böckmann via Freedos-devel wrote: I already incorporated rugxulos changes to my local copy of the ZOO FreeDOS package repository. I will push the changes as soon as I get write access to the repo. This is ZOO version 2.1. Hey, that's really nice! :) Unfortunately Debian and its derivatives no longer have zoo in the their package repositories, but while playing with NetBSD I had stumbled upon a directory traversal bug. You may want to take a look at <https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55684> for more information and further links. If this security flaw is fixed, it might be applied to NetBSD (pkgsrc) and FreeBSD too. There's also someone who has been updating zoo with bug fixes for UNIX-like platforms on <https://github.com/troglobit/zoo>, maybe cherry-picking some of them could make sense. Thanks a lot for your work on this Bernd, and if you have time, I may dig another zoo bug I had reported to Ubuntu back in the day but that's for another time. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] problems with moving in a long history
On Sun, Jun 2, 2024, 8:05 AM Bernd Böckmann via Freedos-devel < [email protected]> wrote: > > > but then I realized that since it doesn't know about it, it doesn't > actually get the full line. It does only see the first 127 characters, > > which is why you can get odd errors even though your line should be > fine, depending on where the break is... > > Nice analysis :) > > The behaviour of silently truncating the command line may even be > dangerous. Consider you are about to delete a file, and the file name > changes because of the truncation... > > > > > Makes me think that maybe we should write a FreeDOS Run-time > Initialization Routine for Open Watcom? They have the example wildargv.c. > > I'll make a note, I'll see what I can do once I start porting DOG to OW > :) Thanks again for the explanation and the resulting deep dive! :P > > If you intend to work on it, perhaps it would be good to contact jmalak, > the maintainer of the OpenWatcom v2 port, to add it directly to the > OpenWatcom v2 LIBC startup code. > > https://github.com/open-watcom/open-watcom-v2 > > Currently the programs have to handle CMDLINE by themselves. At least I do > not know any runtime that handles it by default. > > Bernd > > DJGPP is where the cmdline env and extended command line processing is from I think, that or 4DOS. it's been a while, but it was based on and made to function like existing implementations. _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS on Pocket386
On Sun, Jun 2, 2024, 12:25 PM Jerome Shidel via Freedos-devel < [email protected]> wrote: > Glad you got it working Jim. > > So, for fixing the issue… > > It would be possible to add an additional screen to the installer > (probably only advanced mode) to use the /FORCE:CHS option. > > Most likely, update the existing page to “SYS files with default boot > record, sys with CHS, don’t xfer sys files” > > Or, does the group think there is a better solution? > > Jerome > > > . That would be a good option to have, but I'd like to fix sys bootcode so lba code works and maybe make a multi sector fat32 version that supports both chs & lba. Jeremy _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] problems with moving in a long history
Hi, On Sun, Jun 2, 2024 at 7:33 AM perditionc--- via Freedos-devel wrote: > > DJGPP is where the cmdline env and extended command line processing is from I > think, that or 4DOS. > it's been a while, but it was based on and made to function like existing > implementations. I think it was a Win95 feature originally. (But yes DJGPP supports it.) _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS on Pocket386
On Mon, Jun 3, 2024, 6:26 PM Eric Auer via Freedos-devel < [email protected]> wrote: > > Hi Jim, > > from an engineering point of view, I would say LBA avoids > problems related to mismatching CHS geometries on different > computers, so I still prefer the MANUAL method where users > have to run SYS C: /FORCE:CHS before transplanting a disk > from a computer with LBA support to one without LBA. I would > recommend to avoid CHS on all computers which support LBA. > > 1. ... > > 3. Or we could give SYS support for multi-sector FAT32 boot > sectors, which would be necessary for automatic switching > on FAT32. Only FAT16 is simple enough to handle both cases > within a single sector. > > While FAT32 does support multi-sector boot sectors, I would > think that those get more easily damaged than single sectors? > > Regards, Eric > > > > > So that says that QEMU supports LBA but the BIOS on the Pocket386 does > > not. And ... > I'm thinking of adding a multi-sector boot code for fat32 to support both LBA and CHS, but possibly keeping the single sector boot code support as well. It would be a build option along with other advanced features so as to not bloat basic sys included with kernel archive. I'd like to see if I can still keep lba logic in 1st sector so if 2nd sector corrupted could still boot in happy path (lba no errors). A 3rd sector would not be used hopefully. I will see about working on this, but not until next week. I don't think anything needs to be done with installer. But we can document potential issues and fixes when moving drives from one computer to another, ie boot sector may need updating and there may be other issues if chs used and different geometry expected. Jeremy > ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] prog lang. year for watcom compiler/programming book list?
Hi, On Fri, Jun 7, 2024 at 5:14 PM Richard Stoltenberg via Freedos-devel wrote: > > Just some notes; updates. People might want to stick to the pdfs if they need > bigger font. > LibreOffice may be able to save as html. Got the C Language book from Lulu > on Monday 3rd June. I forgot that even Richard Stallman wrote a C book that he gives away for free: _GNU C Language Intro and Reference Manual_ * https://lists.gnu.org/archive/html/info-gnu/2022-09/msg5.html * https://git.savannah.nongnu.org/cgit/c-intro-and-ref.git/tree/ > I read new standards for Ansi C were updating (2018). > https://www.iso.org/standard/74528.html maybe just bug fixes. > Thanks now can try to fix code. * https://en.wikipedia.org/wiki/C23_(C_standard_revision) _______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Four in a Row (was: one more proposal for upload via fdnpkg)
Hi, On Thu, Jun 6, 2024 at 6:06 AM Jerome Shidel via Freedos-devel wrote: > > Looking around on the ibiblio and my server: > > There is a version that has a timestamp from 2019 in the ibiblio mirrored > files > > Then later, Jim found it as well in 2019 and mirrored it to ibiblio. Actually, there was a mailing list discussion (years ago) and I myself mirrored it to iBiblio for us. > I don’t see a reason that would require it to be excluded. > So, I recommend including it with the release starting with T2407. > > :-) Okay with me. ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)
Hi,
On Mon, Jun 17, 2024 at 6:42 PM Jim Hall via Freedos-devel
wrote:
>
> I wrote a "how-to" article about FreeDOS on the Pocket386 for
> Both.org, but I also copied/pasted this into a wiki article on the
> FreeDOS wiki:
>
> Now that I've reinstalled the Pocket386, my next step is to test every
> application and game from FreeDOS T2406. If you're curious how an app
> performs on FreeDOS on real hardware ('386-SX at 40 MHz, 8MB memory)
> I'll share notes in a follow-up thread.
Definitely interesting!
Since I don't have working legacy hardware anymore, I've done some
light, informal benchmarking of various tools under DOSBox-X (a "fast
486") in FreeDOS. It's definitely eye-opening (compared to my
semi-modern 2010 laptop). So things which seem instantaneous natively
run much slower when emulated. (This is actually good and lets me
optimize my code and compare compilers.)
> So far, I can report that FED is a bit slow to start up (just when I
> thought it had hung, it came up) but runs fine after that.
Is it UPX'd? LZMA compression is horribly slow on legacy cpus, that's
why it's disabled for 16-bit .EXEs by default. (Yes, I know this is a
32-bit DJGPP build.) If so, try unpacking and repacking with "--best"
instead.
A while back I tried running Linux under the web browser in a
Javascript-based emulator. It had GNU Emacs on there. Emacs took at
least a minute to boot up, but at least the syntax highlighting looked
pretty!
___
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)
Hi, On Mon, Jun 17, 2024 at 6:41 PM Jim Hall via Freedos-devel wrote: > > You might be interested in this video I recorded yesterday about > running FreeDOS on the Pocket386: > https://www.youtube.com/watch?v=2h96UseZs6Q > > It shows several apps and games on the Pocket386, mostly running some > shareware games, plus Word for DOS, and As Easy As spreadsheet. Definitely cool. More videos of testing would be interesting. Try rebuilding the FreeDOS kernel with OpenWatcom on it, heh. Or install ZipSlack [Slackware 11, 2006??] Linux atop your FAT partition, I think it supports 8 MB of RAM. (Seriously, people always suggest an old Linux distro instead of DOS, but I think that's not realistic in most ways. Still, no worse than trying to run ancient Windows 3.1.) > If you're curious about its performance, here's a quick rundown of some > games and apps: [not all of these are shown in the video] > > Games: > > - Doom - runs fine at small size I did leave a comment suggesting Fastdoom from Github, which has been specifically optimized for 386s and 486s. * https://github.com/viti95/FastDoom > - Duke Nukum - runs fine, uses PC speaker 3D, right? Not the original 2D one? > - Rise of the Triad - runs fine at small sizes, uses AdLib for sound I forgot this was 386 DOS4GW. (It's based upon an improved Wolf 3D engine, which was 286 / VGA.) I assume Wolf 3D would run faster but maybe not. Hmmm, I vaguely recall some OpenWatcom 386 rebuilds of Wolf 3D. * https://github.com/TobiasKarnat/Wolf4GW > - Shadow Warrior - doesn't run (requires 9MB, this has 8MB) I have no idea. DOS4GW 1.97 is limited in total RAM available, but it does supposedly support VM swapping. But maybe they disabled that here (and/or it's too slow to be usable). You could also try "CWSTUB blah.exe" which supports swapping, but that may not work. > - Tomb Raider - crashes during setup (not a surprise, this is a 1996 > game and requires way more memory and CPU than this laptop has - the > game should have done a memory check) I don't think the Pentium (1993 debut) was really widespread even in 1996 (too expensive), but indeed it was much faster. But I also don't think a lot of things were optimized for legacy hardware (actual 386s) even back then. Quake (1996) has no chance on this machine, for instance. > - Wolfenstein 3D - runs great! Oh, okay, you did test this (it wasn't shown in the video). > - Biomenace - runs fine 286 / EGA, I love that game! > Apps: > > - Borland Turbo C++ compiler - editor runs fine, I've used the > compiler to write a few test programs, no issues there It seems quaint, but back in the day they told us the "optional" math coprocessor was an unnecessary expense and "wasn't needed" unless we were going to do a lot of scientific calculations. Normal home users didn't "need" it. (And of course every cpu since the Pentium has it included by default, go figure. Some software like GCC always assumed an FPU present.) Even ignoring that, the 386 itself was not pipelined like the 486, so the fastest instruction was like 2 clocks. So a comparably-clocked 486 (40 Mhz) would, in theory, run twice as fast. Also 486s often had (very small) on-chip caches which helped. But as far as cpu instructions, the 486 only offered very little advantage. Some expert (Michael Abrash??) once said that the 8086 and 386 preferred small code while the 486 was very sensitive to (code and data) alignment and preferred more RISC-y simpler unrolled code. I'm far from an expert, but docs always warned about AGI stalls and using suboptimal code sequences, even suggesting "blended" code (or separate code paths for distinct cpus). One thing that always bugged me was how much slower GCC (DJGPP) got in later versions after 2.7.2.1. That version ran okay on my 486, but later versions like 2.95.3 (even with -O0) ran much slower. In the race to constantly upgrade to newer hardware, a lot of software was just never optimized properly because nobody cared enough. In fact, I recall that GCC claimed that their 486 code was just the exact same 386 code only with extra alignment. Sad, really, that it never got the full support it deserved. (You can actually rebuild GCC 2.7.2.1 in DOS, I've done it. On my old Pentium it took about 10 minutes. I miss the days when things were simpler and faster!) I don't think GCC even got Pentium support until later (2.8.1). Pentium-scheduled code (U and weaker V pipes) was a big improvement on those machines (and no huge slowdown on older cpus). Not everything can be "fixed" or optimized to run at lightning speeds on such machines, but at least some noticeable improvements are definitely possible. Seriously, most code is just suboptimal, and without proper testing on old hardware you'll never be aware of it. ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Runtime
Hi,
(Sorry for being late to this discussion, I'm a bit backlogged.)
On Thu, May 2, 2024 at 7:05 PM Jim Hall via Freedos-devel
wrote:
>
> On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
> wrote:
> [..]
> > *Runtime*
> >
> > Jim's version is a small C program, 120 lines, using catgets
> > for messages which can be translated in different languages.
> > The binary is a 22kB EXE (31kB without UPX). There were text
> > files with EN, RU, DE, HU and LV translations, I believe?
The latest version of Jim's on iBiblio appears to be 2.1d from 2005.
It has a "Borland TC makefile" using "-mm" (medium model? why?) and
-DNDEBUG in addition to linking to Kitten. The .EXE is 26 kb,
presumably UPX'd, and I'm guessing it uses floating point emulation
(which is unlikely to help much and is extra bloat that is totally
unnecessary for any Pentium or newer FPU-having cpus).
Not trying to nitpick (I've also been looking at old code of mine from
2013 called TIMEIT.C), but just FYI
1). his code isn't ANSI C89
= why include dos.h or process.h ? it says for exec() but uses
spawnvp(), I would normally prefer system()
= does that save memory? are we intentionally trying to avoid shelling
out to %COMSPEC% except for .BATs or built-ins?
= CLK_TCK is not ANSI (old 1988 POSIX???) and not at all preferred,
use CLOCKS_PER_SEC
2). Borland does use 64 kb of heap by default in the smaller data
models. To avoid that (and save a bit of memory, esp. since we're
shelling out), put "extern unsigned _heaplen = 1024;" and "extern
unsigned _stklen = 8192;" in your source. Try shelling out "mem /c" to
see the difference. (Maybe this is why he randomly chose "-mm" Medium
model?? Unnecessary, I'd just use Small.)
3). You really don't need printf() at all here (okay, maybe only for
Kitten ??). It doesn't matter as much for Turbo C, but even for
OpenWatcom it's like 6 kb. If you don't need floating point (see
below), you can make do with a simple "writelong()" routine and save
space. (Yes, I wrote such a routine, if you need it.) FYI, clock_t is
usually a typedef to a "long" integer.
4). In my program, I included both clock() and difftime(). My memory
(and notes) indicate that clock() was for integer times. You know, for
most simple uses, a round number of seconds elapsed is good enough
(and faster / smaller, no bloated and slow emulation lib or expensive
FPU needed). How often does 11 secs. versus 11.5 seconds matter?? A
naive Google search shows people advising to cast it to double! But
that defeats the whole point, IMHO. All the compilers I checked (about
a dozen) all have an integer value for CLOCKS_PER_SEC ... except Turbo
C! There it's 18.2 (for no good reason). Quick: undefine that and
redefine it to 18, that's good enough, IMHO. Or just use OpenWatcom.
> > My version is a small ASM program, made with NASM. It has
> > a main file, circa 450 lines, and a language include file,
> > circa 150 lines, which at the moment contains EN, DE, NL,
> > PT, ES, FR, TR, IT, PL and RU messages :-)
The 2012 version on iBiblio pointed to by Fritz was my unofficial hack
with EO (Esperanto) support.
Checking the latest "2024" version hosted online, it only adds HU but
omits EO. (That's fine if no one cares, but it feels like a
regression.)
> > As a task left as an exercise for the user, one could port
> > the C version to Tom's small KITTEN alternative to CATGETS.
2.1d from 2005 uses Kitten. The MAKEFILE.TC says this:
LDLIBS=kitten-b\kitten.obj
> > My preferred option would be to add HU and LV translations
> > to my small RUNTIME and use that instead of the big one ;-)
Most of that bloat can be removed in one of two ways:
1). use TC's -f87 or WCL's -fpi87 (mandatory hardware floating point
usage, no emulation)
2). use TC's -f- (avoid floating point entirely) only with
integer-friendly clock() and printf("%ld") code
> I wrote the Runtime program, so I guess I'll speak to that.
>
> This is a very old program. I don't remember why I wrote it, but I'm
> sure I was doing some debugging on a program and was trying to
> fine-tune the performance, and needed a way to test how long it took
> to run after making improvements.
A naive way would be to use "PROMPT $t" and leave a TEST.BAT without
any "@echo off", and just calculate the difference shown in your head.
FreeCOM also (non-standard) supports "time /t" to print the current time.
> There are lots of programs out there
> to track the run-time of a program on DOS, and I probably gave a quick
> look around
I forget what 4DOS uses. Some programming languages (e.g. QBASIC and
REXX) have easy timing built-in. DJGPP always
Re: [Freedos-devel] New libfp-0.0!
Hi,
On Mon, Jul 1, 2024 at 11:07 PM Jim Hall via Freedos-devel
wrote:
>
> I've been having sporadic problems today when trying to access Ibiblio
> via the web. I'm not sure if that's my end ("The connection has timed
> out") or their end. For example, I was able to download the T2407 test
> release this morning, but when I went back to Ibiblio later in the day
> to download something else, I couldn't access the website. Has anyone
> else had issues connecting to Ibiblio today?
Yes, I had trouble with iBiblio too (about two hours ago). Strange
because they are usually pretty reliable.
___________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] proposal for community development.
there is an idea for community development. synchronization with discord messenger and telegram messenger. integration with discord is seamless. telegram messenger has 1 billion users, I am sure they will find us through search even without advertising. Discord also I think will have little activity but it is very convenient, more convenient element, alas.___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] development and advertising plan
It's obvious that Freedos is dying. I can probably revive it if I take a course towards the servers. For example, you can save a lot of money if you deploy a VPN on Free DOS. I'm sure that VPN is already possible there, but it needs to be advertised. Even in this small version, Free DOS is already useful. Free DOS should be server-oriented, no one will want to sit in the console anymore (and even if you compile horg it won't help there too much...) Linux is successful because of servers. but now Linux is very heavy compared to Free DOS and you can win on this. especially if you provide ready-made builds for example for email, matrix (python is slow and complex, I know the rest for Nix OS, or does not function, so we will skip) activity pab, for example Pleroma (better not Mostadon, complex and heavy). also activity pub, Lemmy... I am not a programmer but I can help. For example, in advertising. I have a lot of knowledge. I am also a bit of a webmaster. Yes, and I have PHP SQL hosting which is free, we pay only for the domain (and the hosting domain). >I expect they will consider it unnecessary. I think so myself. There will be other proposals later. ## Domain It would be nice if with i2p and/or top so that a person could not pay for domains, and in general. And it would also be good to buy a short domain and make a free ddns for free dos users. then because of the freebies people would install servers on old devices (for many people electricity is free or very cheap)._______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] development and advertising plan
I know about web servers for Free DOS. But so far it is only for static content. If you use it for a static site like Hugo then maybe. It's all pointless while electricity is more expensive than hosting. That's why you need to do more complicated things like a Pleroma server, DNS... To make it profitable, use outdated PCs. -- Reply to message Date: Sat, 13 Jul 2024 01:03:47 +0300 From: Eric Auer via Freedos-devel CC: Eric Auer , Hi [email protected] > It's obvious that Freedos is dying. What makes you think so? > I can probably revive it if I take a course towards the servers. Which servers? > For example, you can save a lot of money if you deploy a VPN on Free DOS. Linux is better for that and zero already is a very good price. > I'm sure that VPN is already possible there, but it needs to be > advertised. Even in this small version, Free DOS is already useful. I am not aware of a VPN for FreeDOS. But there are DOS web servers: https://lunduke.substack.com/p/how-to-run-a-dos-based-web-server > Free DOS should be server-oriented, no one will want to sit in the console > anymore (and even if you compile horg it won't help there too much...) Part of the fun of FreeDOS is that it is simple and console oriented. > Linux is successful because of servers. but now Linux is very heavy > compared to Free DOS and you can win on this. especially if you provide > ready-made builds for example for email, matrix (python is slow ... > activity pab, for example Pleroma (better not Mostadon, complex ... Linux and Android are very lightweight: They even run on phones. People use phones as hotspot servers (WiFi access points) already. > I am not a programmer but I can help. For example, in advertising. Get deep knowledge about the product first, then suggest a campaign. > I have PHP SQL hosting which is free, we pay only for the domain You mean a domain like https://freedos.org/ ? > ... buy a short domain and make a free ddns for free dos users. A DynDNS like armored.fdos.org? What would YOU like to host there? > then because of the freebies people would install servers on old > devices (for many people electricity is free or very cheap). They would have to find a device old enough for FreeDOS first. Eric ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel_______ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] development and advertising plan
First of all, I know what a house is. And of course, I first used your OS four years ago. Just to run classic games. By the way, it works great, much better than many emulators. now few people want to sit and look at the console. except for launching classic games or a server. and VPN is not the best thing that can be done with a server. but if it was possible to place servers on it, for example, activity pub and this was known, then their popularity would grow since such equipment is not suitable for much (4-256 MB RAM, for example) -- Reply to message Date: Sat, 13 Jul 2024 01:06:49 +0300 From: Jim Hall via Freedos-devel CC: Jim Hall , First, I'll say that this appears to be either a troll or spam. Opening with "FreeDOS is dying" is a classic troll "opening." And there's a note in there that seems to be a discussion with someone else that was accidentally copied/pasted into the email, but shouldn't have been: > > I expect they will consider it unnecessary. I think so myself. There > > will be other proposals later. > > > > ## Domain And while I usually don't reply to trolls or spam, I'll reply briefly anyway: At best, this is someone who doesn't understand what DOS is. And we get these emails from time to time - I know that I get emails at my personal address from people who have just discovered FreeDOS, and maybe tried to install it, but they don't know what "DOS" is or how to use it. And then they suggest some odd ideas, like "you should make FreeDOS for a Samsung watch" or "you should port FreeDOS to an Amiga" or something else. This person is suggesting turning FreeDOS into some kind of server-oriented platform, like a FreeDOS VPN. FreeDOS is an open source DOS-compatible operating system that you can use to play classic DOS games, run legacy business software, or write new DOS programs. That's the goal. We're an open source DOS. It's clearly a troll. Don't feed the trolls. On Fri, Jul 12, 2024 at 4:45 PM armored--- via Freedos-devel wrote: > It's obvious that Freedos is dying. I can probably revive it if I take > a course towards the servers. > > For example, you can save a lot of money if you deploy a VPN on Free > DOS. I'm sure that VPN is already possible there, but it needs to be > advertised. Even in this small version, Free DOS is already useful. Free > DOS should be server-oriented, no one will want to sit in the console > anymore (and even if you compile horg it won't help there too much...) > > Linux is successful because of servers. but now Linux is very heavy > compared to Free DOS and you can win on this. especially if you provide > ready-made builds for example for email, matrix (python is slow and > complex, I know the rest for Nix OS, or does not function, so we will > skip) activity pab, for example Pleroma (better not Mostadon, complex > and heavy). also activity pub, Lemmy... > > I am not a programmer but I can help. For example, in advertising. I > have a lot of knowledge. I am also a bit of a webmaster. Yes, and I > have PHP SQL hosting which is free, we pay only for the domain (and > the hosting domain). > > > I expect they will consider it unnecessary. I think so myself. There > > will be other proposals later. > > > > ## Domain > > It would be nice if with i2p and/or top so that a person could not > pay for domains, and in general. > > And it would also be good to buy a short domain and make a free ddns > for free dos users. > > then because of the freebies people would install servers on old devices > (for many people electricity is free or very cheap). ___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] development and advertising plan
I don't understand what made you laugh -- Reply to message Date: Sat, 13 Jul 2024 09:41:53 +0300 From: Ralf Quint via Freedos-devel CC: Ralf Quint , On 7/12/2024 3:05 PM, Jim Hall via Freedos-devel wrote: > First, I'll say that this appears to be either a troll or spam. > Opening with "FreeDOS is dying" is a classic troll "opening." And > there's a note in there that seems to be a discussion with someone > else that was accidentally copied/pasted into the email, but shouldn't > have been: Well, after a long hard day, this post had me in stitches for quite a while. I know we get someone who know everything better at least two or three times a year, but this is clearly from one of the most delusional folks that ever made it onto the mailing list.. Ralf (still laughing) 😛 ___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel___________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
