… Because I claimed that the Egyptian government is in control of their phone spyware. If police in westernised countries have access to this kind of technology what do they think other people will be doing with it?
The only real solution is to promote full secure operating systems with no planned government backdoors (it seems to be the case that the popular phone platforms pushed on everyone are designed to destroy user privacy).
My earlier bugs seem to have just been in obscure test scenarios (specifically reading/writing zero-size or huge-size blocks at a time doesn’t work!), in normal operation such as for simple non-blitting drawing commands the networking & threading code doesn’t present any problems.
Without further hesitation, finally a screenshot of a regular “client” program running on the new desktop system on my kernel (within an emulator window still!). From these humble beginnings I hope to develop an entire graphics library that’s efficient and flexible enough for my OS.
I announced the new desktop system at the very beginning of it’s development, the time since has been spent developing more of a structure for prototyping the desktop system and working towards resolving underlying weaknesses in my kernel & platform.
The desktop system is designed in a fairly straightforward manner:
This design is similar to some legacy graphics systems and also helps test features like networking and multithreading in the kernel, the downside being that it’s very exposed to any bugs or limitations of these features.
The first problem with this approach was that I had to extend the networking code slightly to enable a “localhost” type loopback network.
This now appears to work, but may need some cosmetic changes to avoid people confusing it for a real network driver (right now it shows up like a normal network backend).
While the client/server architecture works correctly on the new kernel & microps-based network stack in simple test cases the kernel will probably require some more troubleshooting before I can get it to work reliably with multiple threads and in different timing scenarios.
Multithreading code in the kernel has only been used for straightforward tests previously so some degree of “unexpected” behaviour was expected. Currently I’m having some problems with the secondary thread hanging when almost the same code seems to work in single threaded or forked-process situations, so this is likely a problem relating to unfinished multithreading support but will take a little while to figure out the exact problem.
While basic support for multithreading exists at the kernel level, the libc (C library) implementation currently has no support for multiple threads, so the current problems could just be a simple problem like malloc memory being corrupted due to a call in the second thread. In that case the fix will probably just be enabling locking in some libc subsystems.
It’s all still coming, and some more workarounds can be made if not every problem can be solved in the short term, but the kernel & libc code in particular will take a while to get to a stable point where I can easily develop & debug new programs on it!
This is part of the reason the desktop system is designed to run on Linux or elsewhere as well, making it easier to determine which bugs are in the desktop code and which are deeper in the system.
After spending some time messing around trying to port existing GUIs I decided to just write a new one, one advantage of this approach is that I can easily make builds for SDL2 as well as for testing on the new kernel in an emulator. Right now these only demonstrate simple mouse pointer operation, but the internal code for rendering this example is the same on either backend.
(NOTE: These examples are filmed on Ubuntu, so both should just look like a mouse pointer demonstration running in a window on another desktop for now! More advanced screenshots with my own window management code etc. will come later.)
Mouse pointer movement is smooth after initial test code was improved slightly. Looks like the system will have no trouble running a desktop and probably won’t need any advanced optimisations except for gaming & other multimedia intensive apps.
An initial version of my GUI API is now complete but not yet ready for detailed screenshots. I may upload some initial output from my new guitest program later.
This kernel-level API is reasonably well designed and should be flexible enough for future extension, but for now only covers the most basic operations of blitting to a screen and receiving associated mouse/touch input (with keyboard input half connected but unfinished for now, i.e. without keymap support).
Further experimentation particularly focused on performance & reliability will determine whether to expand the kernel-level API into a full GUI system or whether to leave it as basic drivers and use a portable graphics server such as Nano-X (the kernel-level interface is designed for both possibilities but windowing is not yet fully implemented in the kernel).
The choice was specifically made to offer a simple and easy to document interface rather than to require opening multiple different devices or configure modes from the program’s end for basic operations, the system is tuned for simple “framebuffer and mouse pointer” operations.
In summary this should be one of the better implementations of a graphics API as far as programmers are concerned, and is very easy to operate & extend with a minimum of fuss required at the program’s end to push pixels to a graphics output and receive events associated with the same screen (whether a physical screen or, later, a windowed abstraction).
Just a sneak preview of in-development code. This API is designed for 64-bit platforms, and may have to be de-optimised a bit if I do any 32-bit ports in the fucture.
SDL etc. usually use a plain struct (like my guirect struct) for passing rectangles, but for kernel system calls it can be better to avoid using too many pointers as long as this method (encoding rectangles as long values) is sufficient.
I’ve already posted some demos at the start of the year but these were much too simplistic to attract any attention so I’m starting to plan a proper launch now with some more capabilities.
Looking at about 3 weeks for basic GUI support becoming stable unless I face any major hurdles (pretty unlikely in an emulator environment), an additional 1 month or so to get some more interesting demo apps working (maybe some games, AI tools etc.), then a further 3 months on refining & advancing the current stack before it starts becoming more useful as a near-general-purpose OS.
So in other words, 4 to 6 months until I can start moving onto my new platform as my main development environment and then updates should start getting a bit more frequent.
This will probably include some very basic web functionality and other things people would expect from a general purpose OS but won’t be competitive with Linux etc. for at least a year or so (when emulators/virtualisation will be more convenient to run “real” apps). The system already has some container type functionality internally but this isn’t fully exposed yet, and other things like drivers and networking will still need more improvement after they start to stabilise, so most advanced “enterprise” & hardware features will be deferred until after an initial commercially-supportable release.
Stay tuned!
I don’t know if I can do anything to improve this situation, but if a professional hacker can’t get access to doctors and job networks here I can only imagine how difficult it must be for more vulnerable members of the community.
Something needs to change around here.
I probably won’t be able to focus on embedded development without setting up a more serious office, my server rack setup is a bit of a mess right now so I’m working from a laptop.
I’d like to do some book publishing in the future though once I’m done setting up my computer gear a bit better, especially making historical documents more accessible, so the business name was partly chosen with that option in mind and my software can be retargeted towards that as well.
So it will probably be a few weeks at least until I have better demos (GUI etc.) as I have some other things to worry about, but I have some excellent plans that will hopefully start coming to fruition this year.