OSDev.org

As for the license problem, that's probably solved by basing on FreeDOS instead (and respecting their license, of course!)


http://git.tyndur.org/?p=tyndur.git;a=summary

kthxbye


The problem is just that what was production quality in 1990, isn't necessarily appropriate any more in 2015. For example, if you're doing anything with networks (who isn't?), and that on relatively recent hardware, DOS is probably not the right answer.

So my expectation is that for many tasks, I'd rather go with an imperfect 2015 hobby OS than with a production quality DOS. Yes, tyndur sucks. But DOS sucks harder in some cases.

Please explain what specifically about the open, close, read, write, rename and delete DOS functions is policy.

It may be hard to draw a line between mechanism and policy. If you have a method for accessing disk sectors, it could be considered as a mechanism. Having those relatively high-level functions is more than than.

• File system. A policy in itself, like file attributes, file name format, date stamps. etc.
• State. How many open files? Read/write pointers? Caches? etc.
• Error handling. How many times you retry if there is a read/write error? etc.
• Fragmentation. How do you handle file fragmentation? Pick up always a first free cluster? etc.
• Extra features. Long-name support? etc.

Please also note that I am probably only one here who admitted that your idea was not totally pointless (see my previous post). Still, it should be noted that you would build your work on some other operating system. Of course, it is possible to use it as an intermediate step, like a boot loader for the real operating system?

Simple systems expose the mechanism in their policy, but the implementation of a file system specification is not policy.All implementation mechanism of an ubiquitous file system, no matter how it is implemented internally it is still a driver.There is actually no LFN support in the io.sys (the last "real" DOS) that came with Windows98, but doslfn.com or similar
can take care of that (with mouse.com providing USB mouse support). I would say that the best extra feature would be indirection.

The user "indirection" experience policy is very similar in DOS and Linux and is implemented in command.com/bash. These two
system's mechanisms and UI implementation policies are different from each other, and the functions which are used to implement
the policy are not the policy itself.Thanks for the support. However, I think you got the wrong point.My point is that for a simple system (standalone utility, game, hobby OS) that is typically using the BIOS function drivers it could just
as easily use the "DOS BIOS", which includes the input/output and basic file functions, without being considered a
DOS application/appliance/operating system. The DOS functions for loading/executing programs and memory allocation etc. are the
actual DOS operating system kernel. It's this OS functionality that would be implemented in the OS and not the DOS kernel functions
being used. The ones being used are only drivers and BIOS wrappers.

I'm not distributing any MS executables nor am I distributing any MS source code (original, modified or derived). The moral/legal issues
of an individual using (for their own personal/private/non commercial use) a bootable USB DOS flash drive are pointless - who cares -
certainly not Microsoft. Some people actually use DOS as their development environment, others use DPMI, others use an MZ
executable/loader for their kernel, etc.

The consensus here, (majority or otherwise) that BIOS based systems are pointless - is pointless since the subject is when DOD is not DOS.

The choice of a file system specification is policy. The moment you choose DOS, you choose FAT, and you choose not to have users, groups, (sym)links and more of their ilk.

Hi,



Except that IO.SYS provides nothing useful (at least not useful enough to justify the additional dependency), so even for a real mode thing it'd be better to ignore IO.SYS and use the BIOS functions directly (until you replace the BIOS disk and keyboard drivers with your own real mode drivers that don't suck as badly, then realise you gained nothing from limiting your toy to real mode because you're no longer using the deprecated BIOS anymore).



I took a brief look at FreeDOS source code, and as far as I can tell they don't have any IO.SYS and just have a "kernel" that does everything.


Cheers,

Brendan

Agreed. I should have made that statement more specific (along the lines of my presentation) "that the mechanism used to implement
the file system specification is not policy".Exactly, DOS means FAT but FAT doesn't necessarily mean DOS (Linux and other systems implement FAT).But that policy could be implemented using the basic DOS file functions.

"BIOS is BAD" is your agenda not mine.The io.sys of Windows98 is the kernel that does everthing. Never the less, the "DOS BIOS" is modular in the sense that it is installed interrupt handlers all of which could be made a derived work of the original to provide a
similar io.sys file.

Just like in MS-DOS 7.x, which Mike used in the first post in this thread. I think his intention wasn't to leave out what used to be in msdos.sys, but rather to use the whole DOS kernel and replace only the shell (which he curiously seems to achieve in a more complicated way than just setting SHELL=... in config.sys). The parts that he doesn't want to use, he would still have loaded, but never call them. That should be possible with FreeDOS - though I haven't looked at its code yet, so you're in a better position to tell.


If you have the whole DOS kernel, this looks a bit different. Having a file system, memory management etc. does help. It's precisely the difference between application and operating system development.

Actually, I only want to use the "DOS BIOS" and the DOS file system functions. I'm not replacing the shell, but rather having io.sys load my standalone utility, game, hobby OS.Nothing complicated about creating a MZ executable named command.com and having the first asm instruction being jp.Exactly, it's the hobby OS that would be providing the buggy, home brewed, amateur, half baked - loading programs, memory
management etc. It would only be using the "DOS BIOS" and DOS file system functions as drivers. Of course the BIOS functions
themselves would still be available but the DOS API is slightly different and it would simplify user documentation if the
duplicate BIOS functions weren't included.

I think I acknowledged that you want to use only part of the DOS kernel, even though you would load all of it.


Yes, instead of loading command.com. That's replacing the shell. (And of course, "standalone" is debatable. It's a DOS utility, game, OS extension.)


Indeed, not really complicated. But just updating the configuration file, where changing the shell is a supported thing, would be even less complicated.


Though that's just the split you like for your own project. It would be similarly reasonable to use the DOS memory and task management and replace the file system.

Also, are you sure that the FAT driver (or any other code you keep using) doesn't do any memory allocations? Using the DOS allocator and your own one in parallel isn't going to work out well.

This discussion here sounds like DOS file system functions are so negligible and trivial that they are not even copyrightable. If we think about real mode operating systems, they are very significant and applications use the disk operating system mainly for operating the disk. On the contrary, loading programs is seen as a relatively complicated "OS" operation. Although one half of it is using file system functions.

Please note that this applies only on real mode operating systems that will be very limited anyway.

If you mean me: First of all, I wouldn't even start bothering with RM, because that's just a bit out of place in 2015. But if I were, I would either use the complete DOS kernel or none of it. Probably all of it, because chances are that I would want to achieve some specific goal rather than just doing some random OS-Dev for fun (if I just wanted to do the latter, I'd probaby write everything by myself), and everything that I can reuse helps doing that. It wouldn't be too unlikely that my DOS application actually would mostly run in PM, though.

The only real "use case" for Mike's suggestion of picking parts from the DOS kernel is proving that it's possible. Otherwise you either want as much as you can get (i.e. be a DOS application) or nothing (i.e. be your own OS).

My operating system is not under active development because it's at most a stack of design papers and at least a stack of papers with strange ideas on them.

That's the fun of designing something entirely new. You can spend as much time as you like thinking about how to put it all together and can use the "oh, it's in the design stage" excuse when someone says "well I don't see you releasing anything". I'm not writing a unix because there are many better, working unices out there. I'm designing something new so I don't dive into a pool of loosely connected ideas getting frustrated trying to reconcile them with one another.