Re: [Freedos-devel] FreeDOS Runtime
Hi,
(Sorry for being late to this discussion, I'm a bit backlogged.)
On Thu, May 2, 2024 at 7:05 PM Jim Hall via Freedos-devel
wrote:
>
> On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
> wrote:
> [..]
> > *Runtime*
> >
> > Jim's version is a small C program, 120 lines, using catgets
> > for messages which can be translated in different languages.
> > The binary is a 22kB EXE (31kB without UPX). There were text
> > files with EN, RU, DE, HU and LV translations, I believe?
The latest version of Jim's on iBiblio appears to be 2.1d from 2005.
It has a "Borland TC makefile" using "-mm" (medium model? why?) and
-DNDEBUG in addition to linking to Kitten. The .EXE is 26 kb,
presumably UPX'd, and I'm guessing it uses floating point emulation
(which is unlikely to help much and is extra bloat that is totally
unnecessary for any Pentium or newer FPU-having cpus).
Not trying to nitpick (I've also been looking at old code of mine from
2013 called TIMEIT.C), but just FYI
1). his code isn't ANSI C89
= why include dos.h or process.h ? it says for exec() but uses
spawnvp(), I would normally prefer system()
= does that save memory? are we intentionally trying to avoid shelling
out to %COMSPEC% except for .BATs or built-ins?
= CLK_TCK is not ANSI (old 1988 POSIX???) and not at all preferred,
use CLOCKS_PER_SEC
2). Borland does use 64 kb of heap by default in the smaller data
models. To avoid that (and save a bit of memory, esp. since we're
shelling out), put "extern unsigned _heaplen = 1024;" and "extern
unsigned _stklen = 8192;" in your source. Try shelling out "mem /c" to
see the difference. (Maybe this is why he randomly chose "-mm" Medium
model?? Unnecessary, I'd just use Small.)
3). You really don't need printf() at all here (okay, maybe only for
Kitten ??). It doesn't matter as much for Turbo C, but even for
OpenWatcom it's like 6 kb. If you don't need floating point (see
below), you can make do with a simple "writelong()" routine and save
space. (Yes, I wrote such a routine, if you need it.) FYI, clock_t is
usually a typedef to a "long" integer.
4). In my program, I included both clock() and difftime(). My memory
(and notes) indicate that clock() was for integer times. You know, for
most simple uses, a round number of seconds elapsed is good enough
(and faster / smaller, no bloated and slow emulation lib or expensive
FPU needed). How often does 11 secs. versus 11.5 seconds matter?? A
naive Google search shows people advising to cast it to double! But
that defeats the whole point, IMHO. All the compilers I checked (about
a dozen) all have an integer value for CLOCKS_PER_SEC ... except Turbo
C! There it's 18.2 (for no good reason). Quick: undefine that and
redefine it to 18, that's good enough, IMHO. Or just use OpenWatcom.
> > My version is a small ASM program, made with NASM. It has
> > a main file, circa 450 lines, and a language include file,
> > circa 150 lines, which at the moment contains EN, DE, NL,
> > PT, ES, FR, TR, IT, PL and RU messages :-)
The 2012 version on iBiblio pointed to by Fritz was my unofficial hack
with EO (Esperanto) support.
Checking the latest "2024" version hosted online, it only adds HU but
omits EO. (That's fine if no one cares, but it feels like a
regression.)
> > As a task left as an exercise for the user, one could port
> > the C version to Tom's small KITTEN alternative to CATGETS.
2.1d from 2005 uses Kitten. The MAKEFILE.TC says this:
LDLIBS=kitten-b\kitten.obj
> > My preferred option would be to add HU and LV translations
> > to my small RUNTIME and use that instead of the big one ;-)
Most of that bloat can be removed in one of two ways:
1). use TC's -f87 or WCL's -fpi87 (mandatory hardware floating point
usage, no emulation)
2). use TC's -f- (avoid floating point entirely) only with
integer-friendly clock() and printf("%ld") code
> I wrote the Runtime program, so I guess I'll speak to that.
>
> This is a very old program. I don't remember why I wrote it, but I'm
> sure I was doing some debugging on a program and was trying to
> fine-tune the performance, and needed a way to test how long it took
> to run after making improvements.
A naive way would be to use "PROMPT $t" and leave a TEST.BAT without
any "@echo off", and just calculate the difference shown in your head.
FreeCOM also (non-standard) supports "time /t" to print the current time.
> There are lots of programs out there
> to track the run-time of a program on DOS, and I probably gave a quick
> look around
I forget what 4DOS uses. Some programming languages (e.g. QBASIC and
REXX) have easy timing built-in. DJGPP always had "REDIR.EXE -t", and
DJGPP's port of BASH has the standard *nix shell built-in "time"
command. (DJGPP's libc also has uclock() which tries to use Pentium's
RDTSC or automatically falls back to something else via SIGILL if that
fails).
> I'm in favor to swap out the old Runtime with this Runtime. No issues here.
One minor enhancement would be to consider stderr
Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)
Hi, On Mon, Jun 17, 2024 at 6:41 PM Jim Hall via Freedos-devel wrote: > > You might be interested in this video I recorded yesterday about > running FreeDOS on the Pocket386: > https://www.youtube.com/watch?v=2h96UseZs6Q > > It shows several apps and games on the Pocket386, mostly running some > shareware games, plus Word for DOS, and As Easy As spreadsheet. Definitely cool. More videos of testing would be interesting. Try rebuilding the FreeDOS kernel with OpenWatcom on it, heh. Or install ZipSlack [Slackware 11, 2006??] Linux atop your FAT partition, I think it supports 8 MB of RAM. (Seriously, people always suggest an old Linux distro instead of DOS, but I think that's not realistic in most ways. Still, no worse than trying to run ancient Windows 3.1.) > If you're curious about its performance, here's a quick rundown of some > games and apps: [not all of these are shown in the video] > > Games: > > - Doom - runs fine at small size I did leave a comment suggesting Fastdoom from Github, which has been specifically optimized for 386s and 486s. * https://github.com/viti95/FastDoom > - Duke Nukum - runs fine, uses PC speaker 3D, right? Not the original 2D one? > - Rise of the Triad - runs fine at small sizes, uses AdLib for sound I forgot this was 386 DOS4GW. (It's based upon an improved Wolf 3D engine, which was 286 / VGA.) I assume Wolf 3D would run faster but maybe not. Hmmm, I vaguely recall some OpenWatcom 386 rebuilds of Wolf 3D. * https://github.com/TobiasKarnat/Wolf4GW > - Shadow Warrior - doesn't run (requires 9MB, this has 8MB) I have no idea. DOS4GW 1.97 is limited in total RAM available, but it does supposedly support VM swapping. But maybe they disabled that here (and/or it's too slow to be usable). You could also try "CWSTUB blah.exe" which supports swapping, but that may not work. > - Tomb Raider - crashes during setup (not a surprise, this is a 1996 > game and requires way more memory and CPU than this laptop has - the > game should have done a memory check) I don't think the Pentium (1993 debut) was really widespread even in 1996 (too expensive), but indeed it was much faster. But I also don't think a lot of things were optimized for legacy hardware (actual 386s) even back then. Quake (1996) has no chance on this machine, for instance. > - Wolfenstein 3D - runs great! Oh, okay, you did test this (it wasn't shown in the video). > - Biomenace - runs fine 286 / EGA, I love that game! > Apps: > > - Borland Turbo C++ compiler - editor runs fine, I've used the > compiler to write a few test programs, no issues there It seems quaint, but back in the day they told us the "optional" math coprocessor was an unnecessary expense and "wasn't needed" unless we were going to do a lot of scientific calculations. Normal home users didn't "need" it. (And of course every cpu since the Pentium has it included by default, go figure. Some software like GCC always assumed an FPU present.) Even ignoring that, the 386 itself was not pipelined like the 486, so the fastest instruction was like 2 clocks. So a comparably-clocked 486 (40 Mhz) would, in theory, run twice as fast. Also 486s often had (very small) on-chip caches which helped. But as far as cpu instructions, the 486 only offered very little advantage. Some expert (Michael Abrash??) once said that the 8086 and 386 preferred small code while the 486 was very sensitive to (code and data) alignment and preferred more RISC-y simpler unrolled code. I'm far from an expert, but docs always warned about AGI stalls and using suboptimal code sequences, even suggesting "blended" code (or separate code paths for distinct cpus). One thing that always bugged me was how much slower GCC (DJGPP) got in later versions after 2.7.2.1. That version ran okay on my 486, but later versions like 2.95.3 (even with -O0) ran much slower. In the race to constantly upgrade to newer hardware, a lot of software was just never optimized properly because nobody cared enough. In fact, I recall that GCC claimed that their 486 code was just the exact same 386 code only with extra alignment. Sad, really, that it never got the full support it deserved. (You can actually rebuild GCC 2.7.2.1 in DOS, I've done it. On my old Pentium it took about 10 minutes. I miss the days when things were simpler and faster!) I don't think GCC even got Pentium support until later (2.8.1). Pentium-scheduled code (U and weaker V pipes) was a big improvement on those machines (and no huge slowdown on older cpus). Not everything can be "fixed" or optimized to run at lightning speeds on such machines, but at least some noticeable improvements are definitely possible. Seriously, most code is just suboptimal, and without proper testing on old hardware you'll never be aware of it. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)
Hi,
On Mon, Jun 17, 2024 at 6:42 PM Jim Hall via Freedos-devel
wrote:
>
> I wrote a "how-to" article about FreeDOS on the Pocket386 for
> Both.org, but I also copied/pasted this into a wiki article on the
> FreeDOS wiki:
>
> Now that I've reinstalled the Pocket386, my next step is to test every
> application and game from FreeDOS T2406. If you're curious how an app
> performs on FreeDOS on real hardware ('386-SX at 40 MHz, 8MB memory)
> I'll share notes in a follow-up thread.
Definitely interesting!
Since I don't have working legacy hardware anymore, I've done some
light, informal benchmarking of various tools under DOSBox-X (a "fast
486") in FreeDOS. It's definitely eye-opening (compared to my
semi-modern 2010 laptop). So things which seem instantaneous natively
run much slower when emulated. (This is actually good and lets me
optimize my code and compare compilers.)
> So far, I can report that FED is a bit slow to start up (just when I
> thought it had hung, it came up) but runs fine after that.
Is it UPX'd? LZMA compression is horribly slow on legacy cpus, that's
why it's disabled for 16-bit .EXEs by default. (Yes, I know this is a
32-bit DJGPP build.) If so, try unpacking and repacking with "--best"
instead.
A while back I tried running Linux under the web browser in a
Javascript-based emulator. It had GNU Emacs on there. Emacs took at
least a minute to boot up, but at least the syntax highlighting looked
pretty!
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Four in a Row (was: one more proposal for upload via fdnpkg)
Hi, On Thu, Jun 6, 2024 at 6:06 AM Jerome Shidel via Freedos-devel wrote: > > Looking around on the ibiblio and my server: > > There is a version that has a timestamp from 2019 in the ibiblio mirrored > files > > Then later, Jim found it as well in 2019 and mirrored it to ibiblio. Actually, there was a mailing list discussion (years ago) and I myself mirrored it to iBiblio for us. > I don’t see a reason that would require it to be excluded. > So, I recommend including it with the release starting with T2407. > > :-) Okay with me. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] prog lang. year for watcom compiler/programming book list?
Hi, On Fri, Jun 7, 2024 at 5:14 PM Richard Stoltenberg via Freedos-devel wrote: > > Just some notes; updates. People might want to stick to the pdfs if they need > bigger font. > LibreOffice may be able to save as html. Got the C Language book from Lulu > on Monday 3rd June. I forgot that even Richard Stallman wrote a C book that he gives away for free: _GNU C Language Intro and Reference Manual_ * https://lists.gnu.org/archive/html/info-gnu/2022-09/msg5.html * https://git.savannah.nongnu.org/cgit/c-intro-and-ref.git/tree/ > I read new standards for Ansi C were updating (2018). > https://www.iso.org/standard/74528.html maybe just bug fixes. > Thanks now can try to fix code. * https://en.wikipedia.org/wiki/C23_(C_standard_revision) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] problems with moving in a long history
Hi, On Sun, Jun 2, 2024 at 7:33 AM perditionc--- via Freedos-devel wrote: > > DJGPP is where the cmdline env and extended command line processing is from I > think, that or 4DOS. > it's been a while, but it was based on and made to function like existing > implementations. I think it was a Win95 feature originally. (But yes DJGPP supports it.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] prog lang. year for watcom compiler/programming book list?
Hi, On Thu, May 23, 2024 at 2:02 AM Bernd Böckmann via Freedos-devel wrote: > > C in general and Open Watcom in particular are good choices for DOS > programming. > > The other free options supporting more recent C versions are GCC as part of > DJGPP targeting 32-bit DPMI, and, > despite being somewhat experimental, IA16-GCC, a port of GCC for the DOS > 16-bit real mode target. Most DOS compilers never supported C99. Although I can appreciate parts of C99, you don't really "need" it for DOS. * https://en.wikipedia.org/wiki/C99 > Not exactly with examples, but for documentation specific to Open Watcom I > recommend their PDFs and / or > the printed manuals. At least the Open Watcom C Language Reference (it is > basically ANSI C with some but > not all features of C99 and implementation specific addons) and the > programmers guide would be a good idea > to have a look at after aquiring some knowledge of the C language. The DOS reader is "whelp cguide", IIRC. Not PDF but readable in plain DOS without third-party tools. _C in a Nutshell (2nd)_ is also a good book and even covers C11: * https://www.amazon.com/Nutshell-Definitive-Reference-Peter-Prinz-dp-1491904755/dp/1491904755/ref=dp_ob_title_bk ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo
Hi, On Wed, May 22, 2024 at 11:17 AM tom ehlert via Freedos-devel wrote: > > am Mittwoch, 22. Mai 2024 um 13:14 schrieben Sie: > > it seems that no knowledgable person finds zoo interesting enough to fix it. > and those who care about zoo have no clue. > I regret that I have to say this. We had a discussion on BTTR a few months back with no obvious consensus: * https://www.bttr-software.de/forum/board_entry.php?id=21046 Do we want ZOO 2.10 (Cygwin sources) or 2.01 (public domain??) or Booz (unextract only, no subdirs) or Unzoo (new compression method only, subdir support)? If we need a Turbo C++ makefile, I can write one (since I did the same for NASM16 and NASMLITE back in 2019). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FETCH4FD
Hi, On Sat, Mar 23, 2024 at 2:14 PM Jim Hall via Freedos-devel wrote: > > And years ago, we used to include COMPINFO in a previous FreeDOS > distribution, but I don't remember why we stopped including it. If I had to > guess, probably it was the same question of "usefulness." I'd have to double check to be sure, but I believe it was old (limited) info and also had the TP7 Runtime 200 bug. ___ Freedos-devel mailing list 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
