flat assembler
Message board for the users of flat assembler.

Index > MenuetOS > MicroWindows/NanoGui

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
daneel



Joined: 19 May 2004
Posts: 56
daneel
Can be MicroWindows/NanoGui port to Menuet (The binary is only 237 kb)?
Its compatible whit X apps... what do you think? Question

Thanks for your time
Post 13 Jun 2004, 19:05
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
You might want to give an URL - I assume it's http://www.microwindows.org/ Smile. 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 Smile
Post 13 Jun 2004, 19:13
View user's profile Send private message Visit poster's website Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
However i think porting SolOS GUI would be much easy Wink

It is also in ASM and so it needs no cross compiler (just some changes as i use TASM) and the size is much smaller and the looks much better ....
Post 14 Jun 2004, 07:03
View user's profile Send private message Visit poster's website Reply with quote
SamuelGaliza



Joined: 13 May 2004
Posts: 11
SamuelGaliza
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?
Post 14 Jun 2004, 12:02
View user's profile Send private message Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
sure
Post 14 Jun 2004, 12:52
View user's profile Send private message Visit poster's website Reply with quote
SamuelGaliza



Joined: 13 May 2004
Posts: 11
SamuelGaliza
I started with system16.asm & bootloader.
It works.
Post 14 Jun 2004, 14:08
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
However, bogdan, does your SolOS gui support win32 and X APIs? Smile
Post 14 Jun 2004, 14:14
View user's profile Send private message Visit poster's website Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
dont know much about X API's

But win32api is pretty similar to SoloS GUI API's Very Happy
CreateWindow, Messages, Window Callback... well i do have a Drag Mouse message Wink but i guess a very simple API translator will work...
Post 14 Jun 2004, 15:01
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Smile. Might still be worth a look though, sounds like it's pretty comprehensive stuff.
Post 14 Jun 2004, 15:24
View user's profile Send private message Visit poster's website Reply with quote
daneel



Joined: 19 May 2004
Posts: 56
daneel
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.
Post 14 Jun 2004, 17:07
View user's profile Send private message Reply with quote
daneel



Joined: 19 May 2004
Posts: 56
daneel
Here are the information about NanoGui:

Quote:

Welcome

Microwindows is an Open Source project aimed at bringing the features of modern graphical windowing environments to smaller devices and platforms. Microwindows allows applications to be built and tested on the Linux desktop, as well as cross-compiled for the target device. Microwindows' genesis was with the NanoGUI project, and has now been combined into a single distribution. The Win32/WinCE API implementation is known as Microwindows, and the Xlib-like API implementation is known as Nano-X. Please read the FAQ for more information. An extensive Architecture document is also available. Check out the Articles that have been written about Microwindows in the left sidebar. To get involved, please join the NanoGUI mailing list. There is a full mirror of the mailing list accessible here.
News
NXLIB v0.44 - Nano-X / Xlib Compatibility Library

June 1, 2003
The first public release of the NXLIB Project, a companion project to Microwindows that allows X11 binaries to run unmodified using the Microwindows Nano-X server, is available from the Microwindows web site:

ftp://microwindows.censoft.com/pub/microwindows/nxlib-0.44.tar.gz

This release has been tested heavily with FLTK v1.0.11, and FLTK v1.1.3. FLTK is built using the standard X11 headers and libX11.so shared library. The NXLIB replacement for libX11.so (named libX11.so.6) is then used to run all FLTK test programs successfully without source or binary modification. This is great news since we now can use a very full-featured small footprint widget set, as well as many already-built applications in the Microwindows environment.

Although a work in progress, NXLIB also is making progress running unmodified QT and GTK+ programs. NXLIB v0.44 has been tested with QT v2.3.1, and GTK+ 1.2.10, and many of the demonstration programs are currently running.

NXLIB works by emulating only the Xlib (libX11.so) library. Since FLTK's use of Xlib is much smaller than GTK+ or QT, more programs are currently running. There is still work to do with the Xrm resource manager routines, and of course the idea is to keep the footprint small.

NXLIB requires Microwindows v0.90, just released.

