OSDev.org

kerravon wrote:

alexfru wrote:

kerravon wrote:It took me an awfully long time to find out what the "huge" memory model in MSDOS actually was, and it didn't help that I got incorrect information in a public group (alt.os.development) with no correction from anyone.

What exactly was the confusion/incorrectness?

https://groups.google.com/g/alt.os.deve ... iXRm-aBQAJ

I think at the time you mentioned this, I did in fact look at the code generated by Turbo C's huge memory model when a "long" was added to a pointer, and confirmed (what I thought was) your observation that the compilers didn't generate the code I wanted.

But I think it was only after an argument in comp.lang.c where I was repeating the (believed) assertion from you that I think I had rudimentally confirmed, that I decided to check Watcom (which I think I had moved on to) to prove I was right. And I was wrong. So I apologized in comp.lang.c and wrote the above. Actually I think there was a gap before I eventually tried Watcom and I apologized belatedly.

And as per the above link, I said maybe we were talking cross-purposes, as there was no reply with clarification.

Just checked with Turbo C++ 1.01 that -mh isn't enough to make all pointer arithmetic 32-bit by default. The pointed-to type (in the pointer declaration) needs to be annotated as huge (e.g. char huge* p) for the compiler to generate a call to a 32-bit pointer add subroutine. Seems like this is different from Open Watcom's -mh. I don't think I ever compared the models in the two compilers.

alexfru wrote:Just checked with Turbo C++ 1.01 that -mh isn't enough to make all pointer arithmetic 32-bit by default. The pointed-to type (in the pointer declaration) needs to be annotated as huge (e.g. char huge* p) for the compiler to generate a call to a 32-bit pointer add subroutine. Seems like this is different from Open Watcom's -mh. I don't think I ever compared the models in the two compilers.

Ok, thanks for confirming that:

1. Turbo C's huge is different from Watcom C.

2. That at the time of that message you didn't know Watcom C was doing the exact thing that I needed.

kerravon wrote:

Octocontrabass wrote:

flossy wrote:16 color text mode only, as that's easiest to implement and make programs for.

What about hardware that isn't VGA-compatible?

Isn't it reasonable to send ANSI escape codes and let a higher level sort that out, possibly with a fallback of only displaying text with no colors?

Which is all blind and deafblind people ever get to "see" anyway.

flossy wrote:So, I've been working on an OS, and I've restarted several times due to not having a plan. I now have a plan, and some principals that I've laid out.

• The user has as much power as the OS. if the OS is capable of doing something, the user do it.
• Keep it as minimal as possible. E.g. C compiler/linker, Assembler, text editor.
• Programs use no dependencies other than the kernel itself. Make everything self contained enough to run on any system running the OS.

Other than that, I have a few other plans for the design.

• Users write their own programs and utilities for the large part, and any non-user made program can be rewritten, replaced, or modified and recompiled.
• 16 color text mode only, as that's easiest to implement and make programs for.

If any of y'all are interested in helping out, let me know

Alternatively, you can look at the implementation of this idea by me https://github.com/Alexey1994/BelOS/blo ... obal/api.c

Here is the api provided to the program by the kernel.

But I recently added graphics to run NES emulator from another developer.

iansjack wrote:Compilers, assemblers, and text editors already exist and can be ported to a new OS with little real effort. As for the OS described, it took Thompson about a month to write a more powerful OS than described here, complete with assembler and text editor.

Three decades seems a little long for such a simple system.

Thompson didn't write the compiler. He modified the BCPL interpreter to have a syntax he liked, he and his colleagues realized they wanted more than one type and compilation would be nice, then Dennis Ritchie wrote the C compiler. I don't know how this sequence of events relates with writing the initial, assembly-language version of Unix, but I'm pretty sure they started writing Unix in 1969 and weren't finished until some point in 1970.

@kerravon: I think your full C90 support makes your C standard library much more complex than the original C of 1970 or so. I'm sure it's much easier to make a simple C without worrying about compatibility. And there's the question of how much energy different devs have for coding after the other activities in their life. Someone who codes for a living might take 10 years to get their OS into a good state even when using gcc and glibc, (we used to quote that figure all the time,) but once, some guy holed up in a cabin in the woods with nothing but laptops for company produced a GUI OS in 5 months.

As for the compiler, I'm told recursive descent parsers are very easy to write. I wouldn't know. I'm going for Forth because many people have done exactly what @flossy would like to, but with Forth instead of C. It's supposed to be relatively easy to make a Forth compiler, but my brain keeps getting tripped up over the indirection in the one tutorial I've looked at -- JonesForth. I'm looking at hForth now; small, simple, designed for embedded work and public domain. Lots of Forths are public domain. Perhaps that's because it had a very different niche to C.

eekee wrote: As for the compiler, I'm told recursive descent parsers are very easy to write. I wouldn't know. I'm going for Forth because many people have done exactly what @flossy would like to, but with Forth instead of C. It's supposed to be relatively easy to make a Forth compiler, but my brain keeps getting tripped up over the indirection in the one tutorial I've looked at -- JonesForth. I'm looking at hForth now; small, simple, designed for embedded work and public domain. Lots of Forths are public domain. Perhaps that's because it had a very different niche to C.

The recursive descent parser is really easy to make, here are some examples of my code
https://github.com/Alexey1994/system-la ... ser.c#L713
and Lua
https://github.com/lua/lua/blob/master/lparser.c#L1845