Hi Rugxulo. >> 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. > 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). I see. Quite frankly I haven't really delved into this, but maybe now is a good time to start. I was going to attempt to abstract the problem. Switching to domain-specific. E.g. a function to read x seconds of an MP4 file and to open a new MP4 file are not covered by C90 either - but in this case, they could be written in C90 as you are dealing with flat files. Whereas making a subdirectory requires OS support. In both cases we want an API to deal with either an MP4 file or a FAT32 (etc) file system. I think the end user of the functions wouldn't know, or necessarily care, which of those sets of APIs involve OS-specific calls. Until it's time to port the application. If the API for the FAT32 file system has perhaps been used to set the "hidden" attribute of a file, then I assume that this is unrelated to Posix, which instead has capability to set the "group" ID of a file or whatever it is called. Ok, so assuming a suitable API exists to set the hidden attribute etc, which ties an application down to the FAT file system - or at best, some file system that is sufficiently compatible with FAT, embracing the concept of making a file hidden, then this would fall into the category of a non-portable application, and potentially "more useful". Although you could actually implement a FAT-32 file system on top of a C90 flat file. So even that ends up being portable. And maybe that's what needs to be done for these applications that manipulate a filesystem. Provide a way for the user to specify the file system they are trying to manipulate. Maybe by default it just does a "passthrough" and hopes that the underlying file system is FAT32, but if not, it accepts a flat file that represents that. Then it will work on a mainframe too, which normally uses a file system that doesn't have the concept of creating a directory. That wouldn't solve the problem of an application, perhaps DVD writing, that requires the ability to sleep for 5 milliseconds. But I had a similar problem with keyboard input - what happens if the user hits a real ESC? How long do you wait for, and what function do you call to do a sleep anyway (not covered by C90)? Turns out that the ANSI X3.64 people already solved that by sending 2 ESC for a real ESC being pressed, at least as a (rarely used) option. I embraced that rarely used option with delight - it looked fantastic! Maybe there is a similar thing with DVD writing - it is fundamentally incorrectly designed if it relies on particular timing? Then again, when dealing with humans, you need to send 50 screens per second or whatever it is, so maybe some hardware needs to inherently not accept a new screen until the old one has been displayed for the required number of milliseconds. I guess - design systems around C90 rather than the other way around, and bitching about C90 and resorting to extensions. Just speculation. > Check out David Given's attempt at CPMish on Github: > https://github.com/davidgiven/cpmish I checked, thanks. >> 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.) How is PDOS/86 supposed to implement that? Currently it calls a BIOS function, which I suspect doesn't work (haven't started debugging that still). > 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. > ke20xx_32.zip : binaries for 8086, FAT16, FAT32 I got this, and then renamed my kernel.sys to kernel.old, then copied this new kernel.sys onto the disk, and then started it under an emulator and it worked fine (as before). I have no way of knowing whether it was actually using the new kernel.sys. The act of renaming kernel.sys to kernel.old would have left it as the first file on the disk. I was under the impression that the boot sector of Freedos would allow the kernel.sys to reside as something other than the first file, so I expected this to be a valid test and to skip the kernel.old and use the new kernel.sys. Please let me know if this is an invalid test. 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. > 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. Then I need Microsoft C 5.1 (which I already have and already tested under DOS 6.22 on the Book 8088) or 6.0 (ordered but not yet delivered). My main interest is developing PDOS/86 using Freedos (or MSDOS 6.22) on the Book 8088. I want to prove it can be done. >> MSDOS 6.22 is sitting there ready to go. > For testing, okay, but you can't redistribute it. I'm not really trying to distribute either MSDOS or Freedos - I distribute PDOS/86. I do have my own Freedos distribution, but that's for another purpose (adding HX to create Win32). > I see no reason not to use FreeDOS. If something doesn't > work, keep bugging us here. Sure, thanks. Possibly the Book 8088 BIOS is deficient and Freedos is relying on that (while MSDOS 6.22 is not). But yeah - if Freedos is 8086 out of the box, that's fantastic and I have no reason to use MSDOS 6.22 except for testing purposes (same as testing on Win95 but normally I would use Freedos + doslfn + HX). BFN. Paul.
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
