Hi all.

There is a new SOLAR OS version at www.oby.ro
http://www.oby.ro/os_main.html

add: above server might not be up 24/7, a more reliable host is still available at:
http://www.hostileencounter.com/os_main.html

What is new:
-------------------------
Multiple desktops
Tasklist/bar with minimize/restore
HDD Fat32 Explorer is improved
Keyboard driver improved
API functions have evolved a lot.

Works pretty well under vmware or booted from a floppy on real hardware and will not attempt to write on your HDD (not yet)

Source code is included.
Also the first version released under GPL license.

This is work in progress and any comments, observations etc are welcome... both positive and negative

I see SOLAR OS and Menuet OS as brothers
since i now use GPL also maybe whenever Menuet will need an improved GUI ... you guys could use my GUI

GPL? f0dder?

I find GPL to be a nice and funny license...

Since Menuet is also GPL i do not see any problems

I do know that f0dder dosent like GPL --as he stated may times -- but i fail to see the connection with this thread / my OS ?

very nice!
I like your Os Concepts "manifesto"
keep up the good work

Very well done, nice work Bogdan, I note that Hawk is working on HD, and your web site explains that currently, booting from floppy only, is permitted, looking ahead though, it might be useful to have a usb interface to permit booting from flash memory.... I think that fasm forum participants will also profit from examining a table comparing the strengths or advantages of solaros versus menuet. I am not referring here to benchmark timing, of, for example, operating system specific chores, but rather, feature comparison illustrating the design differences of the two os. I agree with the previous poster, ox4e71, that the "concepts" page at your web site is very well written, and commendable. Writing only for myself, I would argue that you might even wish to elaborate further on two critical points raised at this "concepts" page:
" Allow full ring 0 control and single thread models
Task switching and protection waste our preciouse time and resources.
Why check an application for errors at every run when it is supposed to be "error free" ?
Why trash cache at evry task switch at arbitrary moments ?
Why switch from Ring3 to Ring0 at every OS System Call ?

Allow preemtive multithreading and ring protection model also
Wastes time, CPU power, and it is useless for well written applications, BUT it is usefull in debugging and while developing applications "

You may wish to underscore, in connection with these two issues, ring 0 control, and preemptive multithreading, how solaros differs, if at all, from menuet.
Another possible area of interest to fasm forum members, is your assertion at your web site, that the source of solaros is compatible with both masm, tasm, and fasm. Were there any conflicts assembling solaros with any of these three assemblers, and, if not, then, why would you construct yet another assembler? I am not arguing against the notion of creating a new assembler, but rather asking what deficiencies in the three you tested led you to decide to build a new assembler? Since you are clearly also well versed in the unix world, i.e. linux, then, did you encounter problems assembling solaros using gas or nasm? Did you try any other assemblers?
Thanks again for an excellent job in revising solaros, look forward to your forthcoming projects as well. Regards, tom tobias

I have to say I really like your concepts and how you have implemented your OS.

I agree that creating a custom assembler is best, that is what I will have to do for my OS. I like debug, I will probably make mine similar to that.

My concept for an OS is basically this:

DOS with GUI with full access to memory.
It uses the same kind of scheme that dos fasm uses(Real Mode 32-bit code).
It would do the co-operative multi-tasking.
The DS and ES are set to base 0 so that all 4 Gig can be addressed by the registers.

The advantages are that you can use all existing interrupt handlers including disk and video until 32 bit drivers are built. Video is very important in this area since I will support resolution changing after OS is booted.
Decided to go this way because protection and complexity equals slowness(ie. task switching and accessing protected mode registers).

Keep up the good work.

PS: Don't know if you implemented it, but I heard that you are suppose to toggle the high bit of port 60 each time you read in a character. If menuetos didn't have the routine to press the esc key, the PS2 mouse would never work. Do that and the mouse works whether or not you press a key.

Thank you for your kind words / observations /comments...

All observations are carefully noted and taken into consideration


To Gomer73
----------------
I will have to deal with switching video resolution while OS is running pretyy soon. If i will find it impossible to find specific video board code i will then (and only then) retrn for a small timeslice to 16 bits --do the switch using VESA-- then return back to 32 bits mode

As you can see from my OS protection doent HAVE TO mean context and ring 0 - ring 3 switch at every API call. You can still design a full blown 32 bits protected mode os while keeping the speed intact.

