There is a new version of Solar OS available...
As a Christmas present ...

New things:

PCI Devices Enumeration
Network drivers for Realtek 8139 cards
Floppy Driver improved a lot
COM1 Mouse Driver
Improved ATA HDD and CD-ROM detection
Video Driver improved with 8 bits resolutions

Network Applications:
-Ethernet raw packets send/recive,
-ARP LAN resolver,
-IP Layer,
-ICMP Ping and statistics application
-UDP layer
-DNS resolver Application

GUI Improvements:
-Added Icons and GFX as HE Sprites (+Animated)
-Scroll Bars improved + added horizontal
-List Box improved
-Anchor controls bottom/right
-Keep relative size for controls

Print Screen Application:
-saves raw on floppy
-you must use rawread and IfranView RAW plugin to read image in.

System Colors application
Fdisk Application
Character map application
Debug viewer improved a lot
Text view Application

Other minor changes:
-Press Alt+A to toggle alpha of selected window
-Ctrl+X clears Edit box contents
Posted on 2004-12-24 22:57:43 by BogdanOntanu
Wow the size as incresed 575.24% :). I guess because you start making apps for the OS ????

I will check it out :).
Posted on 2004-12-25 17:53:04 by rea

The size did increased because of:
(in this order):
1)I have included fancy GFX for all supported resolutions, mainly icons :D but also dialog and toolbar items.
2)PCI devices text file occupied some space.
3)Network applications
4)Other applications
5)new controls+unfinished controls

Sorry it is mea culpa about the icons/unused GFX,
Hopefully i will reduce the size in the next releases...
Posted on 2004-12-25 19:02:14 by BogdanOntanu
I was refering more in the way, wow, you have worked this months :).
Posted on 2004-12-26 10:25:34 by rea
Lots of work done. Nice progress Bogdan. Keep it up.
Posted on 2004-12-27 08:48:15 by SpooK
hi, i just wanted to say i downloaded and booted it, and that its great and cute and keep doing such a good job.

i would even help you maybe if i had some time... and if i liked masm more... and if i wasnt so lazy... and... hum, oh well.

One thing that would instantly make it totally ROCK imho, is a GUI file explorer (even readonly), again maybe i m talking but not doing...
menuetOS still hasnt that at all.
hummm well it would need a support for treeviews, but maybe its possible to write it with the little controls you ve already implemented.
cant you generate binary execs for it with nasm or fasm in some way(yeah, yeah, i m stubborn)?
Posted on 2005-01-13 08:58:18 by HeLLoWorld
I'm sure Bogdan is moving along at a pace that will allow clean implementation of such things instead of the quick fix hacks. Doing something right the first time prevents you from having to fix it later.

There shouldn't be any problem in using NASM to write binaries for his OS. It might take a little work to do so, but it it possible.
Posted on 2005-01-13 09:36:14 by SpooK
BTW there is a GUI file explorer already done from a long time in SolOS just check the applications submenu.

The latest version from 2005.01.08 is even able to select and browse multiple FAT32 partitions. Older version was able to browse a single partition only. Other partition types are detected but are not browseable for now. CD-ROMS and NTFS will become browsable pretty soon.

Listview and treeview controls will also be implemented soon.

I do not mind redoing things again and again because each time i do them i little better and not taking anything for granted is the path towards real inteligence.

Yes you can use NASM and FASM and MASM and other assemblers to write binary code for SolOS.

But you might have to update the include files a little. Also curently you must write position independednt code by hand :D I have samples on how to do this in the doc_sdk folder in the sources distribution. I will need a linker / loader that is able to relocate code at runtime in order to avoid this position independent code issue.

So yes writting binary code for Solar OS is possible but a little harder than writting applications embeded in the kernel.

One other option would be generating OBJ with your favourite assembler and then link them at OS build time with system32.obj. The gfx objects are linked this way.
Posted on 2005-01-13 12:23:42 by BogdanOntanu
Bogdan, it's pretty easy to convert a PE file to something that is more easily loaded - if you want to have a look at my PE->FXF converter and asm loader for FXF, send me a PM.
Posted on 2005-01-13 13:29:16 by f0dder
position independant code?

btw, when i was hearing "flat mode" and each app has 4Gb space i always thought it was implemented loading a new seg at each process switch, and the seg had a different base for each task, so in fact the apps were lying at different LINEAR addresses.

i believed that for quite a long time.

in fact all segs are zero, and the apps lie at overlapping linear addresses(zero and farther) , but the funcking PAGE TABLES are changed a t each switch, so only the PHYS addresses are different... I correct??(thats the way in win and unix?)

i think its far simpler just to switch seg bases... but i dunno much bout paging.

how's it done insolOs, please? i m not brave enough to browse the sources.

with the segment method its very easy to implement loading of executable object code at runtime, the code just has to assume that it ll be loaded at zero (or 0x100 for a dos .COM) .HECK! segs werent introduced for nothing (hmmm...okay its a bit complicated :) ), and we ve got a processor that has dedicated adders that we can use for free at each clock cycle at each RAM access to add the base of the seg to the offset of the data.

hmmm... should go home now.
Posted on 2005-01-13 15:39:11 by HeLLoWorld
hmm and maybe i didnt look hard enough(i thought i had gone thru every single menu of the OS :) ), but i just found something that displays the filenames and the dirs...