The Microwindows mailing list, at microwindows.org will be used for questions, suggestions and patches to NXLIB. NXLIB is licensed under a the MPL license, with a conversion capability to GPL, the same as Microwindows.

Have fun! - Greg
Version 0.90 release, many font enhancements, standard calibration

May 31, 2003
Microwindows version 0.90 is released, and available on the website:

ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.90.tar.gz
ftp://microwindows.censoft.com/pub/microwindows/microwindows-fonts-0.90.tar.gz

There have been many additions, enhancements and bugfixes since the November 0.89 release. Following are some of the major highlights:

o Support for the new NXLIB project, which allows X11 binaries to run unmodified on Microwindows, without requiring the X11 server.

o Support for Sharp Zaurus, Tuxscreen, TriMedia, and Cygnus X11 platforms.

o Standardized calibration (nxcal) support now built into Microwindows. A single touchscreen driver supporting popular ARM platforms including iPAQ, Zaurus, ADS and Tuxscreen is also available.

o Many font enhancements, including support for FreeType 2, as well as a new BDF font converter that will allow any BDF font, including large Asian fonts, to be used. In addition, a new .fnt native binary font format is supported. DBCS multibyte decoding is supported for Japanese, Chinese, and Korean encodings (BIG5, GB2312, EUCCN, EUCKR, EUCJP, JISX0213)

o Major speed improvements to the X11 screen driver as well as text drawing.

o Per-color alpha support with a new 32bit ARGB hardware driver is included.

o LIRC keyboard with HAVI keyboard mappings.

o Doxygen-based automated documentation generated from source code for html and pdf docs.

o And lots more!

New APIs
GrGrabKey, GrUngrabKey
GrCreateFontFromBuffer, GrCopyFont
GrSetTransform, GrCalcTransform, GrSaveTransform
GrSetForegroundPixelVal, GrSetBackgroundPixelVal


From the website: www.microwindows.org
Post 14 Jun 2004, 17:19
View user's profile Send private message Reply with quote
Gomer73



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



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

To do the simpliest of instructions in asm takes several 10s of instructions in c

Usually it's the other way around - at least if you use the language for what it's designed for.

Quote:

To compile X-Windows for FreeBSD would take over 12hours on my computer. None of this is the case with assembler code.

Have you written something of similar size & complexity in assembly? Wink - it's also worth to note the XFree86 is *horrible*, and that the GCC compiler is extremely slow.

Quote:

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.

It's written to be portable, so porting Smile 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 Wink) 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:

Much easier like Bogdan said to use his stuff and port from there.

Depends on what you want to do Smile. 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.
Post 14 Jun 2004, 18:28
View user's profile Send private message Visit poster's website Reply with quote
nere_ikasrearentzat



Joined: 14 Jun 2004
Posts: 3
Location: Chile
nere_ikasrearentzat
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?
Post 14 Jun 2004, 18:31
View user's profile Send private message Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
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.
Post 14 Jun 2004, 19:54
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7721
Location: Kraków, Poland
Tomasz Grysztar
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?
Post 14 Jun 2004, 20:01
View user's profile Send private message Visit poster's website Reply with quote
f0dder



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

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:

To port it from c to assembler is relatively tough.

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:

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.

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:

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.

If Menuet really is oh-that-stable-and-fast Smile, 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.
Post 14 Jun 2004, 20:20
View user's profile Send private message Visit poster's website Reply with quote
daneel



Joined: 19 May 2004
Posts: 56
daneel
I think it better sacrifice speed to win compatibility
However, what we lose trying?
Post 14 Jun 2004, 22:27
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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) Smile
Post 14 Jun 2004, 22:36
View user's profile Send private message Visit poster's website Reply with quote
nere_ikasrearentzat



Joined: 14 Jun 2004
Posts: 3
Location: Chile
nere_ikasrearentzat
Quote:

On 16 bit systems, the entire system, including screen, mouse and keyboard drivers runs in less than 64k. On 32-bit systems, support includes proportional fonts and applications are typically less than 100k.
http://nanogui.org/faq.html

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...
Post 14 Jun 2004, 23:29
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

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