I have never heard of that need.. curently the mouse genertaes IRQ12 while keyboar generates IRQ1 and interupt handlers make the difference, i did have some troubles at start with PS/2 Mouse but i hope i am over that now

About me creating yet another assembler:
------------------------------------------------------
1) I want to have an assemble fully (aka with no source code changes) compatible with TASM and secondary MASM...

2)I am unhappy with curent SOLAR OS dependency of TASM. Even if I have a licence (actually 3 now) others do NOT and this will slow down developement. So a free assembler with exactly the same syntax will help

3)I dislike some things in current version of TASM and i want to correct them

4)I want to know the path of making and assembler but ALSO WALK the path ...since there is a difference

5)I need it for SOLAR OS to become independent like Menuet is already.

6)Althought i like FASM a lot i do dislike some of its features/choices, so i see no other option but to make my own...
However since my own will also be free and open source..

I hope that both FASM and SOL_ASM could benefit from my experience
And in the end we will all have a greater range of better assemblers.

I do not see neither my OS neither my assembler as a competition for either Menuet or FASM... i rather see it as cooperation

To: tom tobias
--------------------

I do have plans to allow booting from HDD and USB pretty soon indeed
and AFAIK booting from CD is already pretty easy

Source code of SOLAR OS is NOT directly compatible with NASM/FASM/MASM some changes HAVE to be implemeted presumebly via macros, but i only code in TASM curently... and hpefully soon in SOL_ASM

But yes i have good knowledge of NASM and MASM also, some very early versions of SOLAR OS have been done fully in NASM. I curently need the STRUC and Call / PROC extensions of TASM but i guess FASM could deal with this via macros pretty well. Using GAS will be a lot of work IMHO

Yest that table would be interesting but wouldnt it look like some form of competition ? However it is a good idea and i might do it on my site(s)...but i will have to talk to Ville about that since i guess he knows his strengths better than i do

Yes you guess right SOLAR OS is pretty much different from Menuet OS, pretty much in respect to:

0) Applications & Drivers:
---------------------------------
SOLAR=pretty limited no of Application (only what i needed for demos/debug), limited drivers for hardware,
More embeded style for applications : curently applications HAVE to be compiled with OS, later will load app from HDD but will require relocations because of memory model

MENUET=More applications and more drivers, can load start applications from HDD/floppy image

1) Multitasking:
----------------------------
SOLAR =cooperative
MENUET=preemptive

2) Memory model
-----------------------
SOLAR = full ring 0 unprotected / shared by all applications and kernel
MENUET = ring 0 / ring 3 - standard protection

3)GUI - greatest diffrences
------------------------------------
SOLAR OS = very advanced fully expandable OOP /Callback based GUI, objects can be added easy , Message based GUI, child / parent, MDI windows are very easy and natural to do
MENUET OS == more basic GUI not OOP AFAIK, windows and buttons mainly

4)Kernel/ Realtime
-----------------------
SOLAR = realtime + a little more advanced producer/consummer and state machines queues. Applications produce/consume events from / to kernel.

MENUET = realtime + ? my knowledge is reduced here ?

5)API available
---------------------
SOLAR = not so many functions (yet ) but more advanced (Create_Window/subclass/superclass/multiple desktops)
Parameter are procedure STDCALL frame based. When ring 3 will be used there will be Callgates

MENUET = more functions, parameters are in registers and syscall is done via INT ... a "style" subjectively not on my likeings ... but pretty good after all

Come to think of it, I am not too sure why I decided the Flat Real Mode thing. I think it had something to do with interrupts. I guess I can kind of do the switch to real mode for interrupts for which I don't have the drivers for yet.

My biggest concern was that I am going to support window video memory which means always switching to real mode to draw stuff on the screen. Since any video cards that don't support linear mode probably won't support protected calls. But I guess that isn't too bad.

I can still support a protected mode environment with support for 16 bit interrupts. I guess I changed the way my OS will run. This is important for me because I like to have the greatest compatibility until I can support it in my OS. So it will support hard drive access through bios until I can natively code it. This allows me to use the UDMA drivers for disk access which are currently faster than XP. As well it allows me to use the dos packet driver so that all network cards will be supported until I can natively code support for them. Same thing for sound cards, USB mice, cd-writers, blah, blah, blah. As long as dos supports it, the OS will support it.

