Index
> MenuetOS > MicroWindows/NanoGuiGoto page 1, 2 Next |
| Author |
|
|
daneel 13 Jun 2004, 19:05
Can be MicroWindows/NanoGui port to Menuet (The binary is only 237 kb)?
Its compatible whit X apps... what do you think? 
Thanks for your time |
|||
13 Jun 2004, 19:05 |
|
|
f0dder 13 Jun 2004, 19:13
You might want to give an URL - I assume it's http://www.microwindows.org/
 . Also, source size is a lot more important wrt. porting than the binary size is.
Reading the page it seems that it's pretty portable - considering they're supporting a whole bunch of both 16 and 32bit platforms. So, if there's some C/C++ compiler that cross-compiles to Menuet, it should be pretty doable I guess? Haven't looked much at it, but the MOS executable format seems a bit simplistic - perhaps you should code PE loader or a PE->MOSexe convertor first |
|||
|
13 Jun 2004, 19:13 |
|
|
SamuelGaliza 14 Jun 2004, 12:02
I'm translating SolOS to Nasm & I will translate MenuetOS into Nasm too & then I will combine all OSes to build a new project.
I think that is a good idea. Can you help me? |
|||
|
14 Jun 2004, 12:02 |
|
|
bogdanontanu 14 Jun 2004, 12:52
sure
|
|||
|
14 Jun 2004, 12:52 |
|
|
SamuelGaliza 14 Jun 2004, 14:08
I started with system16.asm & bootloader.
It works. |
|||
|
14 Jun 2004, 14:08 |
|
|
f0dder 14 Jun 2004, 14:14
However, bogdan, does your SolOS gui support win32 and X APIs?
|
|||
|
14 Jun 2004, 14:14 |
|
|
bogdanontanu 14 Jun 2004, 15:01
dont know much about X API's
But win32api is pretty similar to SoloS GUI API's 
CreateWindow, Messages, Window Callback... well i do have a Drag Mouse message  but i guess a very simple API translator will work... |
|||
|
14 Jun 2004, 15:01 |
|
|
f0dder 14 Jun 2004, 15:24
Well, I think the whole idea of MicroWindows/NanoGui is that
1) it's highly portable 2) it's smallish 3) you get a subset of win32 (MicroWindows) and/or X (Nano-X) ...at source level, without going through any conversion stages etc. I could be wrong of course, as I didn't read the site _that_ thoroughly, and didn't download their stuff. Of course if you don't need win32 or X APIs, you can use whatever GUI/VM stuff you want, and SolOS might be smaller+faster or whatever . Might still be worth a look though, sounds like it's pretty comprehensive stuff. |
|||
|
14 Jun 2004, 15:24 |
|
|
daneel 14 Jun 2004, 17:07
If we can port MicroWindows/NanoGui, the rest will be more easy.For example: The GNU programs are a great help!
I have the C/C++ cross compilers, but they need an improve to compile complex apps. |
|||
|
14 Jun 2004, 17:07 |
|
|
daneel 14 Jun 2004, 17:19
Here are the information about NanoGui:
Quote:
From the website: www.microwindows.org |
|||
|
14 Jun 2004, 17:19 |
|
|
Gomer73 14 Jun 2004, 17:40
I think the tough thing is that it is in C, whereas menuetOS is ASM.
This(I am assuming) is one of the reasons why menuetOS was created-to have an asm OS. C is really inefficient. I ported over some IDE code from C and had to debug why mine wasn't working. To do the simpliest of instructions in asm takes several 10s of instructions in c(I am talking about machine code instructions). Compile time is another thing. To compile X-Windows for FreeBSD would take over 12hours on my computer. None of this is the case with assembler code. This makes it tough to port this GUI over, especially since it wasn't designed for asm, there are some things that might really be inefficient and need to be rewritten. Much easier like Bogdan said to use his stuff and port from there. |
|||
|
14 Jun 2004, 17:40 |
|
|
f0dder 14 Jun 2004, 18:28
Quote:
Usually it's the other way around - at least if you use the language for what it's designed for. Quote:
Have you written something of similar size & complexity in assembly? - it's also worth to note the XFree86 is *horrible*, and that the GCC compiler is extremely slow.
Quote:
It's written to be portable, so porting it shouldn't be too bad. Of course it's a problem if there's no decent C compiler on MeOS, and it's a problem if nobody wants to do a ELF or PE loader for it. Ineffiency doesn't have much to do with "not designed for/in asm", but it _is_ tied closely to the need for portability. The documentation indicates that the only "native" routines used would be pixel access, linedraw and blit. Everybody knows (or should know ) the putpixel-based algorithms will be extremely slow, no matter how optimized the function is. Contrast this with win32 GDI which has a lot of optimized functions (read up on the whole DDI and GDI stuff in NTDDK)... it might still provide reasonable performance though, and it's worth a try.
Quote:
Depends on what you want to do . If you want GDI or X primitives under "a range of OSes" without (m)any source changes, the microwindows stuff sounds good (still sounds, haven't tested it). The SolOS GUI is probably faster, but would require source changes.
Anyway, dunno if this is "the thing" to do for MeOS, and it seems like the project hasn't been updated for a while, and it might not be all that complete... but it's a good idea, imo. |
|||
|
14 Jun 2004, 18:28 |
|
|
nere_ikasrearentzat 14 Jun 2004, 18:31
2 great ideas.
NanoGUI has x and win32 compatibility.. SolOS is beautiful.. What feature is more important? there is a Quake port for MenuetOS... isn´t useful to have a GUI with Xfree and win32 compliance? |
|||
|
14 Jun 2004, 18:31 |
|
|
Gomer73 14 Jun 2004, 19:54
For f0dder
When I said C takes 10s of times more the instructions I was talking machine code. Yes obviously something in C writen as "i*=b" take up less source code space, however it takes up way more machine code space making it both bigger and slower. I have written equivalent programs in assembler and c. Usually takes less than a second or around a second to compile in assembler. Takes 10s of seconds to compile in C. Look at Bogdan's Hostile Encounter. I think he said it took a couple of seconds to compile. No way a c program of any size could compile in a couple of seconds. The NanoGui is portable, because it is written in C. By definition MenuetOS is not designed to be portable(it is written in assembler, it is efficient, but not portable). To port it from c to c is relatively easy. To port it from c to assembler is relatively tough. The portability you are talking about is c to c. The gui is a major part of an OS, if an OS desires to be ASM, I would assume that this crucial part would also be in ASM. Otherwise why not just use FreeBSD, it already has more drivers and has been more thoroughly tested. What value does MenuetOS add if the boot process is MenuetOS and then it just runs a whole bunch linux programs, would make more since to go pure linux. I think maybe looking at the NanoGui/whatever might be good to see what kind of gui's other OS's are implementing, this way you could implement it in your OS. But at the same time, simplicity might be what is aimed for, and why add a whole bunch of uneccesary functions. PS: I do think it is nice to have some emulation, I just think emulation should be done after the goals of the OS are accomplished. IE. sure it would be OK to run an old game like Doom or Quake for nostalgic reasons, but I can do that in dos, so I would much rather run a fast gui off of a floppy than have these huge libraries to run some dos progs which were converted to run in linux. The true type fonts are nice, but would prefer to have that support natively rather than through a C library. |
|||
|
14 Jun 2004, 19:54 |
|
|
Tomasz Grysztar 14 Jun 2004, 20:01
SamuelGaliza wrote: I'm translating SolOS to Nasm & I will translate MenuetOS into Nasm too & then I will combine all OSes to build a new project. Why have you chosen NASM? |
|||
|
14 Jun 2004, 20:01 |
|
|
f0dder 14 Jun 2004, 20:20
Don't want to turn this into a language war, but - it's not true that compilers always generate longer code. And often when they do, it's for performance reasons (small doesn't necessarily equal fast on IA-32, just consider the string instructions, loop, etc.) Besides, most compilers let you optimize for either speed or size. As for execution speed, modern compilers (vc2003, intel's C++ compiler) do pretty well these days. You can still beat them a lot of the time, but it requires some effort... or use of MMX/SSE/SSE2
Yup, assemblers should be faster per-line than C compilers, no matter what - otherwise you have a particularly retarded assembler. Not that it matters a lot, though - by proper use of modular coding, you keep small source files, and the compile will still be fast. Link isn't slow either (except when using link-time code generation, but you only do that for profile or release-to-people builds.) I can of course only speak for myself, but when I program, I tend to focus on only a few modules at a time. Even if I had a C compiler that could process 25 million lines in one second, I would still be doing modular programming. Quote:
Why would you "port" (actually, rewrite in assembly) that NanoGui stuff? You don't have to do that just to use it from assembly, it would be a silly thing to do - might as well write your own then, and optimize it. The advantage of _porting_ something is that you can quickly move it to the target platform... oh, and while it's true for most GPL crap, portable doesn't necessarily mean slow, you just have to do a bit of planning and thinking (and there's nothing that says you can't do assembly implementations of parts of the project for certain target platforms.) Quote:
Yeah, got a point there - but what stops you from writing a thin WIN32 or X API wrapping around the native OS GUI routines? Would mean you get applications for the OS faster, since people don't have to learn YET a set of APIs. Quote:
If Menuet really is oh-that-stable-and-fast , it could still make sense to run "some other OS" applications on it, if they run faster and the OS crashes less... no?
Anyway, it seems silly to convert existing stuff to asm, just because it's written in something else. It's really a waste of time... especially since a lot of people that do this kind of conversion do line-by-line conversions, often ending in ridiculous code. Rather, spend your time optimizing the hot-spots in the libraries, or focus on the menuet kernel. |
|||
|
14 Jun 2004, 20:20 |
|
|
daneel 14 Jun 2004, 22:27
I think it better sacrifice speed to win compatibility
However, what we lose trying? |
|||
|
14 Jun 2004, 22:27 |
|
|
f0dder 14 Jun 2004, 22:36
daneel, you might lose some of the original goals of Menuet... I don't think compatibility was one of the main designs, but speed was. Not saying you have to, though - even with NanoGUI, you could probably implement more things that just pixel+line+blit with optimized code...
I would certainly myself sacrifice speed for compatibility, security and stability, if need be. So if what I'm using feels fast&responsive on a mmx-200 (or at least athlon700, if it's something "heavy"), I don't need it to be The Fastest Thing Possible (TM) |
|||
|
14 Jun 2004, 22:36 |
|
|
nere_ikasrearentzat 14 Jun 2004, 23:29
Quote:
Its light. Has win32 and Xfree compatibility. Its a good idea for a distro, even, for the oficial MenuetOS ... mmm... its a great idea, more useful than a beatiful asm GUI. whatever. Both are great GUI`s, with different purposes. _________________ Sorry for my english... |
|||
|
14 Jun 2004, 23:29 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|