I can only speak for my OS, but I think MenuetOS has similar goals.

For me speed is an issue, but not the major issue. Efficiency is. To establish standards in an OS is of prime importance as far as I'm concerned.

OK, say we use the nanoGui thing. At the same time Ville is implementing his own gui routines. At the same time somebody thinks we should be using the GTK. Everybody will have their preference and the same thing that happened to linux will happen to MenuetOS. In order to run 3 small 5k programs that use different gui interfaces, you will need to load 3megs worth of libraries(just guessing now) which is probably 2 to 3 times the size of the current MenuetOS.

The thing is, it won't stop at the gui, then everybody will want 20,000 different languages to program in, and each program will require a different language to be loaded. Then this library needs to be of a certain version for this program to run, but of a different version for that program to run. This is one of the issues with linux. Linux is the ultimate in compatibility, I wouldn't want to try running anything on it though.

Windows really doesn't have this problem because everything useful is already built into the OS. People have made the freeware GTK thing, but who would want to use that if you can use the native windows code. The is because the supplied OS stuff is already good enough that you don't need external libraries and hence you have one standard.

Like I say, the gui is pretty core and I think it should be written in accord with the principles of the os, asm and built into the kernel/core system files(however you want to put it).

Even at this point I don't know if Ville's MenuetOS will survive. The core system is not really developed yet. There aren't too many gui controls. There isn't a set way of accessing libraries(function calls), to my knowledge anyways. And hardware drivers are pretty minimal. Yet even at this point we are getting multiple distributions. Probably each will have it's own gui preference, each will have it's own file system. Because these things have not been developed yet the same thing will probably happen to MenuetOS that happened to linux. Multiple flavors all kind of compatible, but not really. And huge library file installs. Probably the Russian distribution will win out because they have a team of programmers(hard to compete against a team). Ville's work will probably continue to contribute a lot of the new drivers. The EZ distribution will just hack and combine both distributions.

The C port is definitely the quick and easy route. I don't know if I would say it is the best route at this time though. I think the OS needs to be developed a little more first.

I appreciate this discussion though, it kind of shows me what I should do before releasing my OS into the public. I kind of want to prevent the same thing from happening. Which is ironic, because without releasing MenuetOS out to the public would it be as developed as it currently is?

Yes, there's a lot of dilemmas with regards to OS development. I don't think OpenSourcing it is a bad idea, and OSes are actually one of the very few areas where I can accept the GPL license (not that I'm not against OpenSource in general, just GPL). But then you face The Linux Problem (TM) - everybody doing things slightly their own way (and then of course there's the issue of linux building on outdated 70s technology and ideas, but that's another matter . I like the way the BSD dudes are handling it - there's NetBSD, OpenBSD and FreeBSD, which seem pretty tightly controlled, and with three different goals. And the smaller BSD distros aren't really worth mentioning

It's been years since I've worked on my kernel, but I plan on toying a bit with it during summer break (starting by implementing a better debugger frontend for BOCHS, if I can figure out how to do it). And I know that I will certainly focus on other things before writing a GUI! - memory management, process/thread management, etc... although I probably _will_ write some framebuffer code and a VESA driver relatively early (it's an okay testbed for v86 routines anyway ).

I'm not really expecting to use my kernel for anything though, it's purely for fun, to learn a bit, and refresh x86 systems programming knowledge. Or well, it could be useful to do precise code timing and such, with decent PMC support etc., but... we'll see

*if* I ever get a substantial amount of work done, I surely won't think up my own GUI API though - I'll probably use NanoGUI. I plan to have my own Native API for other stuff though... and perhaps implement wrappers for enough win32 stuff that I can run some console apps (first steps would be hiew32, fasm and nasm, then perhaps even microsoft C++).

But dunno how much I'll ever get done - I need to do some schoolwork in the summer break, plus a lot of boozing

The boozing is important.

Dang, I checked out the MicroWindows stuff.
I downloaded the DOS version since I thought that would be the closest to approximate what menuetos would look like.

Man was that crappy is all I can say. Kind of reminds me of windows 3.1 on a really old computer. You can see it redrawing everything and tons of flicker.

Compare that to the SolOS gui, and I think the decision is easy.

All the best to you on your os programming and boozing during summer break.

crappy or not, has compatibility with X and win32 apps, and this is a wiser idea than to implement a beautiful asm GUI (note: i respect Ogdan Bontanu´s work, but this is not a subject of beauty, im talking about pragmaticism)

Well, Menuet has a C lib, no?

Well, Gomer, the website _does_ say the only primitives the code relies on are pixel,line,blit - hard to get good performance with that . Dunno how much work it would be to optimize some other primitives... btw, was the dos stuff 32 or 16bit? Which resolution and color depth?

nere: sounds like some work would have to be done on MicroWindows, though, before it's all that useful? (I had a short look at it, and it seemed somewhat messy, like having some 3D routines etc.)

I would assume 16bit.
Don't know what color depth or resolution, possibly 800x600. The text was kind of messed up as well on some of the demos.

They didn't provide source code, just executeables.

The source is probably there... somewhere... in their distribution

16bit is probably a safe assumption, DOS and all. 800x600... that could be a standard VGA (SVGA?) mode - 4bpp/16color. A very ugly bitplaned mode which will have _awful_ performance if you need to address individual pixels (although they can be relatively fast if you need to do large single-color fills).

So, if it's 16bit code and 800x600x4bpp, there's a good chance that the code would do much better in a "sane" environment (although probably still rather slow.)

I think it might be interesting porting the stuff over to win32/DirectDraw - that should allow for some pretty realistic measure of how well (or bad) the stuff can be expected to perform.

My last exam's tomorrow (well, today... after I sleep some. five o clock here, exam's at ten, and I still have some 13 pages of reading to do, heh). This will be followed by a drinking spree, but there should be a break after the weekend, and I might have a look at it there.

To Privalov:
I have chosen NASM because there isn´t FASM for BeOS.
If somebody will compile FASM to BeOS I will translate SolOS to FASM even if someone have any other idea

I recompile the source in Linux.Its works realy good. I copy the ways to compile (README.txt) , if you do a port of MW, you will need it.

"Microwindows compiles and runs on Linux, UNIX, ELKS, MSDOS,
RTEMS, X11 and bare hardware. There is support for the MIPS,
ARM, and x86 cpu's using the GNU C cross compiler.

The architecture of Microwindows allows it to be ported
or run on a wide variety of systems. Cross-compilation
for MIPS, ARM and x86 processors is supported. There are currently
screen drivers for Linux 2.2.x framebuffers and Linux 2.0.x
svgalib, as well as an X11 driver that allows applications
to be built and tested under X11 before running on the
target platform. There exists a portable 4-planes VGA driver
that will run on bare hardware, ELKS, MSDOS, or RTEMS.
There are mouse drivers written for bare hardware, direct
serial port, Linux GPM driver, and touchpads. The Microwindows
graphics engine is capable of running on any system that
support readpixel, writepixel, drawhline and drawvline,
although more advanced bit blit routines are provided.

Microwindows features full RGB color support, optimized
palette bitmap drawing, and a 3d look-and-feel.
Overlapped and child windows are supported, with complete
window and client area clipping. Proportional and fixed
fonts are supported, along with utilities for converting
any MS Windows font or .bmp file. Optimized painting
algorithms are used to allow maximum response while the
user is moving windows on the screen.

In addition, the Nano-X server can also be built on top of
the device-independent graphics engine."

OK, then i will translate SolOS to Fasm