Whoops, got the wrong port for the keyboard thing. According to Jeffrey P. Royer, in his book Handbook of Software & Hardware Interfacing for IBM PCs, he says after the scan code is read at port 60h, an acknowledgement for the interrupt needs to be sent by sending a positive pulse on bit 7 of port 61h. Like I say before I did this I couldn't get the ps2 mouse to work after I switched to real mode without pressing a key first. Genuine documentation is always hard to find though.

Are you planning to write a debugger with your assembler?

This is the main reason for me writing my own assembler. A proper debugger saves you 10 times the effort with debugging programs. FASM is even missing this, otherwise I would just modify FASM. The most important thing for me is so that I can see the source code with comments while debugging. This why even using fasm with ollydebug is kind of a nightmare because you can't determine easily where you are in your code.

Bogdan: nice project! I like it

Gomer73: don't you think that modyfing FASM would be anyway simpler than creating your own asm?

regards

Thank you Bogdan for your detailed and thoughtful response to my vague and imprecise questions. I share your enthusiasm for TASM, but confess to being sufficiently hostile to M$ that I have never used masm, and have no desire to commence doing so in this lifetime. I am sure we all appreciate your candor re: FASM and menuet, projects, along with FRESH, that are much enjoyed, appreciated, and, most importantly, created, by the hard work of many of the participants of this forum. I did not pose my question with the idea of suggesting any notion of competition, or any sort of criticism of FASM or Menuet. I believe we are all indebted to Tomasz for creating not only FASM but also this forum, and my question waa not intended to suggest that you ought to find fault with FASM or Ville's Menuet. I was simply impressed that you sought to write source code for solaros, equally capable of assembly with MASM, FASM, or TASM, since I have the impression, obviously incorrect, that relatively compicated projects, such as solaros for example, simply will not assemble using FASM, for example, if written originally for TASM, and vice versa. Your own forthcoming version of TASM, solarasm, would then presumably ALSO include TLINK capability, and the excellent turbo debugger??? Even though you create entirely new source code, won't you run into legal problems with TASM's current distributor, if your new assembler is 100% comformant with TASM? regards, tom tobias: nbri@mail.china.com

For Decard:

The reasons why I wouldn't just modify FASM are as follows:

I don't know how it works. The documentation for it seems to be this forum and the source code. The included documentation is more of asm docs rather than fasm docs. I mean even simple stuff like times and rb aren't listed to my knowledge.

It would take me so long to figure out exactly what it is supposed to do.

The second reason is that FASM is a file compiler and I need a line compiler. This code might be built into fasm, but not sure. I need the line compiling function because I want mine to run as debug does where you can assemble any memory and trace through the instructions.

Thirdly I would have to rewrite it for my OS. This would be no problem if I already knew how it worked. But by the time I figured out how it worked, my assembler/dissassembler would already be done. Assemblers are the simplest compiler, so that aren't actually that tough to make.

Fourthly I want to set a new standard. Somehow getting the organization of C into assembler. Not quite sure how to do this. I know masm uses something like .if cx=1 statements to do this. I don't want global and local linear labels to be my only option.

Lastly, like Bogdan, I like to know stuff inside and out so I would know the most efficient way to write code.

