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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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=20 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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: th...@yamashita1921.com 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: webmas...@propstei-marien.de > 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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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=FreeBSD+13.2-RELEASE+and+Ports * https://man.openbsd.org/hexdump.1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
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 Freedos-devel@lists.sourceforge.net 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 worked around in DJGPP "patchlevel 2" to 2.03 (aka 2.03p2). So apps com
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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
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 making a > clicking noise, which I let run for 15 minutes or something > before switching off the computer. * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2043/ Contents of release zip files: ke20xx_16.zip : binaries for 8086, FAT16 ke20xx_32.zip : binaries for 8086, FAT16, FAT32 ke20xxsrc.zip : sources for the kernel * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/0.85a/ANNOUNCE (I assume these are the latest versions. Someone please correct me if not.)
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 2006 stable one was 186). What else did you rely upon? I would definitely not bother with old MS-DOS. > Linus said that his Unix would never be as sophisticated as > what was it? SCO? I've forgotten. Almost no-one else has even > heard of it to even forget. Linus has said that if FreeBSD's 386 kernel was already available, he
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 Freedos-devel@lists.sourceforge.net 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] a good app launcher and file manager that doesn't try to be a GUI > > GEM is a good low-end GUI and it has apps. It's not a great DOS app launcher. > > 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
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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDISK 1.3.7 and HTMLHELP 5.3.6
Hi, On Mon, Jun 26, 2023 at 5:56 AM Bernd Böckmann via Freedos-devel wrote: > > I released FDISK 1.3.7. > > I also pushed HTMLHELP 5.3.6 to the unstable branch at gitlab. > > It everything goes well both should be included in the next interim build. Thank you for your work on these. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
Hi, On Mon, May 22, 2023 at 11:04 AM wrote: > > On May 22, 2023, at 7:03 AM, Rugxulo wrote: > > On Mon, May 15, 2023 at 6:48 PM wrote: > >> > >> Let me show you a MEM print out from my Pentium Pro: > >> > >> NANSI3,536(3K) 0(0K) 3,536(3K) > >> SHSURDRV 400(0K) 0(0K)400(0K) > >> LBACACHE10,576 (10K) 0(0K) 10,576 (10K) > >> CTMOUSE 3,104(3K) 0(0K) 3,104(3K) > > > > NNANSI [sic] can unload, so if you switch to that, all of these can > > optionally be unloaded (if you put them last) to free up memory. Of > > course, SHSURDRV will also unload your whole XMS RAM disk, too. > > Sure. But... > > Even with loading and keeping all that stuff, the system still has 94K free > upper memory and 84K of that is consecutive. > > Unloading those drivers would not free up the 11K of Low memory used by the > Kernel. > It would just free upper memory of which there is plenty. My bad, I didn't notice and assumed it was all in conventional. > The largest executable size is 628K. > Nothing should every require over 600K of low memory to load. I agree that 600 kb is too much for any reasonable app, but it does sometimes happen (esp. games). I think I saw a demoscene app once that also required that much. Very wasteful. (But even DOS compilers aren't that lean and mean. Smartlinking and overlays are a lost art.) > Actually, that MEM print out is outdated for that machine. Just to use up > some more upper memory, > it now loads CWSDMPI at boot. That brings free upper memory down to about > 45K. But if upper memory > gets too low or their are compatibility issues, I’ll stop loading it at boot. It's 32-bit "DPMI only", no "extensions". So OpenWatcom 32-bit or old Borland 16-bit DPMI stuff might complain. You might also want to disable swapping via CWSPARAM for your old hard drive since it tries to create a CWSDPMI.SWP file by default on C:\ drive. > Side Note: At boot, the system transfers the main OS files over to RAM disk, > reconfigures the environment > accordingly and primarily runs from RAM. Much better performance. A lot less > wear and tear on 25+ > year old drives. Besides, it has got to do something with all that RAM under > DOS. Oh, absolutely, it's way faster in RAM, even compared to USB jump drives. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
Hi, On Mon, May 15, 2023 at 6:48 PM wrote: > > Let me show you a MEM print out from my Pentium Pro: > > NANSI3,536(3K) 0(0K) 3,536(3K) > SHSURDRV 400(0K) 0(0K)400(0K) > LBACACHE10,576 (10K) 0(0K) 10,576 (10K) > CTMOUSE 3,104(3K) 0(0K) 3,104(3K) NNANSI [sic] can unload, so if you switch to that, all of these can optionally be unloaded (if you put them last) to free up memory. Of course, SHSURDRV will also unload your whole XMS RAM disk, too. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] CPU flags register not updating on interrupt calls
Hi, On Sun, Apr 30, 2023 at 4:54 PM wrote: > > In, kernel/pcb.h, I see some notes about “offsets must match the assembly > process” > and a couple of different layouts for the offsets. Could this be related to > the issue I am having? > I am using NASM 2.16.01 and Watcom 1.9. Someone reported that there was a regression in OMF/OBJ for NASM 2.16.01 regarding 16-bit segments. Try reverting to NASM 2.15.05 instead: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/2.15.05/ Or, for really having fun, try the ancient 0.98.39 16-bit version: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal bug [off-list]
Hi,
On Wed, Apr 12, 2023 at 7:10 PM Jim Hall wrote:
>
> > I believe this is a Free Pascal issue because the short
> > hello world test works, but if you decide to use any
> > objects, the Video unit is completely missing.
I don't do a lot of graphical programming, so I'm unfamiliar with the
"Video" unit.
"9 Units that come with Free Pascal"
"9.1 Standard units"
* https://www.freepascal.org/docs-html/user/userse47.html#x157-1640009.1
It lists several, including "video":
"
video
Provides basic screen handling in a platform independent way, and
supports writing custom drivers.
"
I don't think this is meant to be "{$mode tp}" [turbo] compatible
(which only had "graph" and text mode "crt").
What are they trying to do, SVGA? VESA? Maybe something like Allegro
(lib) could help.
> > There is
> > reference to consolidation of the video functions but no
> > references to where the the functions in that unit went.
It's probably only used internally by some FPC utils, if even that
much. Maybe it has no maintainer or bitrotted, I don't know. But I've
never seen it used.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bug 0x5801/41
Hi, On Fri, Apr 7, 2023 at 11:46 AM tom ehlert wrote: > > and - well I understand that kernel version control is a complete > mess - but Kernel 0.85a seems a bit unlikely given that > https://github.com/FDOS/kernel/blob/master/docs/history.txt refers to > 0.42. * https://github.com/FDOS/kernel ... says this: "FreeDOS kernel - current 0xFD version is 2.43 (2043)" Try "ver /r" if in doubt. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, On Mon, Mar 20, 2023 at 5:20 PM Rugxulo wrote: > > On Mon, Mar 20, 2023 at 5:06 PM Bret Johnson wrote: > > > > This is something much more serious than a "tradeoff" or a > > "regression". My new i5 CPU appears to be spending _at least_ 99% > > of its resources NOT processing OpCodes and NOT accessing the > > cache (because there isn't one). And the problem is blamed on > > "sub-optimal code". I don't know what the CPU is doing with all > > those resources it has, but I do know what it's NOT doing. I do know > > that what's going on inside a CPU is very complicated. Call me naive, > > but I always thought the primary purpose of a CPU was to process > > OpCodes. Silly me. > > > > >> I think it probably > > >> would be -- I certainly think it would be WAY faster than my 3.3 GHz > > >> i5. > > > > > nope. > > > > Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5? > > And again, I know it doesn't make any sense, but it's still true. > > Self-modifying code?? Seriously, older machines were faster with self-modifying code, but newer ones are much more sensitive and slower. Anything within a (roughly) 4 kb radius gets slowed down dramatically. I noticed this, years ago, on my old AMD TK53x2 laptop. * https://en.wikipedia.org/wiki/Self-modifying_code#Interaction_of_cache_and_self-modifying_code "In some cases short sections of self-modifying code execute more slowly on modern processors. This is because a modern processor will usually try to keep blocks of code in its cache memory. Each time the program rewrites a part of itself, the rewritten part must be loaded into the cache again, which results in a slight delay, if the modified codelet shares the same cache line with the modifying code, as is the case when the modified memory address is located within a few bytes to the one of the modifying code." "PC processors must handle self-modifying code correctly for backwards compatibility reasons but they are far from efficient at doing so." Maybe speculative execution is affected by this, too? * https://en.wikipedia.org/wiki/Speculative_execution ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi again, On Mon, Mar 20, 2023 at 5:06 PM Bret Johnson wrote: > > This is something much more serious than a "tradeoff" or a > "regression". My new i5 CPU appears to be spending _at least_ 99% > of its resources NOT processing OpCodes and NOT accessing the > cache (because there isn't one). And the problem is blamed on > "sub-optimal code". I don't know what the CPU is doing with all > those resources it has, but I do know what it's NOT doing. I do know > that what's going on inside a CPU is very complicated. Call me naive, > but I always thought the primary purpose of a CPU was to process > OpCodes. Silly me. > > >> I think it probably > >> would be -- I certainly think it would be WAY faster than my 3.3 GHz > >> i5. > > > nope. > > Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5? > And again, I know it doesn't make any sense, but it's still true. Self-modifying code?? (joking) Or maybe you have FDAPM loaded? ;-) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] How to setup a compiler for FreePascal on Fedora Linux to FreeDOS 16 bit
Hi, On Sun, Mar 19, 2023 at 11:16 PM Paul Dufresne via Freedos-devel wrote: > > I am thinking about using FreePascal to write programs for DOS. > > Writing an "hello world" program in FreePascal for 32 bit DOS (Go32) is easy, > because the fpc package can be installed > with fdimples from the Live installer. > > But there is no 16 bit FreePascal directly for DOS. > So one have to used some other OS like Windows or Linux, and use a FreePascal > cross-compiler to 80186 16 bit DOS. If you unpack / install the Windows version (ppcross8086), you can then use it with HX DOS extender (so both DOS host and target): * https://github.com/Baron-von-Riedesel/HX/releases > I say 80186, because this is the precompiled version, you would have to > compile your own cross-compiler for like 386 16 bit DOS. > And now I am realizing that 80186 is kind of too advanced for FreeDos that > prefer 8086... but I think the older > FreePascal can do is 80186. Like you later mentioned, it does also support 8086 (and 286, 386 ... not sure how "improved" those are, though). > Rather than using fpc to compile a .pas file, you use: ppcross8086 > as describe in: > https://wiki.freepascal.org/DOS > which is not too clear, that's why I am writing this. The Wiki is a bit outdated (esp. now that it's not only a snapshot but an official release). But generally you use a (separate) cross compiler for anything other than 386 (i.e. ppc386). Even the 64-bit compiler (ppcx64) is a cross compiler, IIRC. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I wish I had a boot.log file
So you want a TEE utility? Or just to single step through it all (F8)? Try pressing the Pause key. (Yes, I know that's timing sensitive, sorry.) On Sun, Mar 19, 2023 at 10:30 AM Paul Dufresne via Freedos-devel wrote: > > So many messages on boot I cannot scroll back. > If only the boot process would also copy everything in a boot.log file! ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
Hi, On Fri, Mar 17, 2023 at 5:32 AM wrote: > > At present, the FreeDOS installed system and installer boot media load FDAPM > on many hardware configurations and virtual machines. > > As most are aware, there has recently discussed issue that the watcom > installer was taking an excessively long time to install. The problem only > occurred when FDAPM was loaded. This was regardless of which power saving > options were used. Should we cut back on when it is loaded? I almost forgot that the Borland IDE tools were also slowed down when FDAPM was loaded. That is a known issue. > What I’m thinking is we more or less keep things as they are. But, add an > exception to the various AUTOEXEC files that skips loading it as a driver > when the OS is running under a known VM like VirtualBox, VMware, etc. > > Any thoughts? Yeah, just turn it off if under a VM (and document why with a REM comment). Oh, and turn on IDLEHALT like Tom suggests. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
Hi, Just for completeness On Thu, Mar 9, 2023 at 4:22 PM Eric Auer wrote: > > This is a self-extracting ZIP file. You can try using our > build of infozip UNZIP to extract it. Maybe the downloaded > exe uses build settings which are not fast for DOS or which > expect more than 32 MB RAM. Maybe it even uses a swapfile? It does use the Causeway extender, which indeed can swap. Unless they changed something, the old behavior was to swap the ENTIRE amount of used memory to disk (if needed), not just the extra part needed (a la CWSDPMI). So 37 MB RAM usage (e.g. paq8o8z) on a 32 MB physical RAM computer (my old Pentium) would swap all 37 MB (while CWSDPMI would only swap 5 MB). > I also expect that extracting 4000 files in DOS, some of > the directories containing 100s of files (samples/clibexam, > h/nt, binw, binnt, ...) to be slow without a decent cache > and generally slow because our caches do not write-combine. > > If you had 500 MB RAM, you could extract to a RAMDISK ;-) I always favored large RAM disks for MetaDOS. Heck, I also do that for my bootable USB drive for increased speed (since flash is roughly 2x slower to read and 5x slower to write). It's faster to do compilations that way. > You could test how long it takes to extract the files > in Windows and then boot FreeDOS and use either COPY or > XCOPY, with or without a cache, to copy it. I remember > a thread where I suggested an XCOPY patch to pre-allocate > all clusters before incrementally copying file contents, > in order to avoid frequent incremental FAT updates, but > I do not remember whether pre-compiled XCOPY binaries > with this patch are available. It may improve speed :-) IIRC, Doszip (Hjort) used your tip for faster copies: * http://www.bttr-software.de/forum/board_entry.php?id=8862#p8879 BTW, I've never seen any huge slowdowns in FreeDOS. This report was a bit scary to me! But luckily it was (AFAIK) a false alarm. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
Hi, On Mon, Mar 13, 2023 at 4:26 AM Wilhelm Spiegl wrote: > > after several tests I found the reason for this strange behaviour. > It disappeared when I booted from a virtual diskette without fdconfig / > fdauto.bat and executed watcom.exe. Same from HD. > Then I added fdconfig again - it was still fast. > Finally I found out that line (in about 62) caused be brake. > "lh fdapm apmdos" > This command appears three times in the autoexec.bat (lines 40, 62, 76, maybe > it varies a little) and is used there depending on the machine types. > Putting the command "lh fdapm apmdos" to "rem" made the watcom.exe > installation file work as it should. > > I asked Eric Auer, he recommended tests without "lh" - or replacing apmdos > by the softer "fdapm ADV:REG" but this gave the same slow > speed I had before. > > So I wonder if it is really necessary to install energy saving in FreeDOS > live CD, or, at least to check where > the machine runs (bare metal or vm which needs more engergy at all). IIRC, there's also a FDCONFIG setting of IDLEHALT which can already help somewhat. Outside of applications which constantly poll, it should reduce (virtual) cpu usage to less than maximum. Anyways, I just now booted up old QEMU 6.1.0 (64-bit) atop dead Win7 and used MetaDOS 0.7 (kernel 2041, 128 MB RAM, half of that is RAM drive) with old curl 7.64.1 to grab the relevant OW 2.0-c installer .EXE (which uses Causeway). Grabbing 140 MB with Curl took me five minutes. Installing a not-quite-full DOS toolset (roughly 33 MB) took two minutes. This was atop a virtual hard disk (FAT16) of 510 MB, no VT-X needed! NASM 0.98.39 (16-bit) built and worked okay, so did MiniSed, so did p2c. What didn't work was compiling TinyAsm (for some unknown reason, probably a bug). So I guess this issue can be closed. (Further testing results are still welcome.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, On Thu, Mar 9, 2023 at 4:29 PM Bret Johnson wrote: > > The computer I'm currently using is a few years old, old enough that I can > boot DOS on the actual hardware. > The CPU is an Intel i5-4590 running at 3.30 GHz. * https://www.intel.com/content/www/us/en/products/sku/80815/intel-core-i54590-processor-6m-cache-up-to-3-70-ghz/specifications.html So four cores? But only one core is running under DOS (albeit at max clock speed). But even "Turbo Boost" depends on your motherboard and BIOS enabling it for you. It doesn't go into detail about cache beyond saying "6 MB smart cache". I assume most of that is L3, then some L2, with a very small L1 (usually like 64 kb split between instructions and data ... not sure about writeback). Hey, I'm a noob, but some things are faster than others. The Pentium (586) had 8 kb cache, right? And the 486 was much more sensitive to code alignment. But the Pentium had U and (weaker) V pipes while the 486 was only pipelined. I think the Pentium 2 (686) was when they started adding "out of order" instruction rescheduling. Things like ALU or barrel shifter or register renaming or branch prediction also matter. > I have a DOS program I wrote a long time ago, called SLOWDOWN (and hope to > find time to "update" it in the future). The purpose of SLOWDOWN is to slow > the computer down so that DOS applications don't "blow up" because the > computer is too fast. It's not a perfect solution, but is useful in certain > situations. > > One of the things SLOWDOWN needs to do is figure out how fast the computer is > running so that it can slow it down the correct amount when you want to do > that. So, SLOWDOWN can sort of be used as a "benchmark" to see how fast your > computer actually is. > > For my test, I compared how fast my current computer runs (with a 3.30 GHz > clock speed) against a 33 MHz 386 CPU (which I measured way back when -- I > don't have access to that computer any more). At least in theory, because my > current clock speed is 100 times as fast as the 386, my current computer > should run _at least_ 100 times as fast as the 386 did. Also, at least in > theory, it should be even faster than that since the new computer has a cache > and the 386 didn't, modern CPU's take fewer clock cycles per CPU instruction, > etc. So what instructions are you testing? The original Pentium (586 circa 1993) had a pipelined FPU that Quake utilized in their hand-optimized code. Also, all Pentiums below 120 Mhz had the FDIV bug. Surely some of the slowest instructions are DIV / IDIV. > In fact, the new 3.3 GHz i5 CPU runs about 10 times faster than the 33 MHz > 386 did, not more than 100 times like you would expect. Floppy is always slow, optical drives are slow, virtual memory is slow, etc. Even networking can be slow. USB flash drives tend to be twice as slow to read and five times as slow to write. So a software cache and a RAM disk can help a lot. > I then ran a second test where I disabled the cache on the CPU (you can do > this with my CPUCACHE program which is included with SLOWDOWN). This is a > more "apples-to-apples" comparison of the _actual_ CPU speed than the > original test with the cache enabled. When I did this test, the computer ran > almost exactly the same speed as the 33 MHz 386 (it was about 3% faster, not > 10,000% faster as "logic" would dictate). There is something VERY wrong > going on here. I suspect you may not believe my results, but they are > nonetheless real. Sometimes regressions happen. It's a tradeoff. The Pentium 4 was worse at "inc eax" than "add eax,1". It also didn't have a barrel shifter, so shifts like "shl eax,1" were slower than "add eax,eax". That cpu was deeply pipelined, meant to scale up in raw clock speed (not to mention new SSE2 instructions). Like I said, early P4s were slower than high-end P3s. Newer cpus do usually need a recompile to be maximally efficient (for various obscure reasons). Here I'm also thinking of weird things like (SSE3) FISTTP and (FPU) FNSAVE / FXSAVE, not to mention weird optimizations like "REP RET" or "RET 0". (They also used to say "don't use LOOP, it's slow", but AMD sped it up again.) I've also noticed that some of my (semi-modern) cpus run (186) ENTER much much slower than its 8086 instruction equivalents. Not sure why, maybe they didn't think anyone would use it (most don't anymore, but some old compilers do). > So, given this real-life data, how exactly is what I said untrue, > oversimplified, inaccurate, unrepresentative, or any other similar adjective > you would choose to use? According to the theory, what I said can't be true, > and yet it is. I'm sure somebody will claim something like, "modern CPU's > are optimized for modern applications so you can't expect them to run old > stuff, like DOS, very well." Well, I think it's pretty unreasonable to > expect a modern 3.3 GHz i5 CPU to run at almost the exact same speed as a 33 > MHz 386 and with a
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
Hi,
On Wed, Mar 8, 2023 at 3:12 PM Volkert via Freedos-devel
wrote:
>
> 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 does BUFFERS (config.sys) say?
What kernel version (ver /r)? Try again with an older (e.g. 2041) kernel.
Is this atop FAT16 or FAT32?
What host and guest cpus are you using?
How much RAM is available? (Use more than 64 MB.)
Does anyone know what extender (e.g. Causeway) the installer is using?
What VirtualBox version? Is VT-X enabled? (Recent versions only run on
64-bit hosts with VT-X enabled.)
And yes, disable DOSLFN ("doslfn d") first, if it's loaded.
(Sorry, I haven't tried it myself.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, On Wed, Mar 8, 2023 at 8:57 AM Liam Proven wrote: > > On Tue, 7 Mar 2023 at 14:50, Bret Johnson wrote: > > > The problem is, the CPU's _themselves_ really haven't gotten a whole lot > > faster than they were in the 386 days. > > Drastic oversimplification to the point of not being true, accurate or > representative. I'm not sure what he meant there (N.B. not a big deal) nor whether he meant a literal 386. Because the 486 was twice as fast as the 386 at the same clock speed. (The fastest 386 instruction was 2 cycles.) Was he comparing it to RISC design? The Pentium Pro was atrocious at 16-bit code, focusing on 32-bit. And early Pentium 4 models were slower than fast Pentium 3s! In particular, the Pentium 4 was redesigned to be able to scale up to 10 Ghz, but my the time the Pentium-D (3-ish Ghz) came out, it used too much power, so they scrapped it and went back to the Pentium-M (IIRC, the mobile Pentium 3 with SSE2) for the future Core 2 cpus (2006). Even compared to 2004, a lot has improved in cpus, so yes they are overall much faster. * https://www.phoronix.com/news/2004-CPU-3990X-Plus-FX-9590 > I'd say Koomey's Law replaced Moore's Law circa 2007-2008, when the > x86 industry went through the multicore transition. From ~1975 to > ~2005: CPU bandwidth approximately doubled every ~1½ years. Since > ~2005: bandwidth increases ~10% every 1½ years. Wikipedia says "Moore's law is the observation that the number of transistors in a dense integrated circuit (IC) doubles about every two years." This does not strictly mean performance improvements, but most people interpret it thus anyways. Either way, I've enjoyed FreeDOS (in one form or another) on whatever machine I could find. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi again, On Tue, Mar 7, 2023 at 12:41 PM Rugxulo wrote: > > On Tue, Mar 7, 2023 at 8:50 AM Bret Johnson wrote: > > > > That model sort of illustrates the concept, though. Both Windows and Linux > > want to manage the _entire_ machine's > > resources while they are running and one OS must give give up that control > > to let the other OS take over. > > I'm proposing that the control be outside either OS -- in a sense, give it > > back to the "BIOS". The "BIOS" in this case > > can be considered a common Hardware Abstraction Layer (HAL) that all OS's > > can share, but it could be "subdivided" > > (e.g., a "memory BIOS" and an I/O BIOS" and ...). Some might consider that > > a step backwards, but I'm not so sure. > > The direction we've been heading may actually be backwards, or at least a > > dead-end. > > Maybe you mean something like this? > > "Apple’s MS-DOS Compatible 486 Macintosh from 1995!" -- LGR Or maybe something like this? * https://en.wikipedia.org/wiki/Genode ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Interim Build T2303
Hi, On Tue, Mar 7, 2023 at 5:59 AM wrote: > > > On Mar 6, 2023, at 10:19 AM, Bernd Boeckmann via Freedos-devel > > wrote: > > > > I noticed edlin32 2.21 is not working because of missing dos4gw.exe, but > > perhaps that is already obsoleted by the 2.22 release? A quick fix is copying CWSTUB.EXE (Causeway) to DOS4GW.EXE. Then it should work. Or run WDOSX's STUBIT on it. > Gregory has only been releasing edlin updates in source form. That requires > me to compile them. > For most projects, if a precompiled binary is not provided, I won’t compile > them. It get’s to be a very > time consuming process putting all the dependencies together and a successful > compile. At least > for edlin, that is not the case and it is not difficult to compile. But that > is all I do, I don’t go through > the process of attaching a stub to the 32-bit version. So, it still requires > the external dos4gw. > Which as you noted is not normally present. Use the "-l=causeway" flag with WCL386 to attach it when compiling and linking. > Maybe, I should just not bother compiling the 32-bit version for DOS. I think normally 16-bit Edlin is compiled with the Compact model, right? It doesn't mean someone somewhere wouldn't also need a 32-bit pmode version, but I think a 16-bit Compact build is good enough for our needs. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, On Tue, Mar 7, 2023 at 8:50 AM Bret Johnson wrote: > > That model sort of illustrates the concept, though. Both Windows and Linux > want to manage the _entire_ machine's > resources while they are running and one OS must give give up that control to > let the other OS take over. > I'm proposing that the control be outside either OS -- in a sense, give it > back to the "BIOS". The "BIOS" in this case > can be considered a common Hardware Abstraction Layer (HAL) that all OS's can > share, but it could be "subdivided" > (e.g., a "memory BIOS" and an I/O BIOS" and ...). Some might consider that a > step backwards, but I'm not so sure. > The direction we've been heading may actually be backwards, or at least a > dead-end. Maybe you mean something like this? "Apple’s MS-DOS Compatible 486 Macintosh from 1995!" -- LGR "The Power Macintosh 6100/66 DOS Compatible is a fascinating machine. For $2,199 in 1995 you got MS-DOS and Mac OS in one computer, thanks to an Intel 486 and a PowerPC 601 inside! Yeah, mid-90s Apple was rather amusing." * https://youtu.be/9UclHrIIaYA ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, Apologies if this is *slightly* off-topic. On Fri, Mar 3, 2023 at 7:01 PM Bret Johnson wrote: > > Let me just say that the computing world would be a VERY different place than > it is now if Operating Systems > (and maybe even BIOS's) were re-entrant. For one thing, MS probably never > would have became the monolith it did. > I'm not necessarily saying I think it would have been a GOOD idea, but just > that things would be different. The BIOS idea (separate, in ROM) was invented by Gary Kildall, right? Apparently CP/M-86 had a billion derivatives including (according to Wikipedia) Concurrent CP/M-86 3.1 with optional PC-MODE, aka "Concurrent DOS", which eventually evolved into DR-DOS. * https://en.wikipedia.org/wiki/Multiuser_DOS#PCMODE There was also (DR) Novell DOS 7, which supported 286 task swapping and 386 multitasking. And many other (unreleased) projects like "Star Trek": running Mac OS 7 atop Novell DOS on x86. * https://en.wikipedia.org/wiki/Star_Trek_project But Caldera focused on Linux, so even when they won their lawsuit against MS, they didn't really develop DR-DOS past 7.03 in 1999. (Tiny point releases were made to OEMs or other vendors.) I don't really understand it. It's hard to blame MS for everything. DR clearly had a lot of good releases, but many of them never caught on. I guess when you already have OS/2 and Windows and DOS (and Linux and ...), you don't need ten bazillion more. (I used to fervently read OSNews and try things in VMs or burn CDs to boot. Certainly there are dozens of worthy OSes.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] MS-DOG (was Re: [Freedos-user] FSF)
Hi again, I was thinking about this old email and thought I should clarify (in a technical sense). (comments below) On Wed, Mar 31, 2021 at 6:56 PM Jim Hall wrote: > > Here's the thing: I've had years of direct experience with Stallman. > > He calls DOS a "DOG operating system." The FSF and GNU websites > actually referred to MS-DOS as "the M$-DOG operating system" for > years. When I talked to Stallman about it, he doubled down on that > statement and said I was a "DOG man" because I worked on FreeDOS. And > he said anyone who uses FreeDOS is a "DOG user." Maybe Stallman > thought that was funny. FreeDOS is my favorite operating system. I've spent thousands of hours playing with it. I also like dogs, so never would I be offended by being called a "dog man". It's entirely possible that Richard dislikes DOS that much. It's also possible that he was just being funny. Either explanation is irrelevant because our enjoyment and use of FreeDOS does not rely on his preferences. "A poor carpenter blames his tools." But FSF used to sell CD-ROMs with DJGPP binaries. "Current" DJGPP 2.05 has Emacs 28.2 and GCC 12.2. So how bad can DOS be? I actually am pretty sure that "MSDOG" is an old article by Morten Welinder (a big contributor to DJGPP and Emacs back in the day). * http://www.delorie.com/djgpp/doc/msdog.html * https://www.gnu.org/software/emacs/manual/html_node/emacs/Acknowledgments.html The article by Morten is mostly technical in complaints but also obsolete (written in 1995). It covers "file system", "kernel", "shell" (the main culprit, by far), and "utilities". (Don't like FreeDOS? Fix it! "Patches welcome.") A lot of it doesn't apply universally to all DOSes anymore. It mostly targets MS-DOS 6.22. So specific bugs don't exist with other vendors, and all known improvements and workarounds are not mentioned (solving at least 80% of the problems). In particular, like I said, Morten contributed to DJGPP, which was always a *huge* boon to developers with many excellent tools that (also) avoided or fixed most of these problems. If the default DOS shell is despised as too weak or buggy (e.g. GNU Make wisely avoids it, if possible), there are plenty of other scripting tools available. In summary, out of 38 complaints: improved: 1, 3, 7, 8 workaround: 9, 15, 16, 17, 23, 25, 27, 30 vendor-specific: 2, 4, 5, 6, 10, 14, 18, 21, 22, 26, 28, 29, 33, 34, 35, 37, 38 irrelevant: 11, 12, 13, 19, 20, 24, 31, 32, 36 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Mon, Feb 27, 2023 at 5:59 PM Aitor Santamaría wrote: > > As a matter of curiosity, given that we were unable to find a precise answer > to why Microsoft dropped IFS after MS-DOS 5.0 (although we had speculations), > I thought, why not ask ChatGPT (Bing) about that? > > I had hoped that there was some page that we weren't unable to find. Or even > it could have been better if ChatGPT had any access to information from > Microsoft that was not easily publicly accessible. > Neither seems to be true. Search engines are notoriously bad for anything niche. Heck, even popular stuff gives lots of wrong answers. There's still info out there, but you have to ask the right person. Most stuff is tucked away in storage or hidden in some retired guru's brain. The tech world overall is sadly not very interested in archaeology, neither preserving nor emulating nor documenting "obsolete" stuff. "Today and tomorrow" are all they care about. Everything else isn't important to them (mostly). > As a lover of computing archaeology, I fear that when Mr. Gates passes away, > we will have to do with ChatGPT's answer. Oh well. I'm not understanding exactly what you want to know. (But someone like Michal Necasek of OS/2 Museum probably could answer.) PC-DOS was the version for IBM hardware, and MS-DOS was licensed to others. While Microsoft was mostly responsible for DOS (and OS/2), IBM still played a heavy role. At least Wikipedia says "MS-DOS 4" was mostly IBM's work. When IBM "fired" MS, (AFAIK) IBM still had access to sources for Windows 3.0 and MS-DOS 5.0. So they kept updating PC-DOS until, what, 2003? MS-DOS 5 came out in 1991, right? And OS/2 1.0 came out in 1987. OS/2 was supposed to be "the future", and MS was primarily responsible for OS/2 1.x (the 16-bit version). 32-bit OS/2 didn't come until 1992, and 32-bit Windows NT (aka "MS's portable OS/2 rewrite") was 1993. NT did support HPFS, for example, for a few years. So why did the "buggy" DOS 4's IFS interface not survive? They were focused on other OSes. Wikipedia says that OS/2 later got drivers for UDF and JFS. Obviously NT preferred NTFS (journaled, unlike HPFS, with larger max file size) and eventually dropped booting atop FAT (e.g. Vista) for security and performance reasons. It could also just be a RAM issue. IIRC, the standard answer why Windows tools won't create FAT more than 32 GB is because it's too slow (esp. for a real-mode driver). Maybe they never could happily get a working HPFS driver for DOS. (The 16-bit HPFS driver for OS/2 allegedly only supports a 2 MB cache maximum.) So if nobody uses it or it's too buggy or it only helps a competitor OS, then why bother? (Sigh.) For example, a few years ago Linux removed the ext3 [sic] driver because they only needed ext2 and ext4 (backwards compatible). The main reason for keeping ext2 as a separate driver was because it was much cleaner and simpler code. (Besides, I guess some storage media won't require journaling.) Sorry if I am confused, I'm just trying to understand it myself. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, On Sun, Feb 26, 2023 at 1:07 PM Bernd Boeckmann via Freedos-devel wrote: > > in the last two weeks I ported Free FDISK to Watcom C and started fixing the > bugs people mentioned > at the bttr forum and in the issue trackers. Great news! Thanks a ton for your work on this. BTW, it seems you still use NASM (instead of WASM). Seems redundant (no offense). > For people wanting to track the progress, I am doing the development at the > following repository: > https://github.com/boeckmann/fdisk. > > I will make merge requests to upstream https://github.com/fdos/fdisk in > regular intervals > > If you want something to be changed please send me an e-mail. I will try to > implement it if time permits it. Is makefile.bor still maintained? Do you still (also) support building it with that toolset (presumably freeware-ish TC++ 1.01 would work)? * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.BOR 1. Invoking TLINK with a toolset path is unnecessary. You can use "tcc" (or bcc) to link as well. 2. You also don't need to manually create temporary linker response files. (I forget exactly, but it's something like @&&^ ... ^ to do it automatically.) See here for an example: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/n16tcmak.zip Regarding OpenWatcom: * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.WAT 1. Again, you don't need to manually create a temporary linker response file. Try using "LD = *wlink" instead, it will automatically handle long command lines. 2. "if exist *.OBJ @rm *.OBJ" is unnecessary, and you should be able to delete multiple files with Wmake's built-in "rm", e.g. "rm -f *.obj *.err *.lnk" with no error messages if not found. 3. Oh! And %UPX% is possibly a bad variable name since I think that's what the environment variable is also named, so that will override any internal makefile variable by default (if the user has set it). I recommend "PACKER" and "PACKERFLAGS", but this is not majorly important. Again, here's an example "makefile.wcd" of mine (but ignore the older Borland makefile in there): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/nasm16.zip ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Wed, Feb 22, 2023 at 5:19 PM Bret Johnson wrote: > > As an aside, I'm wondering if anybody has a "fool-proof" test for FAT32 > capability in the kernel. In USBDRIVE > what I currently do is go through all the drive letters and see if any of > them responds correctly to INT 21.7302h > (Get Extended BPB). This test works if there is at least one existing FAT32 > drive letter, but will fail if there are > no actual FAT32 partitions even if the kernel supports FAT32. I don't know > of a direct or fool-proof way to detect > FAT32 support, but maybe somebody else has come up with something. I believe DJGPP utils (2.04 beta or newer, e.g. 2.05 current) use the naive method of "only assume FAT32 if DOS version is 7". (By this I mean "du.exe","df.exe" etc. will then use INT 21h, 7303h.) "INT 21 - Windows95 - FAT32 - GET EXTENDED FREE SPACE ON DRIVE" * http://www.delorie.com/djgpp/doc/rbinter/id/40/32.html What about INT 21h, 71A0h? (Admittedly, it may assume the Win95 LFN API is available.) "INT 21 - Windows95 - LONG FILENAME - GET VOLUME INFORMATION" * http://www.delorie.com/djgpp/doc/rbinter/id/23/32.html Returns: ES:DI buffer filled (ASCIZ, e.g. "FAT","NTFS","CDFS") ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, I got bored (despite already knowing about this history), so I started watching Nostalgia Nerd's video on "AARD" (re: Win 3.1 beta atop DR-DOS) on YouTube. "Windows’ Hidden Self Destruct Code | Nostalgia Nerd" * https://youtu.be/TIfNIWn2Ad4?t=753 (comments further below) On Wed, Feb 22, 2023 at 3:20 PM Aitor Santamaría wrote: > > Well, thanks to all that contributed to this interesting topic (there are > quite a few interesting mails in the thread). > > I could find very little extra information, like this: > > https://www.os2museum.com/wp/dos/dos-4-0/ > > Also I found references on IFSFUNC: in 2Fh (AH=11h), IFSFUNC functions seem > to be entangled with the network redirector functions: > > http://www.ctyme.com/intr/int-2f.htm > > Apparently, these functions would be made available by IFSFUNC.EXE (curiously > not provided by kernel itself). > So I suppose the current only way to know more would be to acquire a MS-DOS > (or IBM-DOS) 4.0, disassemble this file. > > My conclusion would be that it looks like an alternative functionality update > to the network redirector itself (and not something entirely unrelated), that > tried to solve some of the previous problems and/or tried to be more abstract > and less tied to internal DOS structures, that was implemented only in DOS > 4.0, probably to try and make HPFS available for DOS, but that was later > abandoned (due probably to high memory requirements) in favour of maintaining > the old redirector). I'm not sure where this pseudo-code came from (Geoff Chappell?). But this is what the above video mentions (12:33 in): IF redirector running (INT 2Fh AX=1100h) AND IF default upper-case map (INT 21h AX=38h) in DOS data segment (INT 2Fh AX=1203h) OR IF no redirector AND IF FCB-SFT header at paragraph-boundary (offset == 0) THEN DOS is considered okay Just wanted you to know. (Yes, it's mostly irrelevant.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] More on Packages
Hi, On Wed, Feb 22, 2023 at 7:53 AM wrote: > > So…. > > There is only an old version with sources. Or, a newer version without > sources. We only have 1.1 of P5 mirrored (so far). I've built 1.4 (pcom.exe, pint.exe) locally but haven't run the test suite yet. (He changed it so my old GNUmakefile isn't good enough anymore.) Mostly it's just extra error checking, no added features. (In particular, he didn't want to extend P5 beyond ISO 7185 level 0.) > What about the zips on ibiblio from 2020 for r67 and r76? No binaries? That's p5c (ISO 7185 level 1), based upon p5, but it's written in C and targets (modern GNU/Clang) C, e.g. GCC 12.2 (DJGPP). r67 is an older version and should be moved to "old/". The latest seems to still be r76. * https://sourceforge.net/projects/pascal-p5c/ > Maybe I can coax you into creating a fresh build. ;-) > > Then hopefully, the community could agree to include it on the BonusCD. > > :-) I do also have p5c.exe locally (built with DJGPP), but it's not hard to build (his readme tells how). Most of the rest of the .ZIP is documentation or extensive examples and tests. I don't demand a package for any of this. Just saying that I found it interesting to fiddle with over the years. (But as Ralf said, some people dislike classic Pascal. So it may not be a popular opinion.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] More on Packages
Hi, On Tue, Feb 21, 2023 at 10:22 AM wrote: > > On Feb 21, 2023, at 3:19 AM, jer...@shidel.net wrote: > [..] > I’ve not looked into P5 Pascal. It would be nice to have a alternative to FPC > for DOS. > > > I just took a quick look at P5 at https://sourceforge.net/projects/pascalp5/ > > I did not see any binaries for DOS. Can it target DOS? Since it is able to > compile itself, it might be capable of creating those binaries. > > Or, maybe they can be convinced to make next version P6 available to DOS. P5 is a full "ISO 7185" (classic Pascal, Wirth's original) version of the P4 "public domain" bytecode compiler (and interpreter) subset from ETH Zurich. The binaries (pcom.exe, pint.exe) were only compiled and tested (by me) with GNU Pascal (e.g. GPC / DJGPP). * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/pascal/p5/ Specifically, Scott (on SourceForge) only targeted Windows and Linux with separate .sh and (DOS-unfriendly) .BATs. So I wrote a GNUmakefile and built and tested 1.1 for DOS, Linux, and Windows. (Latest is 1.4, but I still haven't fully bothered yet. It's minor changes.) He kinda just does his own thing, so he never mirrored any of those builds. So I mirrored the DOS build for us. p5pas11.zip == (full sources and docs and tests, built with DJGPP 2.03p2 in 2013) p5-dj205.7z == (binaries only, built with DJGPP 2.05 in 2017) P6 will be 64-bit only because Scott doesn't seem interested in supporting 32-bit, sadly. So DJGPP it out. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Sun, Feb 19, 2023 at 7:39 PM Aitor Santamaría wrote: > > Does anyone know if the IFS (Installable File System) API is documented > anywhere? I have no idea if this link will help you, but I'm mentioning it "just in case" (because it sounds useful and impressive). * https://ecsoft2.org/ihpfs Basically, it's a read-only HPFS driver for DOS (last updated by Veit Kannegieser). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] More on Packages
Hi, On Mon, Feb 20, 2023 at 1:37 PM wrote: > > Other possible new packages to consider for inclusion (or at least watch): > > 386SWAT - GPLv3, Debugger (may require someone to compile) > https://github.com/sudleyplace/386SWAT You mean the old compile isn't sufficient? (IIRC, it was on his website.) > GW-BASIC - MIT License, Microsoft’s original 1983 version > https://github.com/microsoft/GW-BASIC Personally, I would rather have a package for P5 Pascal. (Although both is fine, too.) (But my .ZIP was old 1.1, and I never got around to testing or building 1.4 for us. No huge differences, just better error-checking, supposedly.) > DIFPAT, GPLv2, DIFF and PATCH Utilities > https://github.com/deverac/difpat Haven't tried these. Usually I just use the 32-bit DJGPP builds of the GNU ones. If these are really 16-bit, that'd be cool. (There are other tools in the wild, too, especially for non-text binaries.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Needs testing: SJGPlay
Hi again, On Mon, Feb 20, 2023 at 7:31 PM Rugxulo wrote: > > On Sun, Feb 19, 2023 at 3:58 PM Jim Hall wrote: > > I haven't checked the new sources (IIRC, it was said to be BASIC ... > PowerBASIC??). Does it also include ACD kit (or whatever third-party > lib)? This release does not include the sources to "ACDkit", only binary files (libs, etc). Can this be fixed? Who wrote ACDkit? Where is it currently found? What is the license? (Do we need a replacement? It can't be THAT hard!) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Mon, Feb 20, 2023 at 6:41 PM Ralf Quint wrote: > > (just for example, DOS maintains > only one single date for a file, "Time modified", while on NTFS and > OS/2, you have additionally, "Time created", "Time access" as well. Some OSes do update "time created" for FAT. (There was a patch for the FreeDOS kernel in recent years, but I can't remember if it was ever officially included.) IIRC, "ctime" wasn't normally available to DOS itself unless DOSLFN (or similar) was loaded. I think (once loaded) DJGPP utils would then read it correctly. I did vaguely find that useful sometimes. But "access time" is often shunned as wearing out the drive for little reason, so (naively) I thought most Linux distros mounted as "noatime". ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Needs testing: SJGPlay
Hi again, On Mon, Feb 20, 2023 at 7:31 PM Rugxulo wrote: > > On Sun, Feb 19, 2023 at 3:58 PM Jim Hall wrote: > > > I used to use SJGPlay a lot (back in the day). I loved it. But I > haven't tried again in many years. > > > Could anyone with a CD player and a sound card on their computer > > please test SJGPlay with actual music CDs I found some old 2007 emails I sent him: >>> I can't get SJGPlay for DOS to work under XP. Windows 95/95 no problem. Ah, >>> the price of progress. >>> Freebasic looks interesting. I should try compiling SJGPlay with it someday. The old .EXE worked fine (years ago), so unless something changed (i.e. recompiled with different tools), then it shouldn't be a problem. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Needs testing: SJGPlay
Hi, On Sun, Feb 19, 2023 at 3:58 PM Jim Hall wrote: > > I wanted to start a new thread for this request. Based on the > discussion from the "FreeDOS package issues" thread, Jerome identified > that the CDP package didn't include source code. Robert suggested > SJGPlay as a replacement. I used to use SJGPlay a lot (back in the day). I loved it. But I haven't tried again in many years. (I liked the karaoke aspect even if I don't sing.) It was very well made. > Could anyone with a CD player and a sound card on their computer > please test SJGPlay with actual music CDs and comment here if SJGPlay > works well. (I don't have a CD drive on any of my computers, so I > can't test this myself.) I haven't checked the new sources (IIRC, it was said to be BASIC ... PowerBASIC??). Does it also include ACD kit (or whatever third-party lib)? (Eric's CDROM2 is maybe too minimal, but I still found it cool.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Proposal: remove Graphical Desktops from next FreeDOS
Hi, On Wed, Feb 15, 2023 at 5:28 PM Danilo Pecher wrote: > > Quite frankly, I would throw them all on the scrap heap. I wouldn't quite "throw them away", but for simplicity we really don't have to include them. I don't use any GUI in DOS (by default). > As Jim said, none of them has any number of apps worth noting I thought GEM included an art program and a word processor?? > and there is a reason why no GUI other than Windows 3.11 ever took off under > Dos. Desqview/X? (The devkit for that is still on DJGPP mirrors under "v1" whatever.) Calmira?? > I know that from painful experience of wasting two years on an attempt to > create one in the early 90s. It's just not what Dos is about, I think. DOSSHELL was quite nice (although I rarely used it). Same with Desktop2. However, for mixing tools and writing scripts and testing things, a UI is usually more of a hindrance than anything. (DOS Navigator was also very nice. In some ways I prefer TUI without mouse.) There were a *lot* of cool DOS programs and toolkits. For DJGPP alone, there was mGUI, JPTUI, Allegro, and others. It's sad how much got deprecated or ignored for DJGPP. It really is a swell suite of tools. > Unless someone puts together a serious attempt (perhaps PCGeOS > qualifies) I wouldn't include any GUI. Frankly, if you are after a > freeware GUI OS, Linux or ReactOS are better options. I wouldn't include any with FreeDOS "by default" either. I disagree about Linux as a suitable GUI for the same family of machines. There are not a lot of good distributions for old machines anymore. Something like ZipSlack (Slackware 11.0) is nice but from 2006. Well, I guess that's no worse than what we have, but it's unsupported and few would use or recommend it. Last I checked, the oldest supported Linux kernel upstream was from 2016. People are already giving up on IA-32 and even trying to split up x64 into separate groups (e.g. AVX2 or AVX-512, ugh). Chromebooks are quickly obsoleted too (which the FSF calls "planned obsolescence"). I'm not blaming anyone for not wasting time or money, but if something is shunned *and* unsupported, it makes little sense to say "just use Linux" when it either literally won't work (anymore) or nobody will develop with it or for it. Or did you mean TinyCore or some variant of Puppy? * https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Email Oblivion
Hi, On Wed, Jan 4, 2023 at 4:11 PM wrote: > > Due to some changes at the current registrar I use for my SHIDEL.NET domain, > my email was broken for the last week or so. > > If any of you attempted to contact me or if I missed something that required > my attention, I would not have received any messages. So if there is anything > you need to point out to me, you will need to resend it. Glad you're doing okay. Yeah, I sent one trivial email (that bounced), but since you're busy I don't think it's super important to resend. Thanks again for your work on FreeDOS, and don't stress too much in the New Year. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS floppy edition boot disk lacks an editor?
Hi, On Mon, Dec 5, 2022 at 8:58 AM Bret Johnson wrote: > > FWIW, the one I use is also called TED and is an old utility from PC > Magazine. The executable is only about 3 kB > (way smaller than the EDLIN that comes with MS-DOS) and is a VERY basic text > editor with a TUI > (it's not a line-oriented interface like EDLIN so is more intuitive to use). > It gets the job done efficiently for things like > editing CONFIG.SYS & AUTOEXEC.BAT. I used e3-16 (Wordstar keys) since it was super tiny (roughly 3 kb), but it was limited to CR+LF files and max 32 kb, which is imperfect. But for boot disks it was great in a pinch. Besides executable size (and license, ugh), you also have to worry about key bindings. I also like SteVIe (a vi clone), which is quite good in various ways. My normal favorite TDE also has a real-mode version, but I probably wouldn't prefer that (nor even an older version) for floppies. You really don't want a 160 kb editor on a floppy (unless you copy it to a RAM disk). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal
Hi,
On Sun, Nov 6, 2022 at 9:08 PM Jerome Shidel wrote:
>
> Make sure your compiling to the correct memory model. (I think huge, but
> you’ll need to double check that)
Default is Small, e.g. "-WmSmall". I assume "-WmCompact" would work
better for you?
> You may need to ensure the actual procedure is declared with far.
>
> Procedure Test; far;
> Begin
> End;
In old freeware TP 5.5, that would be {$F+} at the top and {$F-} at
the bottom of the procedure. (I believe all procedures within the same
unit / file are near while external procedures are far by default.)
> Also, you may need assign the address to a plain pointer and typecast the
> call.
Is that needed??
> Also, there are also compiler directives for FPC regarding compatibility.
Default dialect is "fpc", which is less strict than {$mode tp}, e.g.
it does change function pointer syntax a bit, but it also gives you
structured return types and function overloading.
{$asmmode intel} is only default for {$mode tp} as well (but you can
manually enable it, too).
Don't forget you can also declare inline functions! (Like real
inlining, not just inline machine code.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Hi, On Tue, Nov 1, 2022 at 3:40 AM Liam Proven wrote: > > On Fri, 28 Oct 2022 at 19:29, Robert Riebisch wrote: > > > Just to add: Virtual PC 2004 SP1 and Virtual PC 2007) were/are available > > as a free download from Microsoft, but didn't/doesn't include any DOS > > version. > > That's true. > > I suspect that the thinking was that if you're running on a PC, then > you already have a PC OS, by definition. This is not true of Mac > users, obviously. Old Windows (e.g. 7) used to let you make a system floppy (using DISKCOPY.DLL, which has a bundled MS EBD disk or whatever). RUFUS will optionally use this if you don't choose FreeDOS. (Yes, RUFUS supports the LiveCD but also has a very minimal FreeDOS bundled already.) I don't think that's available in Windows 10 or newer anymore. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] When is FreeDOS slow and when fast
Hi,
On Sat, Oct 29, 2022 at 2:11 AM Ladislav Lacina wrote:
>
> In the last time I worked a lot with the Freepasval compiler.
> The computer: Pentium 4, SSD PATA disk, 512MB RAM
> The task: Compilation of the full Blocek source ("Build all") - 64603 lines
> of code using FreePascal 3.2.0 (GUI)
>
> FD, cwsdpmi, noUIDE, noLBAcache: 208,2s
> FD, cwsdpmi, noUIDE, LBAcache4096: 54,9s
>
> FD, cwsdpmi, UIDE160, noLBAcache: 72,1s
> FD, cwsdpmi, UIDE160, LBAcache4096: 72,2s - 178,8s
>
> The conclusions:
> 1) The speed without any cache is really awfull. On the speed machine and od
> the SSD disk!
> I do not understand why. Maybe the DOS uses some techniques which are
> contraproductive on SSDs
Cache (and even BUFFERS) takes RAM, which early DOS systems couldn't
spare. Even MS won't partition larger than 32 GB FAT32 drives because
it's slow to access it all in real mode.
> 2) Hdpmi32 does not use the RAM disk swapping while CWSDPMI does
> and it seems to be a reason why it speeds up the things so much.
> I do not understand why CWSDPMI does it even on machine with 512MB RAM.
CWSDPMI shouldn't be swapping at all. It does create an empty swap
file by default, but it doesn't use it until needed. You are using r7
from 2010, right?
CWSDPMI was designed to work on old machines (e.g. his old 386 laptop
with only 512 kb of low RAM), so it put the 4 kb page tables in low
memory, too. (He said this is also hard to debug / fix.) That will
overflow on machines with large amounts of RAM, hence the (default but
optional) r7 feature of using Pentium's 4 MB pages when possible.
HDPMI32 does presumably keep the page tables in extended memory.
If you want to load CWSDPMI resident and try without any swapping, try
"cwsdpmi -p -s-".
It's still better than Causeway, which will swap the *entire* used RAM
out to disk (instead of only how much extra is needed).
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New version of text editor (and image viewer) Blocek
Hi, On Fri, Oct 28, 2022 at 6:14 AM Eric Auer wrote: > > I noticed that Jim's TRCH only translates one char at a time, > do we already have a variant which is as powerful as Linux "TR", > supporting for example TR 'a-z' 'A-Z' or TR -d '\n' and so on? DJGPP's TextUtils has TR.EXE (but I'm not familiar with it): * http://www.delorie.com/pub/djgpp/current/v2gnu/txt20br3.zip ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Hi, On Tue, Oct 25, 2022 at 10:27 PM Bret Johnson wrote: > > > Although I never truly needed to know what VM > > One of the main things that started me down this rabbit trail was the need to > know which Ethernet card is being virtualized in a particular VM so I can > load the correct packet driver. I have a single ETHERNET.BAT file I run to > install the packet driver, and since detecting which network card is > installed is a tricky proposition I do it indirectly by detecting the VM (or > lack of VM if I'm running on real hardware). I can't remember exactly (would have to check), but I think I just used BERNDPCI.COM. > >> DOSBox > > > > "Only for games". (Maxes out at 64 MB RAM, meh. "Slow Pentium" is > > best it can emulate, IIRC.) > > No, it can run "real" applications also. But you're correct that its primary > focus is compatibility with games. You mean via IMGBOOT or whatever? But that hides the whole guest filesystem aspect. It's still quite limited. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Hi, On Mon, Oct 24, 2022 at 9:07 PM Bret Johnson wrote: > > I've been working on some updates to the ISLOADED program I sent to Jim a few > weeks ago. > Lately I have been specifically trying to add the detection of different > Virtual Machines (including VirtualBox) > to ISLOADED. It turns out that there are a BUNCH of VMs out there that I've > gotten to work with DOS: Jerome's V8Power Tools will detect some VMs, IIRC: * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/v8power.html Although I never truly needed to know what VM, the naive ways to detect (from my limited experience) are a). check DOS version, b). check VESA version string, c). check BIOS string. (You could also check the cpu, but that's messy. DOSBox is a "fast 486" DX2 by default, IIRC.) Actually, I take that back, several pieces of software check for "version 7" and behave differently, which sometimes fails. Like I said, it's naive and imperfect. (Also some like DR-DOS 7.03 report "IBM DOS 6" for compatibility and need their own incompatible version check [int 21h, "DR"] just to know for sure.) > DOSBox "Only for games". (Maxes out at 64 MB RAM, meh. "Slow Pentium" is best it can emulate, IIRC.) > DOSBox-X It's quite interesting (esp. running atop FreeDOS itself). But I haven't tested it too heavily. > DOSEmu / DOSEmu2 Is this available in any repos? I'm very naive. Didn't the original used to be in "multiverse"? I'm not sure it's there anymore. I still haven't tried DOSEMU2 yet, but it uses its own modified FDPP (DOS) kernel, right? It has a PPA or whatever, not sure. (This does supposedly support VT-X now. They used to support other methods, but I'm not sure if that's still supported. Also, they might be 64-bit host only, not sure.) > Hyper-V So Hyper-V does actually support DOS? From what I read (years ago), I wasn't sure. (Back then it was 64-bit Pro VT-X only.) This is also what WSL2 supposedly uses behind the scenes. > JPC The Java one?? > KVM This is just QEMU using VT-X, right? > Parallels Mac? > QEMU I usually just used Stefan Weil's Windows binaries from his site. (I don't remember what version I have installed, probably 6.x on Win7. Latest version of his seems to be 7.1.0.) > vDOS Wengier did some work on VDOSPlus, I thought (for apps, not games, with LFNs and better printing support). > VirtualBox Even VirtualBox dropped 32-bit hosts and non-VT-X cpus a few years ago. (They use OpenWatcom to compile the BIOS.) > There are also a few other VMs out there that I'm not sure will run DOS (the > documentation is unclear > and I haven't been able to install or test them for various reasons): > > BHyve This was created for FreeBSD and first released in 10.0, IIRC. It requires a 2010 Intel (or newer) with VT-X (and EPT). IIRC, they "mostly" wanted to run other versions of BSD, but there was partial effort to get other OSes (even with a BIOS) running. Honestly, I never tried it, but it sounded interesting. (Wasn't the Mac port called xhyve?) * https://wiki.freebsd.org/bhyve * https://bhyve.org/ Apparently it can also run x64 Windows via UEFI. (sysutils/grub2-bhyve is used for running some other *nixes.) > I know the FreeDOS web site also lists several VMs (some of the same ones > I've listed above, > plus JSLinux which is similar to JPC). Not sure, JSLinux is Javascript while (IIRC) JPC Is Java. There used to also be JDOSBox in Java and one guy (I forget) hosts JSDOSBox (Javascript) with demos on his site. There's also 8-Bit Workshop's website, but I don't know what that uses. (There's a lot of fragmentation and old versions). There were also Joris' Retro (Java) and 8086tiny (in C, with various forks). > At least some of the VMs have a "built-in" DOS, often based on some version > of FreeDOS (for example, VPC and DOSEmu). VPC uses FreeDOS?? Not sure. DOSEMU used to allow MS- or DR- or FD-, but I had weakly thought DOSEMU2 required its own FreeDOS fork called FDPP. > Anyway, I'm wondering how "involved" FreeDOS should be in the VM world > (I think in today's world the vast majority of users install DOS under a VM > rather than on real hardware, > though I personally do both). Yes, I agree that VMs are more common for FreeDOS users nowadays, especially with no more BIOS or CSM on new machines. > How involved in testing / recommending applications (including games) > for compatibility should FreeDOS actually be, particularly when a VM is > involved? I would say games are low priority (but still vaguely important) and thus harder to get working. My main interest is in getting old utils and compilers to run. Graphics (and especially sound) are a whole other ball of wax. > Where/how should the results be documented (or if there even should be a > central repository)? You mean like DOSBox's compatibility list? Or WINE? Does WINE still use DOSBox itself? ___ Freedos-devel mailing
Re: [Freedos-devel] FreeDOS Interim Build T2210
Hi, On Mon, Oct 17, 2022 at 11:04 AM Jerome Shidel wrote: > > > On Oct 2, 2022, at 5:08 AM, tom ehlert wrote: > > [..] > > btw dowloading 900 MB .zip over a 4MB/s download link is a PITA; this > > alone should recommend a split. (Sorry, I'm horrible at trying to calculate such things, but I try anyways. Corrections welcome.) Is this "megabits"? So that would be 30 minutes, right? 4 Mbps = 0.5 MB per second. So 900 MB would be 1800 seconds ... right?? (Assuming no connection slowdowns.) > Imagine downloading it back when DOS was the main home user OS — over a fast > 56k modem. If you somehow managed to download load it without it erring or > timing out, the next OS release would probably be available when you finished. > > :-) 56 kbps = 7 kb per second, right? So 37 hours?? Seriously, in cases like that, you'd probably just download overnight while you're asleep (and nobody is using the phone). Obviously it's better to only download in pieces so you can verify (with checksum), and retry (if needed), only a small part instead of the whole thing. Some places (e.g. Britain) charge for *local* phone calls, right? So obviously it's more cost effective and easier to just order a physical CD (assuming you have a working drive) or IOMega ZIP disk or whatever. (Or somehow copy it from a friend's hard drive who has a faster connection.) Compression also helps (obviously) but should be done "solid" so that it's not only individually per file (and not in very small chunks like 32 kb Deflate). In other words, 7-Zip is overall superior to most things (in size and speed). (Or maybe RAR.) This also means avoiding redundant files and too many competing versions of the same thing. (Smartlinking helps. But modularity and dynamic libs are a whole other issue.) Actually, back in the day (1997), if you downloaded Allegro for DJGPP, they made you compile it yourself, which (on a slow 486) took 30 minutes. That GCC (2.7.2.1) was tons faster than later versions (even when the latter's optimizations were turned off), don't know why. Maybe it was the small cpu cache (used better by a smaller binary). There are many ways to be frugal in size and speed, but most developers don't have the interest anymore when "everyone" has 64-bit and gigs of RAM. Software is not cheap to develop. These days, hardware is much cheaper than software. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Hi, On Sun, Oct 23, 2022 at 1:46 PM Jerome Shidel wrote: > > Although there has not been a lot of feed back on what to do with the > excessively (nearly 1GB) BonusCD in T2210, I think the majority of feedback > has been in favor of splitting off the development packages from the BonusCD > on to their own DevelCD. Yes, probably. I don't have it nearby to look, but a glance at this list ... * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/group-devel.html ... shows a lot of DJGPP stuff. Now, I *love* DJGPP and all it does, but man, is it bloated! That alone takes up the most space, I think. We definitely *don't* need "full" DJGPP here. > And, we should do this instead of dropping packages for several reasons. The > main reason is for the convenience of users who may be on older hardware or > without network support. Those users might experience some difficulty getting > all of the programs they need into their “DOS” machine. Agreed, but you can't please everyone. It's not just DOS support or even "I want C" but dialects and various other minor features. > It has also been suggested to provide a “Developer Oriented” release of > FreeDOS. One that is specifically geared towards DOS development. I actually thought about making my own personal "floppy" for programming! So I know that's not quite what you wanted, but for me, it would be useful: * nasm16 + val, mawk, minised, picoc, P5 Pascal (pcom/pint), dx-forth, regina, dmake, etc. Bundled editor would probably be old SteVIe or e3-16 or even e14_edit. > So where does that leave us? I think there are at least two practical > solutions at present. > > First, split off all development related packages that are on the BonusCD > onto a new DevelCD. This would require very little work. The Release Build > Environment (RBE) is already capable of creating multiple extra package discs > images. However, I will probably want to add some functionality to use > specific labels for them. At present, it would generate BonusCD0 and > BonusCD1. It will not be hard to update the RBE to use custom labels for the > discs. This first solution implies we may eventually have a GamesCD, UtilsCD > and others as well. If we go down this path, perhaps we should start > separating some other packages on to their own media as well. DJGPP could have its own disk. (On my old hard drive, I had at least 1 GB used by DJGPP stuff.) You might also want to include DJGPP-derived things like Free Pascal and FreeBASIC. I mean, I've mentioned before that I made a single 1.44 MB floppy of an old DJGPP (2.03p2 with GCC 2.95.3 + BinUtils 2.16.1 + make 3.79) compressed by 7-Zip (so you only need the small 7zdec). That's C only and lacks C99 and newer GCC features and has no extra graphic or networking libs, but it's much smaller (and can fit on small a RAM disk). Newer GCC is *much* larger. > I don’t know if there is a good solution to this issue. But, I am certain we > can not provide a "950Mb BonusCD.” > > If you have any comments or other suggestions on the problem, please speak up. > > :-) Jerome, you're very smart and have done a ton for FreeDOS, so I trust whatever decision you make here. Don't stress too much over it. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] GNU C Language Intro and Reference Manual
I stumbled upon a link to another cool e-book about C (using the GNU Free Documentation License 1.3): "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/ "This manual is intended for learning the C language, if you know how to program in some other language. It is also a reference manual for GNU C. Please report any flaws, including any passage that is unclear or hard to understand." ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Ré : Ré : GCC 12.2.0 and BinUtils 2.35.1 packages
Hi, On Thu, Sep 1, 2022 at 1:10 AM Paul Dufresne via Freedos-devel wrote: > > I said previously: > > Please do not try to install the previous packages for now. > > > > I have created the files in DEVEL\BIN rather than DEVEL\DJGPP\BIN, etc. > > > > Will fix the packages now. > > I think it is fixed now. > Added a package for GCC sources too. > > Again, available at: > https://gitlab.com/dufresnep/freedos-djgpp/-/tree/main I'm pretty sure the sources can only be cross-compiled (obviously??). And you also need MPC, MPFR, etc. (libraries). Sure, it would be nice if these were all reproducible, but I don't think most of us can do it. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] How to install GCC in FreeDOS? (avoid the segmentation fault when running gcc)
Hi, On Mon, Aug 29, 2022 at 1:52 PM Paul Dufresne via Freedos-devel wrote: > > At first I did: > fdnpkg install djgpp_gc > and then tried: gcc , in some directory... was not working > > I then "cd c:\devel\djgpp\bin" > I then "gcc", but then I got a segmentation fault. > > I think that after some Google search (did not help)... I saw > C:\DJGPP\README.1ST > > I then: > fdnpkg install djgpp > fdnpkg install djgpp_bn > > and added to c:\fdauto.bat (after other set, before aliases): > set DJGPP=C:\DEVEL\DJGPP\DJGPP.ENV > set PATH=C:\DEVEL\DJGPP\BIN;%PATH% > ... > reboot > > after that: > gcc --version > have given the expected result. > > Wish to help others get the result faster... either creating a Wiki page > would help. > Or maybe some line written when installing djgpp_gc? Traditionally, you would follow these instructions: * https://www.delorie.com/pub/djgpp/current/v2/readme.1st Also see the mini-FAQ: * http://www.delorie.com/pub/djgpp/mini-faq.txt ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] No simple cpu identification program returning an error code as an answer?
Hi, On Fri, Aug 26, 2022 at 1:27 PM Paul Dufresne via Freedos-devel wrote: > > Following the modification of my idea proposed by Tom: run edit32 on 386+ > else run edit... BTW thanks Tom! I believe CC386 had a 386+ text editor also using D-Flat. > I have been looking a bit for a simple program that would identify > approximate CPU and return it as an error code that batch file could used. > I did not found that (especially with free license)... so that I am thinking > about writing one. > Just asking if that exist already here. Eric Auer wrote this one years ago: * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/cpulevel/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] MS-DOS compatibility issue
Hi, On Fri, Jul 29, 2022 at 1:45 PM Steve Nickolas wrote: > > On Fri, 29 Jul 2022, Ralf Quint wrote: > > > But IIRC, the common way to check for the presence of an ANSI device driver >> was to check via an INT 2Fh (multiplexer) call (don't recall the exact call >> value > > (AX/AH)). > > That would only work on MS-DOS 4 or later and I'm not sure NANSI supports > it, but according to RBIL, it's INT2F/AX=1A00, return FF in AL. I remember when Eric Auer added it to NANSI, so it should support it: * https://docs.huihoo.com/help-pc/int-int_2f_0.html INT 2F,0 - DOS Multiplex Interrupt - Get Installed State AL = 00 AH = 1A for ANSI.SYS (DOS 4.0+) on return: AL = 00 not installed, ok to install = 01 not installed, do NOT install = FF installed ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] m2c 0.6 for DJGPP (Modula-2)
Hi all, Years ago, way back in 2013, for whatever dumb reason, I decided to try and build m2c 0.6 (circa 1998) for DJGPP inside DOSEMU. M2c is GPL and supports so-called "PIM dialect" Modula-2 (aka, Wirth's original version). I didn't use it much (except barely for my Befunge-93 interpreter), so I didn't give it much thought until recently. It has some bugs, but overall it "mostly" works. Unlike Pascal, files and strings are relegated to separate external library modules (i.e. usually non-standard). Unfortunately, most (but not all) compilers are PIM and not ISO. You still need DJGPP (gcc), too, so I just used my old fits-on-one-floppy-compressed version (gcc 2.95.3 + binutils 2.16.1 + djdev 2.03p2). * https://en.wikipedia.org/wiki/Modula-2 * https://www.modula2.org/ * https://freepages.modula2.org/ * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/modula2/m2c/ * https://sites.google.com/site/rugxulo/DJGPP203.7Z?attredirects=0 * https://sites.google.com/site/rugxulo/compilers (sources to GCC et al.) Sorry if the binary .ZIP (m2c.zip) doesn't have proper documentation (check the source archive, it has the man pages and examples). There are several other compilers for DOS, too, but they're harder to find or set up. Much better would be getting GNU gm2 (soon to be part of GCC proper) to build for DJGPP, but I doubt that's going to happen. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] The 386MAX source code has been released :)
Hi, On Sat, Jul 2, 2022 at 4:53 PM Eric Auer wrote: > > PS: Regarding Jim's search and replace suggestion, I like > to add the twist to use "touch" to "copy" the timestamp to > a /tmp/tstamp file, then use sed -i for in-place-edits and > then copy back the change time from the temp tstamp file. I also was going to suggest "sed -i" but, in particular, "sed -i~" (for backup). Also, I believe "touch -r" is what you want for using date from reference file. * https://linux.die.net/man/1/sed * https://linux.die.net/man/1/touch ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] REMember a bug
Hi, On Sun, Jan 9, 2022 at 1:39 AM Jerome Shidel wrote: > > > Since the docs say everything after the REM is ignored, > I feel that the behavior is not consistent with the stated > behavior. So, it is a bug in either the handling of the pipe > in a REM statement. Or, it is a bug in the documentation. > > Either way, It is more of a philosophical question.MS-DOS > is NOT bug free and just because happens in MS-DOS, > does that mean it needs to do the same thing in FreeDOS. > Even if it is a bug in MS-DOS? This is well-known .BAT behavior in MS-DOS (but could still "maybe" be considered a bug). The classic workaround is to use "::" (two colons) to comment out the line, then you can use as many pipes and redirection symbols as desired. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: FDTUI and Minibox
Hi, On Tue, Dec 21, 2021 at 11:29 AM Jim Hall wrote: > > Ercan sent this announcement and question to me, and I wanted to share > it with the freedos-devel list: > > > -- Forwarded message - > From: Ercan Ersoy > Subject: FDTUI and Minibox > > I hve read documnetation on CWSDPMI and have found bug in CWSDPMI. > How can I report for the bug? I'm not sure if it's still considered actively maintained, but you can try here: * https://sandmann.dotster.com/cwsdpmi/knownbug.html ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] SmallerC compiler
Hi, sorry for late reply,
On Sun, Sep 19, 2021 at 6:27 PM Jim Hall wrote:
>
> Smaller C is a simple and small single-pass C compiler, currently
> supporting most of the C language common between C89/ANSI C and C99
> (minus some C89 and plus some C99 features). Currently it generates
> 16-bit and 32-bit 80386+ assembly code for NASM that can then be
> assembled and linked into DOS, Windows, Linux and Mac OS X programs.
>
> The developer recently released a new version. This release includes:
> + DOS binaries (regular and DPMI) + CWSDPMI r5 for the DOS DPMI
> binaries + include and library files + test programs. This release
> also includes the source code, under the BSD 2-clause license.
I'm glad you mirrored this. Maybe I should've pressed harder to mirror
it sooner or done it myself, but I was too busy. (I would've deleted
binaries for other OSes by default, especially because of bogus
antivirus heuristics.) It's truly genius, so I'm glad we have it. I've
already tested it with MetaDOS over the years.
But I never got around to testing this particular release until now. I
always forget everything these days.
It seems fine. The only weird part is the old CWSDPMI r5 from 2000
instead of a newer r5 from either 2002 (three fixes, IIRC) or the 2008
refresh (which also includes the fixes and turns on SSE).
AFAIK, r5 was old and only uses 4 kb pages (e.g. EMS / EMM386 doesn't
know any higher). So the Pentium-era 4 MB pages (much faster but won't
swap, you can also disable it with CWSPARAM) aren't here, only in r7
from 2010. Actually, there's no CWSPARAM included here at all.
I'm dumb, so take what I say with a grain of salt. I'm no systems
engineer. Including this older version may not matter much because it
doesn't use much RAM. (Using any binary in /BINDP/ will also use the
/BINDP/CWSDPMI.EXE binary by default, not any other global one unless
resident in memory.)
But it worries me because r5 would easily overflow the page tables
(which are in low / conventional memory) with higher amounts of RAM, I
thought, e.g. over 512 MB. You can get around it by letting it swap
(default on) to harddisk ("c:\cwsdpmi.swp"). I tried disabling that
(put '\0' where the drive letter is, that's what CWSPARAM does), but
luckily nothing broke. IIRC, Charles said debugging or fixing page
tables wasn't worth it (and he also wanted it to work on very low-end
machines, e.g. an old 386 laptop with only 512 kb RAM!). You can also
change where to swap ("-sg:\whatever.swp") to swap to RAM disk, if
needed, I think, in case it runs out of room for its own page tables
of available RAM. Or use a different DPMI host (e.g. hdpmi32.exe).
Anyways, this is just a ramble from me, trying to clarify. I always
prefer r7 in my testing. I can't think of any reason to prefer the r5
2000 release, but if nothing breaks, it's okay, I suppose. Just be
slightly aware.
* https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/cwsdpmi/
* https://sandmann.dotster.com/cwsdpmi/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DIGPAK sound drivers now open source under MIT license :) Can anybody help me port these from TASM?
Hi,
On Thu, Sep 23, 2021 at 4:55 PM Volkert via Freedos-devel
wrote:
>
> 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.
Good to know, thanks for telling us.
> DIGPAK drivers are used in many DOS games, and provide hardware abstraction
> to software developers through a well-documented INT 66h API.
What specific games used it? If we can find a compatible game that has
sources available, that might increase motivation for some people.
> 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
Cool. (Seems everything is conditionally defined in one large [240 kb]
SHELL.ASM.)
> 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.
LazyASM (LZASM) was a "freeware" assembler that was TASM compatible
(Ideal only, case sensitive only). I think it was probably a licensed
(Russian?) fork of TASM itself! It's still available on various sites,
e.g. SAC.sk:
* https://www.sac.sk/download/utilprog/lzasmx.zip (DOS .EXE via WDOSX)
* https://www.sac.sk/download/utilprog/lzasm.zip (Win32)
OpenWatcom's WASM has "-zcm=tasm" for partial support.
(I also still have my copy of TASM32 5.3 from 2007's Turbo C++
Explorer. Not sure whether newer Embarcadero C++ demo downloads
include it. Probably!)
I'm far from an expert, but the complexity depends on what features
were used (preprocessor, macros, structs), how much .OBJ or
segmentation support is needed, external dependencies (compilers,
linkers, libraries, include files), etc.
> 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?
JWasm and MASMv6 syntax (see _Art of Assembly_ book) might be a good
candidate. But overall I think NASM is the best assembler to use, for
various reasons. However, it's very imperfect for such old legacy
code.
> 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. :)
My experience is fairly low, honestly. Mostly I've just been fiddling
with converting PSR Invaders ("old MASM" syntax) via scripting to
target various assemblers, but it's a simple 8086 .COM, so it's not
too complicated (but hard enough!). So I'm not sure I'm much help.
Anybody truly interested might want to buy Tom Swan's _Mastering Turbo
Assembler_ (2nd ed.) used from Amazon. (I think I checked, and it was
only $16.)
Again, not sure of the overall complexity required here. Legacy code
tends to be VERY myopic.
Good luck! (I'll ask on BTTR to see what they say.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] desmet-c link
Hi, On Sun, Sep 19, 2021 at 6:22 PM Jim Hall wrote: > > > On 9/19/2021 1:17 PM, Paul Dufresne via Freedos-devel wrote: > > > On the chat today, desmet-c (that seems to be some kind of fork to > > > https://github.com/IanHarvey/pcc [A small C compiler]). That's not DeSmet C. That's something else entirely (with no DOS port, AFAIK). * http://pcc.ludd.ltu.se/ "The compiler is based on the original Portable C Compiler by S. C. Johnson, written in the late 70's. About 50% of the frontend code and 80% of the backend code has been modified. See the PCC History wiki page for details." * http://pcc.ludd.ltu.se/pcc_history/ * https://en.wikipedia.org/wiki/Portable_C_Compiler The part I remember reading was this (although it's not actively maintained anymore, sadly, AFAIK): "On December 29, 2009, pcc became capable of building a functional x86 OpenBSD kernel image." (But most people in *BSD later went with Clang instead.) There was also a Windows version (using YASM? I can't remember) that I minimally tried, years ago. Not sure if I ever tried it under HX, though. > > > Before closing my tab, mailing the link to all for not loosing it: > > > http://www.desmet-c.com/ > > On Sun, Sep 19, 2021 at 5:49 PM Ralf Quint wrote: > > No, it's not a fork of anything else. It was one of the early PC C > > compilers, a commercial product that due to be produced by a one-man > > company lost out in the market as soon as Borland released Turbo-C... > > > > It's never the less a very interesting and neat C compiler for (Free)DOS... > > Thanks for sharing this. > > So others can find this later, I added a link to the DeSmet C compiler > from the Links page on the website, under "Programming": > > http://www.freedos.org/links/ What you're thinking of is the shareware release of "PCC" found on Simtel here: (from PCC.DOC): "Personal C Compiler" "Copyright 1989 by C Ware Corporation and DeSmet Software" PCC12C.ZIP 175811 Personal C compiler. Fully functional, C WARE * http://cd.textfiles.com/simtel/simtel20/MSDOS/C/.index.html P.S. Don't forget, TinyAsm (aka, minimal NASM clone for 8086 host/target of .COM only) uses DeSmet C to build itself: * https://github.com/nanochess/tinyasm ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freecom beep crash question
Hi, On Thu, Aug 12, 2021 at 12:43 PM Eric Auer wrote: > > I notice that FreeCOM 0.84pre2 hangs after beeping, probably > because it uses some method for timing the beep which fails > on certain hardware. Could somebody tell me whether newer > FreeCOM versions fix this by using a foolproof timer, for > example the 40:6c timer tick counter? Is there a method to > disable beeping, for example using a command line option? > > Given my habit to use tab-completion in FreeCOM, crashing > after each beep is quite annoying :-p Thanks for your ideas! I guess you've forgotten this old mail from 2016 (May 11, freedos-devel)? "Beep command can't stop sounding when run in Intel Skylelake platorm." [sic] * https://sourceforge.net/p/freedos/mailman/message/35079762/ --- binary patch begins here --- Comparing CMD.OLD and CMD.COM 8293: 55 C3 82AF: 55 C3 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Wirth compilers (was: 2 diffrent index of ibiblio?)
Hi,
Changing subject to Wirth compilers (Pascal, etc)
On Tue, Jun 8, 2021 at 2:21 PM Paul Dufresne via Freedos-devel
wrote:
>
> I am a bit confused...
> I used to see:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/group-devel.html
> but searching ibiblio from myself found:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/?C=N;O=A
>
> The first seems to be more the programs included in 1.3.
>
> But the second seems to contains more programs.
> I particularly like to find a modula-2 compiler.
> The evolution goes a bit like this (might be my personal oversimplification):
> pascal,
> modula-2: separate compiliation of module definition and implementation
> oberon: no more separation, an * indicates you export a symbol, the other
> being private.
>
> Anyway... is the second list a kind of index with rejected packages for
> Freedos?
First of all, I'm far from an expert in these languages, but I did
fiddle quite a bit (for such a simple project as a Befunge-93
interpreter) with various Pascal(s), Modula-2, and Oberon(s).
* https://sites.google.com/site/rugxulo/BEFI_4Y.ZIP?attredirects=0=1
The various interpreters and compilers I successfully used (in DOS)
were as follows (not all mirrored to iBiblio, sadly, some are only
"freeware" or "non-commercial" or "shareware" and not Free/libre). I
can probably point you to most (or all?) of these.
Pascal:
= GPC/DJGPP, TP55, FPC, P5, TMT, VP (under HX)
Modula-2:
= FST, GPM/PC, GPM/DJGPP, M2M-PC, M2C, XDS (under HX)
Oberon:
= Oberon/M, Oxford (old DJGPP or newer MinGW under HX), GPO/DJGPP,
Edipar, XDS (under HX), Exaprog (under HX)
**
Long story short: FPC is probably your best bet. (3.2.2 just came out
but hasn't been mirrored to iBiblio yet.) FPC is more than adequate
for "most" things! Their {$mode tp} is very good, and they've (also)
supported the i8086-msdos target since 2015 in addition to
bog-standard Go32v2 (32-bit DPMI)!
* http://www.bttr-software.de/forum/board_entry.php?id=17823
* http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/pascal/
* https://wiki.freepascal.org/DOS
A good blog about Modula-2 (e.g. news about many things including
GM2/GCC, which sadly doesn't have DJGPP support ... yet?):
* http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/modula2/
* https://freepages.modula2.org/
Oberon is a bit more scattered, and DOS support is hard to find and
somewhat ancient, sadly.
* http://www.projectoberon.com/
* https://people.inf.ethz.ch/wirth/CompilerConstruction/index.html
You might also try asking in the DJGPP newsgroup (comp.os.msdos.djgpp)
about getting someone to help build this for you, but don't get your
hopes up (I've never tried, and things like this are usually
difficult, even via cross-compilation):
* https://miasap.se/obnc/
Oh! I forgot that XDS (for Win32) is now "open source" / Apache license!
* https://github.com/excelsior-oss/xds
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Smaller C
Hi again, On Wed, Nov 4, 2020 at 7:45 PM Rugxulo wrote: > > On Sat, Oct 31, 2020 at 4:11 PM Paul Dufresne via Freedos-devel > wrote: > > > > Well, after having a problem with IA-16 gcc (which seems to requires DJGPP > > gcc installed and working), I have search for an other free C compiler for > > FreeDOS. > > I can send you a .BAT to setup IA16-GCC in FreeDOS No takers? This is one of the few ways to build FOSS 16-bit DOS binaries in C. (Yes, you need p7zip due to LZMA method in the .ZIPs.) === I16GCC.BAT begins === @echo off REM ... takes roughly 52 MB of space! ... if "%RAMDRIVE%"=="" goto end if not "%DJGPP%"=="" goto end if exist %RAMDRIVE%:\i16\NUL goto end for %%a in (md pushd) do %%a %RAMDRIVE%:\i16 set D1=c:c:\tmp\tkchia p7zip920 x -x!SOURCE\* %D1%\i16gcc.zip >NUL p7zip920 x -x!SOURCE\* %D1%\i16butil.zip >NUL p7zip920 x -x!SOURCE\* %D1%\i16newli.zip >NUL unzip -qn C:\ZIPS\DJGPP\djdev205.zip >NUL set DJGPP=%RAMDRIVE%:\i16\djgpp.env set D1= call mypath %RAMDRIVE%:\i16\bin call mypath %RAMDRIVE%:\i16\devel\i16gnu\bin popd if not "%1"=="" i16gcc.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 :end === I16GCC.BAT ends === Just to reiterate, that old p7zip build (7za) was mine (from 2012) but still has latent bugs and missing features. I'm not smart enough to fix or document everything, but it "kinda" works. I have no idea if that particular version is "100% better" than the current package we now include (older 4.65). The only unique advantage was that I tried to support backslashes properly for paths, for convenience. "Testing" implies that it needs more work. * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/9.20.1/testing/p7z9201-latest.zip > > I have found Smaller C: > > https://github.com/alexfru/SmallerC/blob/master/v0100/doc/smlrc.md > > Note that I made a 3.5" 1.44 MB single-floppy .7z (compressed) DJGPP > installation years ago. It was fairly old even then (GCC 2.95.3, > BinUtils 2.16.1, DJDEV 2.03p2) with a few bundled utils, but it worked Try this, it should be good enough for reasonable ANSI C89 projects: * https://sites.google.com/site/rugxulo/DJGPP203.7Z?attredirects=0 (Yes, my site has full sources [20 MB, mostly in .tar.bz2]. No, it doesn't bootstrap atop FreeDOS proper yet, unfortunately.) > Note that SmallerC is always 386+ (same as DJGPP) but it can output > real mode (-dosh is default Huge) If you really want to be masochistic, you could "maybe" try the old shareware (real-mode-only) 386 emulator TSR (emu386) with SmallerC code. Maybe it'd actually work (186's int6)! I think ecm's fixed fork of 8086tiny supported "INT 6" properly, but I haven't tested this particularly. Still, it would be weird if it actually worked! (And someone here could easily reimplement that TSR [famous last words!].) * https://github.com/ecm-pushbx/8086tiny * https://github.com/barotto/IBMulator/wiki/Processor-Identification > He recommends YASM, which is much *much* faster than NASM here. * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/yasm/1.3.0/ (more rambling ahead) We already have TinyAsm (30 kb .EXE built by DeSmet) for 8086 + bin output. It can also be built with IA16-GCC. But to build it with SmallerC, you have to fix the old K function definitions. This is not a huge deal since most people have heavily preferred ANSI since forever (and then some). (L. Peter Deutsch wrote ANSI2KNR.C years ago, but I don't remember where it is. Perhaps old BinUtils source archives?? Dunno if that's a "better" solution here.) I ended up just writing a Sed script (admittedly somewhat sloppily), but it works. The ANSI-fied compiled .EXE (from Turbo C++ 1.01, for comparison) matches that of the original K version .EXE exactly. So I guess I didn't mess anything up! There are too many Sed derivatives (most old ones based upon code by Eric Raymond), yet none is perfect. I tend to test many implementations on my scripts just to weed out any accidental portability bugs. Even though Sed is quite simple and a POSIX standard, implementations vary a lot. IIRC, SmallerC will compile CSed but not MiniSed due to bitfields. And IA16-GCC has trouble with all of them (for other, unknown reasons) except ancient HHsed. But at least an IA16-GCC build of HHsed does seem to work (after defining __TURBOC__ [for prototypes? hey, this code was 1991] and removing an errant 0x1a from SEDCOMP.C). Well, it outputs *nix "LF only" text, even for DOS-style CR+LF inputs, which confuses some tools (as always, I don't know why that's such a prevalent problem, even nowadays ... unix2dos FTW!). So yeah, HHsed (circ
Re: [Freedos-devel] Simplifying FreeDOS
Hi again, Just FYI, if anyone cares, just to be more informed about such things On Tue, Nov 10, 2020 at 2:54 PM Rugxulo wrote: > > On Sun, Nov 8, 2020 at 7:31 AM Rugxulo wrote: > > > > Regina was (IIRC) compiled with Watt-32 due to external stack queue or > > whatever (rxqueue). You can almost certainly rebuild without it (I've > > done it) I need to go back and cleanly try to make a proper patch, but it does build successfully (Regina 3.9.3 from Oct. 2019) with DJGPP 2.05 (GCC 10.2) and works (no obvious slowdowns or regressions, e.g. rexxcps). That's without needing Watt-32, so it's only supporting the internal REXX "stack". It's about 220 kb UPX'd, which is far less than the 490 kb one we include already. (Honestly, I'd probably build both with and without Watt-32, just for completeness. DJGPP does have its own "port" of Watt-32 in /current/v2tk/ from last year, so it's probably best to prefer that.) I did also find my public copy (on iBiblio) of older Regina 3.5 built for EMX (GCC 2.8.1), which works fine with RSX + DPMI (since EMS has some obvious environmental bugs and caveats). I don't have GCC/EMX set up nowadays, so I'd have to check my backups, but it shouldn't be hard to get working again. Then again, I don't know of any obvious reason to prefer that over DJGPP. I also found Compact Rexx (CRX) archived on Mike's website (again), and while it worked for very simple programs, it didn't quite work for some of my tests (system resources exhausted). I have no idea if it's really that paltry on RAM, buggy / incomplete, or somehow getting confused (too much free??). It's originally from the late '90s, and the author was testing on a 300 Mhz laptop "for nostalgia". He sounded very competent, so it's probably still useful somehow. But there's a lot of auto-generated sources and other complications. It's probably not impossible to get rebuilt, but you need MASM 6.x (JWasm??) and Nmake (ugh). It's only 40 kb. (Remember that my TC++ build of MAWK [GPL] is only 60 kb UPX'd. Both languages are "standards". It wouldn't be a bad idea for FreeDOS to include AWK by default.) > But Regina is also slower to run [external procedures], moreso than just > typical > slowdown from simple path searches. I have no idea if that's DJGPP's > fault or not (probably not entirely, some is definitely my naive > code). Splitting out three of my procedures in one script slows Regina down > (on a 2010 laptop atop RAM disk) nine times: from half a second to four and a > half seconds! Being more idiomatic, removing the need for two trivial external functions (files) in lieu of better use of built-in functions (BIFs) saved some time, plus some "don't call unless needed" for the one big external procedure remaining helped a lot. So it's only 1.3 seconds now, roughly only 3x slowdown (instead of 9x) when separated out. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi again, On Sun, Nov 8, 2020 at 7:31 AM Rugxulo wrote: > > Regina was (IIRC) compiled with Watt-32 due to external stack queue or > whatever (rxqueue). You can almost certainly rebuild without it (I've > done it) > > > > Regina at least has some justification. Some later versions of PC DOS > > > came with REXX. > > > Even AWK and REXX have modularity via separate files, which > is interesting and almost surprising. > > > REXX is a very cool language (ANSI standard, too, in 1996). Just FYI: In REXX, external functions (in separate .REX files) are permitted, which is great for modularity (separation of concerns) and reusing code. But the functions must be immutable, so everything that is needed is passed as parameter, and you then return a relevant result from that. You also must remove the "procedure" keyword (Regina hates it) and forcibly rename the main module as "*.REX" (for BRexx, else it won't run correctly). But Regina is also slower to run that way, moreso than just typical slowdown from simple path searches. I have no idea if that's DJGPP's fault or not (probably not entirely, some is definitely my naive code). I'm also not sure what internal REXX caching is done either. (Regina can tokenize / byte-compile at cmdline, but I'm not sure if that helps speed at all.) Splitting out three of my procedures in one script slows Regina down (on a 2010 laptop atop RAM disk) nine times: from half a second to four and a half seconds! (REXX has a built-in timer for such tests.) It is definitely noticeable, but I do see an obvious optimization to add to my code (that will be unnecessarily redundant and verbose, but only very slightly). BRexx is very fast, regardless of external functions or not. I also tested two other REXX interpreters on Windows (ooREXX and r4), and they had similar slowdowns. I prefer not having tons of external dependencies and dozens of files to keep track of. Although lumping everything into one big file is bad, for very simple scripts (less than 1000 lines), it's probably not worth modularizing except for theoretical reasons. But I did whip up another quick REXX script to automate even that for me, so I don't have to tediously extract it by hand just to test such things. I know not many people around here prefer REXX, but it can be quite a useful language. However, if you already have QBASIC or AWK or Forth or similar, it's much less crucial. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi, On Sun, Nov 8, 2020 at 10:40 AM Mark Olesen wrote: > > DOS Chromebook? I do not believe FreeDOS could compete with the latest > web browser technologies. It is an interesting concept though.I > believe an attempt was made to Resurrect Amiga with a working machine > and desktop sometime ago. > > FreeDOS is fun stuff for sure. Every once in a while, I enjoy > tinkering around with it and sometimes programming in that > environment. I didn't mean a commercial project aimed at millions of people, just a niche toy for us nerds. Obviously we wouldn't have HTML 5, but we do already have ports of Lynx and Links2, Wget, Curl, FTP, IRC, etc. And of course we have DJGPP (GCC), OpenWatcom, SmallerC, FPC, FBC, NASM, FASM, AWK, Python, Ruby, Perl, etc. Thus, it should be possible to have a dedicated machine (or at least one with emulation) that would let us develop for FreeDOS more easily. Heck, maybe we would even gain more contributors! With the online popularity of Git (SCM) these days, it seems to imply that a Chromebook or similar Linux machine with Git installed, thus with QEMU for emulating FreeDOS, would be optimal for development (and maybe DOSBox for graphics / sound / cycle-throttling). But I'm specifically thinking of a non-generic laptop here. Heck, maybe something that dual boots into FreeDOS natively. But it's just a dream, and frankly, Linux has more marketshare (despite heavy fragmentation). As grateful as I am for FSF's "Respects Your Freedom" attempts, I'm not sure how reliable those are. Maybe I need to grab one and find out. But x86 hardware seems like a dead end, yet I don't know how much success or promise can be found on others (ARM? RISC-V?) for emulating legacy x86. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi, On Sun, Nov 8, 2020 at 8:10 AM Mark Olesen wrote: > > That sounds fantastic. It is unfortunate development was abandoned. > Having multiple choices seems like a good idea. TinyCore Linux also has a "Core" (11 MB) "base system which provides only a command line interface". The biggest problem is probably non-free / non-redistributable firmware, not the actual wireless drivers. (My ancient Dell laptop has BCM4312, which is a minor pain to get working.) > Q: Does anyone know if DELL still uses FreeDOS for firmware and BIOS > updates? Or maybe they used to ship a computer with FreeDOS as the > primary OS? > > At one point, I know they did. I have not kept up with the times, > however. I would imagine it would be very lite? I know almost nothing, but the only link I can think of is this one: * https://www.dell.com/support/article/en-us/sln171755/update-the-dell-bios-in-a-linux-or-ubuntu-environment?lang=en#updatebios2015 But keep in mind that BIOS/CSM is effectively dead: * https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#CSM_booting "In November 2017, Intel announced that it planned to phase out support for CSM by 2020." I don't know the exact rationale. It may be to remove support burdens, reduce costs, speed up booting times, or just drop unnecessary legacy. Actually, I half got the impression it was for power management / battery life reasons. But it could also be for security (secure boot?). (Windows is still 80% marketshare, everything else considered relevant is "POSIX" [usually Linux]. Hence nobody majorly needs BIOS/CSM anymore, AFAIK.) > I have an OpenBSD Lenovo A485 laptop rig. Since I do not run Windows, > they provided a bootable ISO. I have no idea what they are using? IIRC, FreeBSD has the best hardware support out of all the *BSD family. The big differences with OpenBSD are that they refuse NDAs, insist on building atop actual hardware, support various sentimental machines, and also have a monolithic kernel with no separate modules. (Corrections welcome, I could be wrong.) Apparently 6.8 was just released last month for their 25th anniversary. (I've only, very barely, tried earlier versions under VM.) Then again, I was surprised (a few years ago) that FreeBSD was still supporting ancient ARMv6 (early RaspPi??), but even there, the only Tier One platforms are AMD64 and i386 (with various others under Tier Two). Even most Linux distributions (e.g. Ubuntu) have dropped i386 support. There are many full Linux laptops for sale these days. I'm looking to buy one myself soon. This Dell Chromebook isn't too shabby either. (We really need a DOS Chromebook. Obviously it won't have Chrome. Or at least something that can run QEMU. This one does [Linux "beta", cmdline only, optional], but I don't think it allows switching OS images, probably for security reasons.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi again, (Sorry in advance for the ramble.) On Tue, Oct 27, 2020 at 2:06 PM Rugxulo wrote: > > On Sat, Oct 24, 2020 at 4:21 PM Steve Nickolas wrote: > > > > On Sat, 24 Oct 2020, Eric Auer wrote: > > > > > Regina REXX was not very small, while some others are small? Regina was (IIRC) compiled with Watt-32 due to external stack queue or whatever (rxqueue). You can almost certainly rebuild without it (I've done it), but I don't think the code supports 16-bit cpus. Even the smaller BRexx 16-bit build from 2003 isn't 8086-friendly (not sure, 186??), plus it's non-commercial only (not quite GPL). I also have a newer DJGPP build of BRexx from 2011, it's only like 110 kb. (It's always "interesting" testing code between various quasi-compatible interpreters. There's always dozens of caveats and dark corners and bugs. But it's amazing when portable code works!) Years ago, I put old Perl 4 [sic!] (16-bit) on my RUFFIDEA floppy just to have "something" scripting-wise, even though I never learned Perl. It was really only useful for "ztouch" (touch .gz from internal date, if found). Although I later wrote a sloppy and unportable (but functional!) version in REXX (both Regina and BRexx supported)! I never did finish writing a simpler C version (mktime(), utime()). I also lamented not just throwing REXX on floppy instead, but perhaps AWK (which?) would've been a better fit overall. I did recently rebuild old MAWK with Turbo C++ 1.01. UPX'd it's only 60 kb (compared to the family / bound DOS + OS/2 build which can't compress and is 160 kb). In some ways, MAWK is better than other ports (e.g. memory efficiency). With one script of mine, it works where our 16-bit (G.K.'s OW build, 2010) BWK's AWK doesn't. (32-bit builds of BWK work fine, as does 32-bit DJGPP Gawk. Again, it's always good to test on all available interpreters to weed out hidden bugs and non-portable issues.) > > Regina at least has some justification. Some later versions of PC DOS > > came with REXX. > > Yeah, it replaced QBASIC there. QBASIC only gets about 160 kb free memory (at best), no overlays nor extended memory, plus there's no modularity, not even include files (sadly). Even AWK and REXX have modularity via separate files, which is interesting and almost surprising. I actually dislike extreme modularity where you have too many separate files all over the place, but it can indeed be very useful. > REXX is a very cool language (ANSI standard, too, in 1996). It's almost too complex with all the (extra) features and extensions. But the base language is quite simple, almost BASIC-ish. Not as simple as Sed, but Sed is not a real programming language (no variables, no arithmetic). But, like I said, Regina is 32-bit (or 64-bit) only, AFAIK, so I don't think it'll build for 16-bit, which may annoy some of us purists. But it's still quite good. (Oh, there was CRX [Brian Marks' Compact Rexx] which was 16-bit, but I never delved too closely into it. I think it was buggy, but it was used for verifying standard code, back in the day. I forget the license, but IIRC it was written in MASM. I should take another look.) > Our Regina build (ANSI only, no OOP) is mine from 2012 using DJGPP. > Later sources had bugs that I never dug into that made it refuse to build. Trisquel had an even older Regina (3.6?)! Sheesh. Sometimes it's weird how packages are never updated, but I don't blame them (tedious). Anyways, you used to also be able to rebuild Regina via GCC/EMX, which I've done a few times (years ago) for fun. Not sure that's really "better" than DJGPP, though. Anyways, I've just been messing around with PSR Invaders (yet again), writing various scripts to convert MASMv4 syntax to various Free/libre assemblers (e.g. NASM, FASM, TinyASM). So that's my limited experience. Just FYI. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi, On Sat, Nov 7, 2020 at 2:24 PM Mark Olesen wrote: > > Great idea. I like minimalism. However, I don't think networking > drivers are up to snuff to completely automate the process. This has already (unofficially) been done. * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/metados/ But it still needs cleaning up (and some things haven't been properly vetted, e.g. Curl, which is not included by default). But it does have two packet drivers that work with (old and new) QEMU and VirtualBox. These are also used by the FDNET package, but Jim seems almost uninterested in that. N.B. Even Trisquel GNU/Linux has a "net install" (only 42 MB!) .ISO download. Perhaps trying or recommending such things from Linux would be wiser as a starting point since they have much better hardware (e.g. network) support. > On Sat, Nov 7, 2020 at 1:46 PM Chelson a wrote: > > > > Why not have a simple floppy that can install the system via internet > > connection? > > > > Base cd, extras cd and boot disk with internet install? > > > > > > > > On Sun, 8 Nov 2020 at 05:37, Mark Olesen wrote: > >> > >> Why not have a minimal install iso. Then have separate additions iso > >> for each category? Could the install handle that? ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi,
On Tue, Oct 27, 2020 at 2:15 PM Rugxulo wrote:
>
> (AFAIK)
> Perl 6 was officially renamed Rakudo.
Apparently the language proper is "Raku" ("camel" in Japanese, like
the old mascot) while the only current major/stable implementation is
Rakudo (Artistic License 2.0, FTW!). The website "perl6.org" just
redirects to "raku.org" (and has the same new mascot, Camelia the
butterfly with the embedded "P6" symbols). It was renamed in October
2019 for ... reasons.
Perl 6 was originally initiated circa 2000, so it's been a long time
coming. Apparently it targets various VMs (including JVM and JS) but
seems to prefer MoarVM. Apparently you can build NQP (Not Quite Perl,
"a lightweight Raku-like environment for virtual machines") with only
Make and Perl 5.8. (No, I doubt it will build with DJGPP, but I
haven't tried.)
Sounds complicated (like almost everything else). Good luck to them.
Just FYI.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Smaller C
Hi,
On Sat, Oct 31, 2020 at 4:11 PM Paul Dufresne via Freedos-devel
wrote:
>
> Well, after having a problem with IA-16 gcc (which seems to requires DJGPP
> gcc installed and working), I have search for an other free C compiler for
> FreeDOS.
I can send you a .BAT to setup IA16-GCC in FreeDOS, if you're having
trouble. It may have a few rare bugs, but it's not bad. (I used
p7zip920 to unpack.)
> I have found Smaller C:
> https://github.com/alexfru/SmallerC/blob/master/v0100/doc/smlrc.md
SmallerC is genius, and I've played with it several times over the years.
> I note: Smaller C is not an optimizing compiler, but it does the job better
> than the typical small C implementation.
Note that I made a 3.5" 1.44 MB single-floppy .7z (compressed) DJGPP
installation years ago. It was fairly old even then (GCC 2.95.3,
BinUtils 2.16.1, DJDEV 2.03p2) with a few bundled utils, but it worked
well (in moderate testing). There are other options, too, but it
depends on what you want and are trying to do.
Note that SmallerC is always 386+ (same as DJGPP) but it can output
real mode (-dosh is default Huge) and several models (not sure if
they're fully supported, though, e.g. "-dost"). "-dosp" is the 32-bit
pmode / DPMI version using CWSDPMI while -dosu is "unreal", IIRC.
SmallerC isn't really optimizing, no, so even ancient GCC 2.95.3 is
probably faster, but anything is faster than Turbo C 2.01 (buggy /
unbuffered by default). That problem was apparently later corrected in
Turbo C++ 1.01.
> I installed it in a new minimal FD-1.3-rc3 image (more like injected it in
> QEMU qcow2 image, by using:
> https://gist.github.com/shamil/62935d9b456a6f9877b5 ), and was able to
> compile test.c:
It's very easy to setup and test, IMHO. I even used it as a .BAT test
in my MetaDOS image.
> #include
> void main(){
> printf("Smaller C is fine!\n"); // Oh well, I change a bit the string here
> }
1). Why C99 comments?? SmallerC "mostly" supports C89 with some bits
of C99, too.
2). int main(void) or (int argc, char** argv) is preferred.
3). puts() is simpler (and implies "\n" at end).
4). You didn't "return EXIT_SUCCESS;"
5). You may wish to use some Lint (maybe DJGPP's port of Splint). Or
at least compare your code with "gcc -std=c99 -pedantic -Wall
-Wextra".
> directly from the ...\SMALLERC\V0100\BIND directory with:
> smlrcc test.c -o test.exe
"-Wall" might sometimes (rarely) help here. (Not sure he really
intended to warn on literally everything.)
> resulting in 20k test.exe by just installing nasm and make sure it is in PATH
> (Apparently come with a linker for ELF format to DOS 16 or 32 bits format).
He recommends YASM, which is much *much* faster than NASM here. You
can also use FASM ("-asm n2f") for 32-bit only (e.g. "-dosp"). You can
also "set NASMENV=-O0" for a small speedup, if you don't have YASM.
> The compiler executables are about 700k, but this does not include libs and
> includes.
It's very portable and can even rebuild itself. It's truly great work.
> You should probably be aware of this issue:
> https://github.com/alexfru/SmallerC/issues/26 (Virus/trojan false positives:
> SMLRC has many false positives on Windows #26)
All of those are bogus (yes, I already told him), usually because of
"heuristics" (aka, blind guesses) which are usually wrong. It stinks,
but AV companies are sloppy (but also have a lot to deal with).
> License seems BSD: https://github.com/alexfru/SmallerC/blob/master/license.txt
>
> I think I'd like to have it in FreeDOS 1.3.
I halfway wanted to make a proper package years ago, but I never found
the time nor energy. There's just too much to do, and I'm very easily
distracted these days.
But SmallerC is amazing, and Alexei is a genius. I would strongly
recommend somebody (Jerome? Jim?) mirror this to iBiblio "as is". A
proper package can come later.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi again, Just to clarify On Tue, Oct 27, 2020 at 2:15 PM Rugxulo wrote: > > On Sat, Oct 24, 2020 at 6:27 PM Jim Hall wrote: > > > > Another thought: how outdated is this DOS version of perl? > > Our build of 5.8.8 (from DJGPP) is from 2008. Not quite, but close enough. Our build (at least the one I have on hand) is from 2007 while the copyright itself is from 2006. > For most basic things, I would greatly prefer AWK or Sed. > > I'm not aware of much in FreeDOS that would need Perl. (Devore's NoMySo does, > but few here seem to use it.) The full PERL588B.ZIP (from DJGPP 2.04 /beta/ ... ironically probably the exact same .ZIP in 2.05 /current/ nowadays, from a quick glance) that I have here unpacks to 39 MB. If you piecemeal unpack a few pieces individually, you can minimize that a lot. I was able to get Devore's NOMYSO working in only about 2 MB of space (hence omitting most of the 2000+ files). It still has a few bugs and is quite slow, but it mostly works. (The big advantage is converting implicit data sizes into explicit overrides and adjusting weird bracket displacement syntax. It doesn't handle "Assume" seg overrides at all, though.) I also, years ago, found yet another Befunge-93 interpreter written in Perl (IIRC, by a guy nicknamed mtve). Not only did I put it inside a self-contained .BAT (yes, you can do that), but I also slightly adjusted it (one syntax change) so that it would work even on ancient 5.005 (which was much smaller). (IIRC, 5.005 was just before 5.6.) Just FYI in case anybody finds that interesting. It's almost a shame that nobody knows or uses such things anymore. There's a lot of lost art lying around in computing. Anyways, I still prefer Sed or AWK. I actually wrote a (very flawed) AWK script yesterday to auto-adjust implicit data sizes. Previously I was just doing a functional but very simplistic kludge in Sed (two passes, temporary files). I was really trying (with AWK) to do it all in one pass in RAM, but so far I've only half succeeded. But it does work (mostly). Actually, even that isn't needed with Sed if the assembler supports EQU or %define (it can be written to a separate include file), but some assemblers don't (or are buggy). Yeah, there are no quick fixes for difficult problems, and old code often needs a lot of work. I'm just trying to get a better understanding of the basics. No miracles performed here. Still, it's cool. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Obsolete DJGPP in upcomming FreeDos 1.3
Hi, On Wed, Oct 28, 2020 at 7:56 PM Jerome Shidel wrote: > > Aren’t there nearly 100 DGJPP packages? Any others needed or should be added? > > Like I said, I don’t use DGJPP and am not very familiar with it. Someone who > actually uses it should work on making the updated packages. Getting all the (huge!) sources and dependencies is the most worrisome part to me. Not that most people care anyways, it's just tedious (especially since these will only cross-build). The README.1ST or Zip Picker should give you some idea. * ftp://ftp.delorie.com/pub/djgpp/current/v2/readme.1st * http://www.delorie.com/djgpp/zip-picker.html Long story short, you don't need much beyond DJDEV*, BNU*, GCC* (and probably MAK*) for bare minimum. Add GPP* for C++. (Maybe add a third-party lib like PDCurses or FSU Pthreads or Allegro or Zlib, if you really want.) Everything else is optional. Bison and Flex aren't needed by 90% of things or people. Even GDB is technically optional (although RHIDE/RHGDB is obsolete and too old to be much use anymore). TexInfo is just for documentation, and while somewhat useful, you can do without (since it's just plain text with hints for navigation) or use (huge!) GNU Emacs. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi, On Sat, Oct 24, 2020 at 6:27 PM Jim Hall wrote: > > Another thought: how outdated is this DOS version of perl? I know it's Perl > 5.8.8 and the current version is 5.32.x. > But how "far apart" are those two versions? (It's been years since I > intentionally wrote a perl script, so I don't know.) I've never done any Perl programming. (I have an old book from my brother, but neither of us ever read it.) But I greatly respect Larry Wall. It's not perfect (nor is anything), but it can sometimes rarely be useful (e.g. rebuilding NASM instruction tables to save RAM). (AFAIK) Perl 6 was officially renamed Rakudo. Perl 7 is the "next generation" based upon Perl 5.32 (with "shrinking" [??] backwards compatibility, saner defaults [use strict ??]). Perl 5 has been around, in various forms, since 1994. Our build of 5.8.8 (from DJGPP) is from 2008. To be honest, there are so many languages that everything overlaps: Python, Ruby, REXX, AWK, Sed, etc. For most basic things, I would greatly prefer AWK or Sed. I'm not aware of much in FreeDOS that would need Perl. (Devore's NoMySo does, but few here seem to use it.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi, On Sat, Oct 24, 2020 at 4:21 PM Steve Nickolas wrote: > > On Sat, 24 Oct 2020, Eric Auer wrote: > > > Regina REXX was not very small, while some others are small? > > Regina at least has some justification. Some later versions of PC DOS > came with REXX. Yeah, it replaced QBASIC there. REXX is a very cool language (ANSI standard, too, in 1996). TRL2 (1990) was version "4.00" while ANSI was "5.00" and the newer (non-standard) OOP variant ooREXX is version "6.00" (can be detected at runtime and your source can branch accordingly). It's garbage collected, no reserved words, an "easier PL/I", meant even for non-professional programmers, with few arcane symbolic "line noise" needed. No dangling pointers nor manual memory management needed just to use linked lists! (Howard Fosdick gives away his REXX book [PDF] for free on his website.) It's roughly the same capabilities as *nix/POSIX AWK (which is also quite useful and has some good DOS ports). I don't know if ooREXX will build with DJGPP. Probably not, but I haven't checked lately. IIRC, it required C++ and Pthreads. But maybe DJGPP's FSU Pthreads (like in p7zip) would let it "mostly" work?? Honestly, I don't grok any of the Smalltalk-esque OOP stuff (but the newsgroup users always seemed to love and prefer it). Our Regina build (ANSI only, no OOP) is mine from 2012 using DJGPP. Later sources had bugs that I never dug into that made it refuse to build. You could maybe argue that even rebuilding 3.7 with DJGPP 2.05 (or newer, more powerful GCC) might bring some benefit. Dunno. But he did (barely) update 3.93 last year (after several years of inactivity). I haven't checked lately to see if I could rebuild it. I probably need to do that (since, indeed, I started getting back into it a little bit). Just FYI, in case anybody is curious. (No, I never used PC-DOS, but I'm sure it's good ... but not as good as FreeDOS!) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Simplifying FreeDOS
Hi,
Sorry, I'm late to this thread, but ... I don't feel like reading ten
pages before quickly responding to this misunderstanding.
On Sat, Oct 24, 2020 at 2:39 PM Jim Hall wrote:
>
> Over time, FreeDOS has grown to include lots of interesting programs. The
> FreeDOS 1.2 and 1.3RCx distributions are very big.
>
> As we look to the next FreeDOS 1.3 Release Candidate, I think we should
> consider removing some packages from the FreeDOS distribution.
>
> To be clear: I am not suggesting deleting packages or programs from the
> FreeDOS archive at ibiblio.
> There's lots of useful and interesting programs there. But I don't think we
> need to include everything in the FreeDOS distribution.
If you keep networking (FDNET), at least for QEMU and/or VBox, then
you can offload as much as you want to further downloads. That way is
simpler, IMHO. But clearly we're not trying for extreme minimalism
here (like MetaDOS).
> Here are my thoughts from the FreeDOS 1.3 package list (wiki)
>
> Archivers
> Do we really need all of those archivers? For example, who needs Zoo these
> days? My suggestions:
> 1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of Unix
> tools
> 2. Keep zip, unzip, p7zip
> 3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma, lzop, zoo
>
> *Note that p7zip can unpack a ton of other file formats, so we don't need
> these other archivers anyway.
I've explained several times that p7zip is very buggy. It has many
versions (for DOS/DJGPP) and many flaws. I do not consider it as
"standalone" nor totally stable. (Even worse, our package is an
archaic version, 4.65.) In particular, very few people seem inclined
to rebuild to even attempt fixes. I've done so before (despite limited
skills) and did some fixes with 9.20, but it's never going to be
perfect. Even M.K.'s latest build of 16.02 I didn't mirror
(particularly because it included non-Free RAR support, which you
dislike). I also didn't find the time to diff his changes since he
just included one lump source archive instead of a separate patch. His
build still has many bugs and idiosyncrasies due to the POSIX nature
of the port (and the Win32-centric nature of the original sources). It
doesn't mean it's useless, far from it, but it is indeed tedious to
use.
7zdec is very simplified, so it lacks some things ("-x!" can be very
useful in rare circumstances), but it's much cleaner and smaller, if
you're only interested in simply unpacking entire .7z archives. I
would definitely not exclude it. (In fact, I emailed you recently
saying I personally wanted to update it to a newer version.)
> Development
> Can we pare down the list a bit? We have a lot of packages here, but I don't
> think we need them all.
> For example, we should include the tools we know we'll need to compile the
> different FreeDOS utilities.
> I'd also like to keep the GCC related packages, and other packages that
> remain popular.
By far, DJGPP and FPC take up the most space, IIRC, but few people
here use them (from FD packages, I mean, most just grab newer versions
upstream). That doesn't mean they aren't incredibly useful, just that
we never seemed motivated enough to update the DJGPP packages (which
get even huger in newer versions). I halfway suggested before that we
make "DJGPPLITE" (GCC 2.95.3 or 3.46?) or "FPCLITE", but nobody seemed
to even acknowledge the usefulness of that idea. (Yes, I saw Andris'
recent email about DJGPP 2.05 / GCC 10.2. Honestly, I'm not sure how
to 100% bundle all the appropriate sources [MPC? MPFR?], which are
huge and impossible to build in raw DOS anyways.) AFAIK, there's
little reason to have a separate BinUtils anyways since no other
package relies on it besides GCC (which, in newer versions, also
requires newer BinUtils). FPC doesn't really need it anymore, and FBC
has its own older version.
> Editors
> Not sure about these. I know there are a few here I'd like to keep:
> Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim
Probably not, honestly, but it's not the end of the world. There's too
much stuff. I'm not direly opposed to anything that works, but some
things are very flawed.
> Networking
> I don't run FreeDOS with a network, so I don't have any opinions on these
> packages. What do you think?
FDNET just borrows from Crynwr, but without it we can't have a working
packet driver under QEMU. I would consider removing it "a downgrade /
loss of useful functionality" (but maybe you're still worried about
the confusing licensing text??).
> Utilities
> We have a mix of things in this package group. I think some of these were
> interesting long ago, but probably aren't used anymore and can be deleted. My
> recommendations:
> 1. Keep aefdisk, ansimat, bootfix, callver, cdrcache, cdrom2ui clamav +
> clamdb, cpied, cwsdpmi, dialog, dn2, dog, dos32a, dosutil, doszip + dzemm,
> fdimples + fdisrc, fdnpkg, fdshield, fdtui, foxcalc, foxtype, gcdrom, gnuchcp
> + gnufonts, hexcomp, localize, lptdrv, memteste,
Re: [Freedos-devel] Thought I'd mention - An updated bc(1) for 16-bit DOS
Hi, On Wed, Sep 2, 2020 at 4:27 PM Steve Nickolas wrote: > > GNU's bc ... I ported it to DOS using Borland C++ 3.1 I'll be honest, although I've heard of it, I'm not directly familiar with the syntax of "bc", but thanks for the port! I'll look closer eventually. (The makefile is a bit confusing and could use some cleanups, IMO.) > Last night I sent an e-mail to the author asking if he was able to do the > same with dc, and expressing curiosity at the license change. He said he > wasn't (since dc was written by someone else, just shared some of its code > with bc), Years ago, one guy (Greg Ubben) wrote most of a "dc" clone in Sed (presumably p.d. since .mil)! * http://sed.sourceforge.net/local/scripts/dc.sed.html While I've not really used this script at all, I have delved a lot into Sed, even on DOS. > and explained that he had balked at the GPL3, but that he had > retained rights to the code so that he could maintain it separately for > Minix ... 3-clause BSD license, and that's the one I ported to DOS. > > http://6.buric.co/dosbc.zip Jim has mirrored this to iBiblio now: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/bc/ Thanks again. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freecom beep / stuck freedos core components
Hi, On Wed, May 13, 2020 at 5:04 PM tom ehlert wrote: > > > Please shed some light on the well known reasons. > see Bart's 29 dez 2019 mail in freedos-devel Sorry, I'm preoccupied, so I haven't been doing as much contributing to FreeDOS as I'd like. So I haven't tested the latest pre-release (though I'm a good candidate to try it, it's very useful to me, at least non-professionally). > in https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/ there are > no recent changes. could the 'leader' please specify where official > sources are, who is official maintainer, aso. AFAIK, the maintainer is Jeremy Davis, and he last updated it on his Github 13 days ago: * https://github.com/PerditionC/fdkernel But I don't know his plans, don't have frequent contact with him, and only vaguely remember an email from a year ago from Juan Manuel Guerrero (DJGPP dev) about improvements in trunk (that I never investigated). That would be worth checking, but I haven't had the time nor energy. > > Is kernel development officially dead? How about freecom? > not officially. just as a matter of fact. It can always be restarted if anyone is interested in doing the work, of course. For most people, either it's good enough, too complicated to fix, or not important enough. (Or maybe "real life" worries take precedence.) Let's not sweat it too much. It's not the end of the world. > writing and running a couple of .BAT files would be cool. To do what or test what? I've written dozens of .BATs over the years of varying quality. I'm not holding back any amazing scripts. Most of my stuff is public, but it's a bit disorganized. MetaDOS had a bunch (albeit spaghetti code) that was partially used as test, IIRC. But I haven't had time to go back to that to try to kick the tires some more. I'm definitely in favor of improving FreeCOM and making sure it works on "Free" compilers. But I've also never rebuilt it (correctly), and it's a scary behemoth. Then again, I've had a bit more experience since then, so maybe I should try again. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] beep implementation
Hi,
On Fri, May 8, 2020 at 10:48 AM Johnpaul Humphrey wrote:
>
> I am running FD12 on an HP Pavilion that is about three years old.
This was reported at least twice in recent years:
1). 2016-May-6: "[Freedos-devel] Beep command can't stop sounding when
run in Intel Skylelake platorm."
* https://sourceforge.net/p/freedos/mailman/message/35068370/
2). 2017-Jun-9: "#189 Beep function freezes on recently intel platform
(skylake/kabylake)"
* https://sourceforge.net/p/freedos/bugs/189/
As shown there, while I don't have such new hardware, I made a small
binary patch to remove beeping.
(old standard TC++ build of FreeCOM 0.84-pre2 XMS_Swap from 2006)
("upx -d command.com" first)
--- binary patch begins here ---
Comparing COMMAND.OLD and COMMAND.COM
8293: 55 C3
82AF: 55 C3
So you can grab the default COMMAND.COM from my small floppy .img from
MetaDOS, if that'll help you (7-Zip's "7z" can extract from .img),
since I disabled it there:
*
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/metados/metados-0.7.zip
* https://sites.google.com/site/rugxulo/p7z1602b.7z?attredirects=0=1
*
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/archiver/7zdec.zip
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
