flat assembler
Message board for the users of flat assembler.

flat assembler > MenuetOS > Progress

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
Is Menuet still ticking? I only see two posts in the last month and a bit, and they're both support requests. Was kind of hoping there was more interest in the project. It *is* really cool that such a tiny little OS in assembler got as far as the windows 95 stage (and even on x86-64)

I've been thinking:

I'm moving my copy to be a "guest OS/appliance libOS" for virtual machines. To that end, the host already provides excellent isolation between programs and heavyweight multiplexing, along with capabilities. Each guest therefore ought to run ring 0, lightweight multi-threading, and event-based. (I think Singularity OS, but without Microsoft)

I've been doing:

1) Removing obsolete API calls (done)

2) Porting to use booted disk, whatever that may be (done, except CD's)

3) Porting all the event-strobe model code to the event model (mostly done)

4) Expanding executable specs to declare memory/cpu/network initial and maximum states (finalized, not implemented)

5) Causing all applications to run in ring 0 (weird bug atm)

6) Setting up each application to have a table of event handler pointers that drivers can leverage. The idea is to have the drivers allocate a stack and schedule the stack for asynchronous execution (on the application's time) Arguments can be passed via the allocated stack. This is like an uber-lightweight thread/continuation. (finalized, not at all implemented)

I realize I certainly couldn't release such a derived creation to the general public without consent. To be honest, I feel no pressing need to release it. There are opportunities with our immediate clients that would save them 10m here, 40m there. Just need to get apps for such a thing that take 1/10th the processor and memory requirements of dedicated windows servers.

I already know the feeling towards open source contributions, but was curious what the reaction would be to closed source ones.

Best Regards,
Daniel

_________________
dd 0x90909090 ; problem solved.
Post 28 Mar 2008, 07:48
View user's profile Send private message Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
Spent my code time this month working on my scripting engine, so no progress. Been thinking to study up Virtual Iron, see if there are exposed interfaces to make life easier - like being able to start in pmode or lmode.

Well practiced and studied laziness outdoes blind hard work most days.

_________________
dd 0x90909090 ; problem solved.
Post 01 May 2008, 06:45
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2145
Location: Estonia
Well, sad to see your posts unanswered, but I see no solution from my end. Try to mail Ville directly and ask him in e-mail or post this thread. In his busyness he might not stumble here very often. Now that he also has Menuet's own board.

I feel that you are talking about 32-bit version, because 64 isn't open-source. So the points you gave actually mean, you've been improving or modifying 32-bit MenuetOS?
Post 03 May 2008, 18:56
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
The website provides the algorithm in a format designed to be executed by the x86 platform, rather than read by a human. Fortunately, tools have existed for the past 20 years to translate from one to the other.

It's unfortunate that we need to do extra work because some people are uncomfortable with that.

Anyways, I had offered to provide some patches behind closed doors and received no response so I'll assume they're also unwanted. Judging by the low activity around here, these forums are essentially dead. My recommendation is to check out http://www.kolibrios.org, which is an open source fork, but if you're stuck on Menuet for some reason...

http://menuet.2.forumer.com/

_________________
dd 0x90909090 ; problem solved.
Post 07 May 2008, 00:16
View user's profile Send private message Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 215
Couple of notes..

> 1) Removing obsolete API calls (done)

System calls are build upon programming needs. It's likely that all of the system calls are used by some application.

> 5) Causing all applications to run in ring 0 (weird bug atm)

If new features are added, ring-3 protection needs to be preserved.

> The website provides the algorithm in a format designed to be executed
> by the x86 platform, rather than read by a human. Fortunately, tools
> have existed for the past 20 years to translate from one to the other.
> It's unfortunate that we need to do extra work because some people
> are uncomfortable with that.

Programming language is a personal choice. Both Fasm and Menuet32/64 are for assembly programming.

Regards,
Ville
Post 08 May 2008, 12:09
View user's profile Send private message Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
1, 5) Graphics and HID driving should theoretically be a separate programming effort. Putpixel, etc, was separated out into a different bundle of code and I'm thinking to assign them different interrupts. Something like:

0x40 for OS
0x41? for graphics?
0x42? for keyboard and mouse?

Would seem sensible, but I can't remember what interrupt addresses are taken.

~~

The security model I'm thinking of is to use Pacifica/VT/Virtual Machine to multiplex securely; and to use my algorithm (the modified Menuet) to act as the application with seemingly raw hardware access to an arbitrarily consistent hardware platform.

~~

Quote:
The website provides the algorithm in a format designed to be executed by the x86 platform, rather than read by a human. Fortunately, tools have existed for the past 20 years to translate from one to the other.


Quote:
Programming language is a personal choice. Both Fasm and Menuet32/64 are for assembly programming.


Yup. I've no problems with the assembler language. Translated plain, what I said was that the menuet website provides the program in binary form, not assembly. Fortunately there are disassemblers to translate from the one to the other. I am still working off 0.78 however, since that debacle earlier.

I do wish I could use 0.84, but I'm restricted from translating it to assembler, and I refuse to read the machine code directly, even just to understand the USB improvements.

The arbitrarily consistent hardware I want these appliances to have available is x86-64, DMA, USB 3.0, AC 97, USB 3.0 disk space and Eth 10/100/1000. I realize USB 3.0 isn't even fully spec'd yet, but I'd imagine it's not terribly far from USB 2.0 so that's probably a good place to plan from.

Regards,
Daniel

_________________
dd 0x90909090 ; problem solved.
Post 09 May 2008, 06:57
View user's profile Send private message Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 215
Currently only interrupt 0x40 is available from ring-3 application. Calling other interrupts will generate a general protection fault and will terminate the application. Menuet32 uses single interrupt for system calls since it's easy to implement and doesn't duplicate programming efforts. A single interrupt is also somewhat easier to supervise. Menuet64 has both 0x40 and 0x60 interrupts available, also from 32bit application.

After the USB mass storage code is running flawlessly, we should add more support for different device classes, like networking.
Post 09 May 2008, 19:31
View user's profile Send private message Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
The other interrupts generate a GPF because the IDT is set up to do so (at least, it looks this way). Most OS IDTs use a default GPF error for unused slots, so all that needs happen is a function pointer to a new ISR in the IDT in slot 0x41 iff the 0x41st slot points to that default.

Looking forward to USB. That'll be cool.

_________________
dd 0x90909090 ; problem solved.
Post 12 May 2008, 06:34
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2145
Location: Estonia
Actually I don't understand the benefits of your proposal, daniel.lewis. From programming side it doesn't matter if you change interrupts or registers. It doesn't change functionality - whether its done in one way or the other in an OS.
Post 12 May 2008, 16:39
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
Very Happy You're right, Madis. Separating the interrupts is merely a symbolic indication to programmers that there is some difference between one or the other. I'm simply indicating a device-wise isolation to compartmentalize work.

I would recommend:

cpu/thread/eip related
memory/paging/alloc/gc related
disk/storage related
display/gpu/physics related
audio in/out related
network/tcp/ip related
keyboard/mouse/hid related
timestamp/clock/apic/little things related

By compartmentalizing device like that, you can upgrade each device in parallel to the others, out of sync, and beginning to remember the right interrupt for a given category is easy (6-8 is a good number for the brain). You can approach the cpu driver as a whole and without clutter and envision gaps and overlap in it's functionality.

That is what I was moving towards.

_________________
dd 0x90909090 ; problem solved.
Post 13 May 2008, 00:18
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4186
Location: 2018
Quote:
a device-wise isolation to compartmentalize work.

and to comparmentalise coding.

a global interface, x86 oriented, shall be found and deeply studied to have a strong and powerfull system.

each layers shall work in parallel, and be as concice as possible.
this is not only menuet os related, but all os related.

and one precision, before to devellop something impossible to rely to other OS, we can seek a method together. exactlly as the OSI and W3C make, but FASM oriented, about os construction, and with direct application.

one second very important thing is to permitt to all FASM based os to execute the same executables binaries, providing a comon minimal interface with the kernel based on normalised hardware.