gomer73 wrote: "Fourthly I want to set a new standard. Somehow getting the organization of C into assembler. Not quite sure how to do this. I know masm uses something like .if cx=1 statements to do this. I don't want global and local linear labels to be my only option."
One way, in my opinion, to create a new standard, would be to CREATE THE DOCUMENTATION FIRST, then make the assembler. I believe strongly that the proper STARTING POINT, in creating ANY software, is a rigorous DEFINITION of the capabilities of the final product, including both the algorithms to be employed, and the data structures required. You make a couple of very good points in your sentence above. Surely, you are to be praised for recognizing the need to improve on the documentation issues. Why not go the extra step, and elaborate the documentation, here, at the forum, BEFORE you commence writing your code.
In my opinion, "C" is the wrong starting point. You would profit from NOT following the Americans, and instead sticking with Wirth, and RISC notions: (1) USE AS FEW of the Intel instructions as possible. (2) ABSOLUTELY no pointers, under any circumstances. NO LOGICAL justification for this obsolete approach. DIRECT ADDRESSING MODE ONLY (3) Ditch the stack wherever possible, it is hopelessly difficult to debug programs by chasing stack pointers. (4) STANDARD memory access = 32 bits. NO MORE bit operations, and byte manipulations, etc. Why?? Isn't that one of the great advantages of Assembly, that one can MINIMIZE the amount of memory required??? NO. WRONG. Memory today, IS FREE. USE it. TIME is costly, and I am not referring here to the time needed to EXECUTE A PROGRAM. I am referring to the amount of time needed to DEBUG a program. In my limited experience, it takes 50 X more time to repair a broken program, than the time needed to create the original code. With a standard 32 bit data size, debugging becomes so much simpler, and both the assembler, and the debugger will be much easier to design (5) Eliminate all the "slick" capabilities of other products, and create a VOLKSWAGEN (1930's era, PEOPLE'S CAR), instead of a JAGUAR. A boxey looking, "plain jane", NON-FRILLY, SIMPLE TO UNDERSTAND, SIMPLE TO OPERATE (and therefore, elegant) product that will be both revolutionary, and practical. There is no reason why an excellent product could not be created that worked with ONLY A VERY SMALL SUBSET of the vast Intel instruction collection, AND NEVERTHELESS permitted creation of elaborate programs, including entire operating systems, while requiring users to define data strictly as 32 bit values, rather than single bits (boolean), bytes (characters), and words (I/O). Not supporting the fpu would be very restrictive, but since the integer arithmetic capabilities are superior to the fpu, little would be lost, apart from the transcendentals, which could be computed from a library of functions. Complex data structures could combine four 32 bit values to access the simd registers. Input/output instructions which require 8 bit or 16 bit values would require the assembler to decompose the original values, adding some unnecessary complexity to the assembler, but simplifying program design when using this new assembler. Best of all, such a design, with only a FEW instructions available would eliminate the absurd syntax, employed by almost all programmers today: eor eax, eax (because eor wouldn't survive the cut!), replacing this nonsensical expression, which dates from the 8086 when one clock cycle was saved, by writing instead: mov eax,0 i.e. erase the contents of a register, or assign a value that humans can read to a register, in other words, changing to a new approach, as you mentioned above, one in which Assembly, not C becomes the de facto standard, not because it is the "best" language, but simply because one can read it, and understand it, surely not the case today, as can be appreciated upon reading your rationale for designing a new assembler!. regards, tom tobias

Yes i think that AFTER is have a working assembler i will also start a debugger, the projects are somehow related and experience from one is usefull to the other. I already feel the need of a debugger inside SOLAR OS already...

I guess i will need a linker too

But they do not have to be exactly like Tlink and Tdebug IMHO.

As for looking too much as TASM,

I write my own assembler from scratch and i only try to make it compatible with TASM's syntax folowing just the specifications and changing the things a little where i feel like... i see no problems here

I wll try to implement ALL TASM/MASM syntax in exact form also but only for compatibility reasons, so people that have such source files could still use them as they are unchanged...


After all TASM can assemble MASM and viceversa...
And i hope somebody has not patented ASM files yet

remember me? =)
i write specification...
http://neos32.net/forum/phpBB2/topic.php?p=45
what you think about it?

Well done. I like your static elaboration, "wasting" memory to eliminate need for dynamic allocation. Excellent diagram. If there is a link, I would download your demo. regards, tom tobias nbri@mail.china.com

Hey, exactly the same ! Olly/masm32/fasm/radasm are all great, but I really really appreciate old Turbo-C 1.0 IDE
And as I write a kind of 64-bit DOS extender (actually, entering 64-bit mode on my Opteron is done, but 64-bit exception handling is a nightmare), debugging is where I spend most of my time
Writing a debugger is an investment, should I say a must...
Bogdan, I fully agree with u with a Ring0 unprotected tiny OS, it is what I aim too. So if u put some 64-bit asm in it and an IDE debugger... I'll hurry

Regards

I don't understand this little piece of code in SYSTEM32.ASM



What is the point of moving anything into eax if, on the very next line, eax now will equal zero?

Then the next line will always equate to zero since zero or'red with zero always gives you zero right?

so it seems to me that entire code is equivalent to

xor eax,eax

Yes it is,

You understand well

But you have to understand that it is a leftover form some early tests when i have used a dual mode:either GFX or TEXT mode

Later on when i have abandoned text mode I've just added the xor eax,eax line so the jump below will always succed.

I have thought that if i will need text mode again (for tests) i might just comment out that xor exa,eax line

So baiscally that code has a history of trial an errors (esp until i setup things up and start GUI) and it is possible that you find more such non-logical stuff in there... basically leftover form my paranoia or tests

Slowly slowly i will clean up such dummy code ...

Until i do... if you are ever in doubt ... it is easyer and faster to just ask me