After a long period of silence, finally some news on SkyOS. SkyOS now has a dock-like launcher application, written by Lukas Linemayr. Other than that, the core components of the operating system are now available in a staggering 27 languages. The translation from PE to ELF is almost complete, and a new release, with desktop compositing, should be released shortly.
Its interesting to read the various comments on the site regarding changes to compositing esp from others that are doing their own render schemes not related to SkyOS.
The change from the original scheme was obviously needed.
Can’t say I buy into the glassy translucent window thing, seems a good way to show of GPU power at special FX than actually being useful. It also shows that 1 or a few people can do what MS & Apple no doubt have many more people working on. I never read a book with transparent paper though and wouldn’t want to.
To add to the comments I also use a single screen 32b backbuffer for my lil ol windows project and have pretty smooth responsiveness with many hundreds of large overlapped windows. It all comes down to the way the clipping is done. I know how Apple QD used to do this with regions as lists of delta edges. Instead I use a low rez bitmap so every 8×8 screen pixel tile has a 1 bit mask so blitting is done 64pixels or so per clip test. The unwanted overdrawing is hidden by rendering windows back to front so approx 20% more pixels are painted than absolutely needed. An earlier scheme used to test every pixel and was very slow.
Also drawing is only done on Pulse events if the clip mask has been changed. User actions simply cause Show() to add more bits to that mask. The front window uses that mask as is, each behind windows use a clip minus each infront window. Since this is all low rez b/w, its pretty fast and most clip masks are null. Ofcourse I’l never have enough cpu perf to do translucent or alpha effects.
I’d be curious to know more about SkyOS region clipping if its still there, bitmap or rectangle lists of some sort?
Window compositing isn’t about transparent windows so much as its about being able to do window moving, resizing, etc, with zero flicker. Also, transparency might be annoying when overused, but it can also allow for rounded window corners that don’t look like ass because of aliasing, as well as subtle effects like window shadows.
Okay for transparancy, I could live without with the ever so subtle effects I don’t normally notice like the shadows and for some rounded apps like clocks. Most of the gross rounded apps I see are those awefull media players that come from graphic card installers.
The technique I use for window moving, resizing is entirely flicker free since draws are only done during the Pulse event, effectively the user interaction queues up tiny draws in the clip bit map which is then emptied or zeroed after the Pulse update. In the Apple QD world this was done by region accumulation. Being cpu driven means that the window dragging is a tad bit more jerky than if done by a GPU, but this lil project is intended for a GPU less system.
FWIW this is built on top of BeOS but should port to any OS since it doesn’t use more than a few hooks to the host. That will allow it to run on cpu only FPGA system with the look n feel of a regular OS.
What I find most interesting in alt OSes is to see what the consensus is on doing things, whether for or against the mainstream, user features and internal details.
That’s certainly news. Window compositing in an alternative OS (a first?). Shows Windows can’t get their act together
Thats not entirely accurate, the problem with Microsoft, like Apple, is that they have to provide a degree of backwards compatibility for those old API’s that still rely on the classic way of doing things – in the case of Windows, its having to move, and test their grab bag of toolkits to see if they work with the new GDI+ which is based ontop of the composite engine.
In the case of Apple, the reason they haven’t turned on Quartz Extreme 2D because it cocks up applications that still use the class quickdraw interface – hopefully in the future we’ll start seeing vendors move away from that and instead using the more modern Quartz 2D and Cocoa for their GUI front ends.
hmm, and here i tought that apple had a history of dropping backwardscompatiblity whenever it got in the way of advancement…
Nuff said. Robert’s awesome.
There are still a few bugs that need to be worked out before another release can be made (crashes).
I’m looking forward to developing for and using the newest build of SkyOS.
Great work, as always, Robert.
http://shots.osdir.com/slideshows/slideshow.php?release=519&slide=1…
I’ve noticed lots of artifacts and redraw bugs in the older betas I downloaded – I need to get a free minute to try this new one out. The bugs seemed to stem from this old method they were using, which led to missed redraws. I can see how the new structure also helped with the translucent effect, but I honestly couldn’t care less about translucency – I think it’s overrated and often used when it shouldn’t be.
(Had a hard time clicking a window border before? Well now it’s freakin see-through!)
I was more interested in the transition from PE to ELF, it’s a considerable migration from what I understand of it. One of the few things BeOS and Dos/Win had in common was a binary portable executable format (not literally similar, but the concept was similar). From what I’ve seen, this generally lead to smaller (filesize) applications.
I’m not really familiar with the ELF model, and am interested in what the differences and benefits are (other than porting and migration – which I admit sound good).
But what is the underlying difference between the two? Are there others? Perhaps there may be a middle-ground layer to support both (upward compatability is a wonderful thing). I imagine implementing system frameworks like Java or .net/.gnu/mono could have their own model they would prefer – and while accepting MS-related frameworks is distasteful, having a migration path wouldn’t hurt.
I was more interested in the transition from PE to ELF, it’s a considerable migration from what I understand of it. One of the few things BeOS and Dos/Win had in common was a binary portable executable format (not literally similar, but the concept was similar). From what I’ve seen, this generally lead to smaller (filesize) applications.
Incorrect, BeOS used the elf format, they moved to elf in R4 – hence the big commotion made by some when they broke compatibility with R3, which used aout IIRC.
Okay, that’s a good point – they moved to elf in R4. And I can see that Sky is going through the same transition, so is there a bad-practice or limitation in PE or is there something else that ELF can provide? I’m just saying there’s probably a good reason for the change – and I haven’t seen a good one other than software availablility (which is good, but it seems to be a bit of effort).
You probably can’t leave missing symbols in PE. When you compile DLL in e.g. VC++, it complains about missing symbols in DLL, when you won’t declare them (you can do that in ELF). Also the other annoying thing is that you need to use __declspec() for exporting and importing symbols. In ELF symbols are exported immediatelly (you can use __attribute__((visibility(“hidden”))) in new gcc and binutils – symbols will be hidden from dynamic linker). I don’t know if PE supports weak symbols (e.g. when you have foo() in libc and foo() in libd which links in libc, then foo() in libd() wins and it’s used in whole app). In ELF you don’t have to build import libraries – you just link app/library with .so file. IMO important advantage of PE is that you can use Visual C++ compiler to build apps for your OS if you provide libc and other system libraries (custom link without standard libraries and compiling without using compiler include directories).
Edited 2006-06-25 07:55
BeOS used PE i R3.
Yes, you are right ( http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/developer… )
If all things a constant, its probably not only for compatibility with the rest of the UNIX world, but for performance reasons as well.
Perhaps I missed the question, but what exactly is the compatibility with existing applications from Windows, Linux, Mac etc? I’d assume, none? What’s the plan for a wide enough software base to attract users?
SkyOS is highly POSIX compatible making it easier to port open source applications.
For small applications porting to SkyOS just means recompiling it.
More advanced and GUI applications usually need some more work to get it running on SkyOS.
It’s certainly not binary compatible with other OS’s.
Some bigger applications that are already ported are: Firefox, Thunderbird, samba, apache, gaim, gimp, abiword, …
Some users are helping Robert with porting applications to broaden the available software.
The POSIX-compatibility in SkyOS means that many applications can be ported from the *nix-world with a minimum of fuss. This has already happened.
However – it does look like the preferred way is to develop native applications rather than using “foreign” applications.
It’s the same line of thinking you find in Haiku and Syllable.
Yeah I read the POSIX compatibility and suspected UNIX/Linux re-compilation. Though I would be curious as to the draw of using this operating system over well established Linux distributions?
Don’t get me wrong, the development of a stable operating system that’s POSIX compliant is a treamendous effort, I just question how they plan on building business model around a very small operating system when Linux is available.
Well, to get the best answer to that, I really suggest you visit skyos.org and especially the forum.
I went to the site to try to find out more about this OS, but I couldn’t find any text on wht SkyOS is good for.
The site displays a complete lack of vision, is this becuas of bad PR-skills or is the development truly “random”?
From the site:
“SkyOS implements the same fetures as everything else out there. It isn’t open source. It isn’t done yet but will cost money when done… and, oh yeah, we aim to be easier then the rest”.
Is this the official sales pitch?