i have a preference for the .com binary, as it can be executed from boot to v86, and in Protected mode too.
org 100h philosophy. we can use 256 bytes from kernel to provide a semaphore array used by the kernel to communicate with the executable.
this 256 bytes zone can be used as a device interface too.
for example , the keyboard, it can store all the status of all keys.
and for network, it can store the content of a NE2K page.
for audio, it can store the generic controls of the card. and so on.
Post 13 May 2008, 00:29
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
This is my example of taking Menuet and completely compartmentalizing it in this fashion. Go ahead and do it differently or not at all, I don't care. I find it's fairly revealing and useful though.

int 0x41 : cpu driver call
rax : function

5 - Delay
9 - Get process info
10 - Wait for event
11 - Check for event
22 - Wait for event with timeout
40 - Set bitfield for wanted events
51 - Threads
105 - Delay (ms)
123 - Wait for event with timeout (ms)
126 - Switch to 32 or 64 bit
256 - Start process
512 - Terminate process

int 0x42 : memory driver call (obviously needs more work)
rax : function

64 - Application memory resize

int 0x43 : display driver call
rax : function

0 - Draw window
1 - Draw pixel
4 - Draw text
7 - Draw image
8 - Draw button
12 - Window draw state
13 - Draw rectangle
15 - Draw background
35 - Get pixel
38 - Draw line
47 - Draw number
50 - Draw freeform/transparent window
61 - Framebuffer access
67 - Resize/move window
113 - Scrollbars
119 - Draw circle
120 - Window skinning
122 - 3D API
124 - Hide/Show/Activate window
125 - Window transparency

int 0x44 : hid driver call
rax : function

2 - Get key
17 - Get button info
37 - Get mouse data
66 - Keyboard data mode
* - note: some stuff in menuet is intermingled with CPU driver

int 0x45 : misc calls (refactor!)
rax : function

3 - Get date/time
9 - Get process information
26 - Get general system information
58 - Filesystem
60 - IPC
63 - System debug information
110 - Get information about me
111 - Who am I?
112 - Get configuration information
121 - Drag and Drop
500 - System

int 0x46 : port driver call (refactor!)
rax : function

42 - Read data from IRQ
44 - Define ports to read at IRQ
45 - Reserve/Free IRQ for data read
46 - Reserve/Free port for direct read
52 - Network interface
53 - Network interface
114 - CD Audio
115 - PCI
116 - Driver state access
117 - Audio
118 - MIDI

_________________
dd 0x90909090 ; problem solved.
Post 13 May 2008, 01:52
View user's profile Send private message Reply with quote
System86



Joined: 15 Aug 2007
Posts: 77
Makes sense, but why are the subfunctions not consecutive. Why not have them go up 0, 1, 2, 3, 4, etc. for each interrupt, if that is done? Is the reason backwards compatibility (to make it easier to port existing code)?

Also, why do other systems (like Linux) use only one interrupt (int 80h) (just a question, not sure why)? There are 256 ints available, and even with 32 reserved and 15 for IRQs, there are lots of ints left. I think each driver could have its own vector, kind of like in BIOS/DOS, were video=10h, disk=13h, kdb=16h, DOS=21h, mouse=33h, etc. There are plenty of interrupts available, why not use them?
Post 14 May 2008, 00:25
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2145
Location: Estonia
I'll have to agree more with daniel.lewis's proposal here because going the DOS ways has a few more negative sides.
One is programming. You will have to program every vector. MenuetOS resolves this by having only one, but asking user the function (=EAX/RAX).
Other is well debatable, but this 32-to-64-bit transition showed us how sparing ints may help. Just change one value from 40h to 60h and you're calling 64-bit functions. When you take most of the ints in 32-bit world, you'll have to scrap everything or write over them etc.

daniel.lewis was proposing organizing. You're thinking on the road of separating everything.
Post 14 May 2008, 05:47
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
Smile Okay.

He was right about making the interrupts more consecutive, I was just showing the mapping from the current numbers into appropriate groups.

Separating interrupts into specific devices gets problematic because it's quite feasible these days to have a single terminal server with 300 users. Or the OS being used with a similar number of DoF for a robotic assembly line.

