flat assembler
Message board for the users of flat assembler.

Index > MenuetOS > MicroWindows/NanoGui

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
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?
Post 14 Jun 2004, 23:30
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Wink. 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 Smile

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

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 Smile

*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 Wink
Post 15 Jun 2004, 00:04
View user's profile Send private message Visit poster's website Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
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.
Post 15 Jun 2004, 00:39
View user's profile Send private message Reply with quote
nere_ikasrearentzat



Joined: 14 Jun 2004
Posts: 3
Location: Chile
nere_ikasrearentzat
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?

Wink

_________________
Sorry for my english...
Post 15 Jun 2004, 02:06
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Well, Gomer, the website _does_ say the only primitives the code relies on are pixel,line,blit - hard to get good performance with that Smile. 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? Smile (I had a short look at it, and it seemed somewhat messy, like having some 3D routines etc.)
Post 15 Jun 2004, 02:26
View user's profile Send private message Visit poster's website Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
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.
Post 15 Jun 2004, 02:46
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The source is probably there... somewhere... in their distribution Smile

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 Smile (although probably still rather slow.)
Post 15 Jun 2004, 03:02
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Post 15 Jun 2004, 03:06
View user's profile Send private message Visit poster's website Reply with quote
SamuelGaliza



Joined: 13 May 2004
Posts: 11
SamuelGaliza
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 Smile
Post 15 Jun 2004, 07:28
View user's profile Send private message Reply with quote
daneel



Joined: 19 May 2004
Posts: 56
daneel
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."
Post 15 Jun 2004, 18:00
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
crc - 13 Jun wrote:
FASM now works perfectly under BeOS! See See http://board.flatassembler.net/topic.php?p=10763#10763 for the download (source + binary)


SamuelGaliza - 15 Jun wrote:
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 Smile


Question Confused Question
Post 15 Jun 2004, 21:00
View user's profile Send private message Yahoo Messenger Reply with quote
SamuelGaliza



Joined: 13 May 2004
Posts: 11
SamuelGaliza
OK, then i will translate SolOS to Fasm Smile
Post 16 Jun 2004, 07:51
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.