OSDev.org

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

mikegonta wrote:

Kazinsal wrote: But as a real project? It'd be more worth your time to write a real operating system

Show us yours and we'll talk.

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

kthxbye

Antti wrote:In the hobby OSDev scene, there seems to be very few "production quality" operating systems available. All the common IO.SYS implementations are production quality although someone could probably list a truckload of flaws. If you built your OS based on that, assuming that your code is high quality too, you could have an operating system that can be valid in production use.

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.

Antti wrote:

mikegonta wrote:The DOS file system functions (while part of the DOS kernel) of and by themselves can not be considered a DOS Operating System.

Technically it might be possible to turn this into a valid statement but you will have difficulties in convincing people. Those file
system functions are not just providing mechanism but significant policy is involved. And that policy is very DOS.

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

mikegonta wrote: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?

Antti wrote:

mikegonta wrote: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 (that).

Simple systems expose the mechanism in their policy, but the implementation of a file system specification is not policy.

Antti wrote:

• 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.

All implementation mechanism of an ubiquitous file system, no matter how it is implemented internally it is still a driver.

Antti wrote:

• Extra features. Long-name support? etc.

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.

Antti wrote:Please also note that I am probably only one here who admitted that your idea was not totally pointless (see my previous post).

Thanks for the support. However, I think you got the wrong point.

Antti wrote: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?

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 implementation of a file system specification is not policy.

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,

mikegonta wrote: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.

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).

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

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

Combuster wrote:

the implementation of a file system specification is not policy.

The choice of a file system specification is policy.

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".

Combuster wrote:The moment you choose DOS, you choose FAT, ...

Exactly, DOS means FAT but FAT doesn't necessarily mean DOS (Linux and other systems implement FAT).

Combuster wrote:... and you choose not to have users, groups, (sym)links and more of their ilk.

But that policy could be implemented using the basic DOS file functions.

Brendan wrote:

mikegonta wrote: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.

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).

"BIOS is BAD" is your agenda not mine.

Brendan wrote:

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

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

The io.sys of Windows98 is the kernel that does everthing. Never the less, the "DOS BIOS"

mikegonta wrote: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.

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.

Brendan wrote: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.

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.

Brendan wrote: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).

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.

Kevin wrote:

Brendan wrote: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.

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 ...

Actually, I only want to use the "DOS BIOS" and the DOS file system functions.

Kevin wrote:... and replace only the shell ...

I'm not replacing the shell, but rather having io.sys load my standalone utility, game, hobby OS.

Kevin wrote:... (which he curiously seems to achieve in a more complicated way than just setting SHELL=... in config.sys).

Nothing complicated about creating a MZ executable named command.com and having the first asm instruction being jp.

Kevin wrote:

Brendan wrote: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).

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.

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.

mikegonta wrote:Actually, I only want to use the "DOS BIOS" and the DOS file system functions.

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

Kevin wrote:... and replace only the shell ...

I'm not replacing the shell, but rather having io.sys load my standalone utility, game, hobby OS.

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.)

Kevin wrote:... (which he curiously seems to achieve in a more complicated way than just setting SHELL=... in config.sys).

Nothing complicated about creating a MZ executable named command.com and having the first asm instruction being jp.

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

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.

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).

mikegonta wrote:

Antti wrote:

mikegonta wrote:Show us yours and we'll talk.

A little bit rude comment.

And I apologize for that, but it was meant to be tongue in cheek (I'm not a big user of the funny face). It's sort of like when someone
makes an informal (not requested) business proposal and the response is "OK, we'll talk" (a sort of brush off), or "my people will contact
your people". I should have said "Show us yours and we'll have lunch"

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.