i meant a shiny, new, beautiful graphical explorer, like in windows, with the mouse working when you click and expand folders, where you can sort files by tpe, associate the opening of a text editor, or copy/paste things... i think your project is maybe the one i would be the most willing and proud to contibute to...i already have other things that more or less fucking BORE ME... imho the explorer is one (if not THE) KEY app in an OS.
sometimes i think i m going to BREAK the table or the screen at school just because their linux dont have a decent file browser, well , and because one of my exams will be the same day as a kickboxing competition i was planning to do, too.
Posted on 2005-01-13 15:55:06 by HeLLoWorld
Paging allows for more fine-grained access control, though - and it's very useful that you can remap linear->physical areas (one cute use would be allowing all applications "direct screen access", but redirecting the non-foremost app memory region point to buffers. I'd still prefer a decent API for it, though).

If you want to support virtual memory or on-demand executable loading, paging is also nice, and more flexible than segments.
Posted on 2005-01-13 16:12:47 by f0dder
Thank you for the info fodder ... but PE is a windows specific format ;) is it not? so i could not base my OS on it, but yeah it could be an intermediate solution for a while...

I dislike paging, i like segmentation but not enough to use it for now ...

Everything is shared in Sol and all memory address are physical. The screen as well as any hardware is accessible to any application whatsoever. There will be a decent API for direct exclusive screen access .
I do not plan to support virtual memory.

You did not look well :P
1) press Sol Button,
--> Sol Main menu opens
2) press Applications Button
--> Applications menu opens
3)Press HDD Explore Button
-->HDD Explore application Starts

In the top listbox there will be a list of detected drives adtheir partitions/filesystems
Select a HDD with a FAT32 partition
You can now browse the drive
use keys:
-Alt+Enter opens selected file in Text viewer
-Enter opens the selected file in Hexviewer
-Also enter opens a folder,

You can use the Up button to go up one level in folder structure

Use Name,Size,Ext buttons to sort files acordingly

Yes the HDD Explore application is in its infant stages and heas some problems/bugs but it will evolve.

Maybe you only use NTFS filesystems or Linux extfs2 or other...

I never said that each application has 4G you wanted to hear that :P imagine 100 applications ...

Instead ALL applications share the same 4G RAM and have full access over it (and hardware)

The mode is flat indeed as all selectors point to 0..4G base and limits

Sol OS is done very simple and mainly on a need to do basis. So i have no need for paging now and no need to move segments arround in memory either :D
Posted on 2005-01-13 17:22:39 by BogdanOntanu

Thank you for the info fodder ... but PE is a windows specific format ;) is it not? so i could not base my OS on it, but yeah it could be an intermediate solution for a while...

I can't see any limitation of PE that makes it unsuitable for other OS'es - it's pretty flexible, and since you can manipulate base address and PEs can have relocations, they can run fine under other OSes. Also, you don't have to use the windows way of imports, you can have 0 imports and do API another way. It's nice being able to use existing tools to create executables :)

I created my FXF format for a project where a full PE loader would be infeasible, and then wrote a PE->FXF convertor to be able to use standard tools (and imports, etc.) to create the FXF images. It works pretty well, and the code is only a couple hundred lines of FASM - including imports and relocs. Handling aPLib compressed images is another ~150 lines.

I dislike paging, i like segmentation but not enough to use it for now ...

That's fine, I'm not arguing you should use paging - will be interesting to see an alternative as most OSes out there are paged. I prefer paging myself, even if it means TLB overhead and such. I like the protection and flexibility :) SolOS goals are obviously different from my toy kernel goals, and that's just fine :)
Posted on 2005-01-13 17:41:21 by f0dder
Very - Very Impressive Bogdan.
Posted on 2005-01-13 20:18:37 by JimmyClif
yes, i had found the explorer, its not that much graphical, but its a start.

i didnt say eachapp had 4Gb of meme in your OS, its just the addr space...

but in win/unix each app has its own 4Gb space , but if i understand well, in your OS each app lie at different linear(=phys) addr...

so yes for apps not embedded in the kernel, apps that are loaded dynamically, you must compile them knowing the location they will be loaded at, or write them as position independant...

i think i understand, but for multiple instances of a kernel module its the same thing?oh yes, they share their code and static readonly data... and for the variables? you only do malloc?but you still have to store at least the malloc pointer (base of private data) for each instance and load it at process switch... in fact thats what segments do LOL

and each app can R/W others data code etc... you could also protect via segments...not that its absolutely needed, though... i read once"blabla... and then paging protection was more flexible etc"... as long as you dont need virtualmem, i cant see why...
ofcourse with segs if you ve got no protection you can also access all mem, but only mem at HIGHER addresses than your app...right? what happens if you try and access mem when the seg base is lets say 3 gigs and the offset 2 gigs? does it wraps around?

and yes with segs (each app at different logical, but each app has its own seg base) you cant access absolute locations like VRAM as easily as otherwise (the relative addr of the LFB changes by respect to every app) but since you would prolly do a syscall to get the LFB addr its no prob...unless you want the OS to have the right to change the app location while its running without telling him...(dangerous!)...

i dont say you should go with segs, but i prefer it: otherwise even loading and firing executable code is hard coz it implies patching all addresses of the code , so it implies an exec format with link info, it sux... DOS .COM are very simple by comparison! but then theres the problem of shared problem if you change segs at each call... i see, it makes a big number of far calls. hmm... okay, everything has a reason to be the way it is.
Posted on 2005-01-14 07:30:21 by HeLLoWorld
The HDD Explorer will get more graphical in the future.

Each window instance has a small spare space for variables starting at window_data01. You can store variables here or indeed you can store a pointer to a dynamically allocated memory block that would hold your application's private variables

I also prefrer segments over paging. owever i use none for now. I work on a need to do basis and until now I have had no need or no simple acceptable solution.

However i will have to find a solution some day ;)
Posted on 2005-01-14 14:33:16 by BogdanOntanu