Point being, you want broad semantic categories on an ISR, at most. That way at most you'll have 16 interrupt lines, and can do what Madis suggested.

The reason you *do* want more than one interrupt line is so you can keep your API coherently listed even when you need to add 1 function to the memory driving component.

Wink

_________________
dd 0x90909090 ; problem solved.
Post 15 May 2008, 00:17
View user's profile Send private message Reply with quote
Tolle



Joined: 21 Jan 2004
Posts: 71
The following is all in my honest opinion:
Quote:
The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs.
By using more interrupts, you are not only adding another (useless) abstraction layer, you will have to write new code to handle these interrupts. Code that can introduce new bugs. While we have a working system right now.

Consider the following examples:
Code:
;Let's draw a black pixel at 10,10
mov rax, 1
mov rbx, 10
mov rcx, 10
mov rdx, 0
int 0x60

;Now, since i don't like remembering numbers i use a neat little trick
putpixel equ 1
button equ 8
waitforevent equ 23

mov rax, putpixel
mov rbx, 10
mov rcx, 10
mov rdx, 0
int 0x60

;Since the above works out quite nice, i decided to add another equ

sysint equ int 0x60

mov rax, putpixel
mov rbx, 10
mov rcx, 10
mov rdx, 0
sysint

;I don't have to worry about sysint,
;it will always do what i want and always logically conclude my system call.
;It will work for every function out there,
;i can easily spot a mistake and i have to make zero modifications
;to the kernel to code like this today.

;If we modify MenuetOS to add more interrupts i could still use equ's 
;but i will at least double my changes to goof up because now i have 
;to remember not one but two numbers/identifiers per sytem call.
mov rax, putpixel
...
sysintdraw

mov rax, getprocessinfo
...
sysintcpu

mov rax, getprocessdata
...
sysintcpu

;Since you knew it was coming, you will have noticed that i conclude
;both getprocessinfo and getprocessdata with sysintcpu while
;in the example daniel.lewis gave above, i would have 
;to type something like sysintmisc, my mistake. 
;I hope i don't spend the rest of the day looking for this bug.

;+ you are opening a whole can of worms on deciding what function 
;belongs in which subfamily. a problem we don't have now.
;32 vs 64 is pretty strict, i can live with that one.

;If you want to have some sort of structure in your own programs,
;you can also use equ's

display_putpixel equ 1
hid_getkey equ 2
...    

Keeping structure might seem great and it usually is. But fighting numbers with even more numbers will (again imho) always fail.

The less i have to remember and think about things, the better.
Post 16 May 2008, 01:25
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
Well Tolle, there is no additional abstraction or layers or new code or new bugs.

Right now, flow goes into an interrupt, goes to an isr function which is a switch and each case is a "function".

My proposal, flow goes into an interrupt, goes to an isr function which is a switch and each case is a "function".

Rolling Eyes

Personally, I think it makes sense separating "draw a button" from "get process info" on the API.

More importantly, I think it makes sense to group things different ways to recognize the gaps and overlap in functionality provided by one. Like I said, use it as you see fit.

_________________
dd 0x90909090 ; problem solved.
Post 16 May 2008, 05:27
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2145
Location: Estonia
I'm for it with my both hands. You are better off hiding the numbers with macros as Tolle showed us here. Then the user doesn't care anyway about what's behind it.
Post 16 May 2008, 05:28
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 215
Currently we only need to remember a single system call for function. Adding new interrupts will just add another layer to be remembered. Not to mention the need to rewrite most applications and M64 system calls.
Post 16 May 2008, 17:06
View user's profile Send private message Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
Meh. For my fork I don't care about apps yet, just the OS. I look at it as a need to move to support drivers; and that using a single address space for all drivers will result in more pollution long term than using address spaces for each driver class.

It might also be possible to dynamically map interrupts to a program but ultimately if you want device drivers it makes sense to offer them some kind of ISR interface.

I would also like to say that I haven't yet done what I've said above and by the time I do a good number of the relevant function calls will be different.
Post 21 May 2008, 05:17
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-2019, Tomasz Grysztar.

Powered by rwasa.