return to home
08/30/16 Goodbye, Exelyx.
After essentially two decades in pre-release, this project is officially dead. Its final form, the Exelyx kernel, was authored in Watcom C and designed to run atop the CWSDPMI back-end. The completed components of the kernel formed a basic environment which probed the hardware available and structured its findings into a data table for applications to easily access. It also supported high resolution VESA graphics and included basic mouse support, but never reached much further into development due to complications encountered with sharing resources with the DMPI server at run time. When it became apparent that there was no efficient way to maximize performance in this manner, the decision was made to cancel the project. Although it may seem to have been a complete waste of resources, the time spent on the many internal iterations of this OS have provided valuable data from real-world field tests of feasible kernel builds which have helped immensely to determine what works well and what decidedly does not. This entire project can be seen as more of a proof of concept study: the goals to which it aspired were found to be appropriate - and the completed portions indeed functioned well - but the implementations of these features were not adequate. Despite this project's cancellation, however, all is not lost - no worries, we are far from finished. The lead programmer of PCOS/Exelyx has created a new kernel called “Night” which will incorporate features and techniques from Exelyx and recreate them in a “clean slate” Protected Mode environment with no DPMI, no background services... nothing. This kernel will be written completely from scratch in hand optimized Assembly using NASM and all testing will be done in VirtualBox throughout the development cycle. Just over a year into development, the Night kernel supports automatic high resolution video mode switching and basic hardware support for keyboards, three button wheel mice, the Programmable Interval Timer, Programmable Interrupt Controllers, etc. Future developments can be followed at the Night Kernel group and in the project's Git repository.
10/21/14 Halloween is nearly upon us...
...and we have some appropriately scary news. The PCOS project is no more! *GASP* What?? That's right, PCOS is officially gone. Well... in name only. As it turns out, there are a couple complications with using the “PCOS” name. It already was an operating system made in the early 1980s as well as the name of a current Linux distribution (“PC/OS") with neither of which this project needs to be confused. Since “PCOS” was always more or less a code name anyway (the finished product was never intended to actually be called “PCOS”) we've changed the project's name to Exelyx - pronounced "Eck-sell-ix". Throughout this entire site and all documentation, we've attempted to update “PCOS” to “Exelyx” where appropriate, with notable exception of the screenshots. We have better things to do than go back and obtain updated versions of them. Besides, they can stand testament to the roots of the project, right?
12/22/13 Merry Christmas!!
So, it's Christmas time once again, and it's time for another update. There's been (yet) another major design change in the Exelyx kernel over the past months. We all know the history of this project has been less than mind-blowing. Its development has been stricken with a long series of starts and stops (more stops than starts) and has had its schedule slip repeatedly with no target release date in sight. Well, as the project nears its twentieth anniversary in 2015, it's time that all changed. We believe Exelyx still has the potential to fill an untapped niche in the low-end computer user base. Today there exists no viable option for users of older PCs to have a modern, elegant operating system which can breathe new life into their aging hardware as well as be a dependable, stable platform for everyday use. We also believe DOS is perfect for these users, but lacking the many features found in modern a desktop OS, its adoption will likely be slow and labored at best. There are several small GUI programs out there, however what they offer is just that - a GUI. When it comes to the demands of day-in and day-out use, they simply don't hold up. Sure, they may successfully put a friendly face on DOS and give folks something familiar to work with, but have they really changed anything? On the other hand, Exelyx was designed from the ground up to bridge this gap. It's not simply a GUI; it works on a fundamental level, interfacing with your PC's hardware to bring a user experience unrivaled by any simple DOS shell. Alas, to attempt perfection takes considerable time. At its heart, Exelyx has always been 16-bit. Talk was made of taking the platform to a true 32-bit base, but this was planned for later in the kernel's life cycle, and not as an introduction build. The main reason for this being the lack of a suitable DPMI server (and we tried several of them) and a good, solid tool set for the authoring of 32-bit code. After all, there's an awful lot you can do with 16 bits if you try. However, with our renewed focus on making this project ship, it became clear that we had no time to design a complete 16-bit kernel only to redesign it in a 32-bit flavor later on. Instead, it's time to do this once, do it right, and make this project happen. With that in mind, a few things are changing around here. You'll notice fewer regular updates here in the news section than usual when the project is under active development, but we're following what has been called the "open development model" for this project from this point on until it's completed. This gives you all the ability to follow along in real time with the evolution of the Exelyx kernel as we write it. This will be done via a Dropbox link which will contain all the code and resources we're using to do the job at hand. You'll be able to check the Dropbox folder and the accompanying development log at any given time to see exactly how things are going, and even submit bug fixes and features before the product is released. The Dropbox link is listed as the "Project Repository" on the home page. We're about to go down a long and winding road, but the end will be well worth it, friends. Well worth it. Now let's do this!
06/02/13 What's this? A domain!
For the first time in Exelyx history, the project is being hosted under its own domain: www.mercurycoding.com. But then again, if you got here, there's a good chance you already knew that. Oh, well. It's still a tasty announcement :D
04/10/13 Progress update.
Development on the NextBASIC compiler has been slow due to a major lack of time and resources, but the project is still alive.
03/01/12 Progress report on NextBASIC compiler.
We are pleased to report that development on the NextBASIC compiler is off to an impressive start. We have decided to tackle the most complex items first, such as nested mathematical function evaluation and complex IF / THEN parsing. At this point in time, the compiler is barely functional but as you can see in the Screenshots section, the basis of its ability to parse and calculate the more intricate algorithms found in some programs is already operational. The goal of this project is to provide the highest degree of compatibility with QBASIC possible while still producing fast and efficient object code. What this means for developers is when using NextBASIC they will be able to directly import the majority of their existing QBASIC code and have it compile to Exelyx native instructions with absolutely ZERO modification, regardless of the complexity of the program, as long as the code uses standard BASIC language commands. Tricks like direct screen writing and manipulation of memory addresses may break due to the fundamental differences in the underlying architecture of the Exelyx kernel versus DOS, but the majority of normal programs should run just fine.
02/21/12 Development of NextBASIC language and accompanying compiler.
The Exelyx kernel has long been plagued by a lack of active application development. And what good is an awesome operating system if nobody's writing code for it? The first attempt to fix this issue was PBASIC, which was simply a Exelyx native compiler for the classic BASIC language. After minor development, the compiler was shelved. The next attempt was to give the kernel the ability to run binaries targeted to other platforms. This approach is also uncompleted, but is still under development and is scheduled to be implemented later in the kernel's life. All this considered, however, these solutions are not the best way to solve this issue, as several developers and users have pointed out. The new solution? NextBASIC. This is not only a new dialect of the traditional BASIC language targeted to the Exelyx platform, but the program will also cross-compile for the Motorola 68000 family and the Intel x86 family as well. The ability to compile native DOS applications means that the Exelyx kernel will no longer have to rely on the obscure and expensive PowerBASIC compiler in which it was originally designed. What's more, since it's a stand-alone application, the NextBASIC compiler can be used with an existing IDE such as QBASIC by replacing the bundled compiler. Since most of the folks doing development on the Exelyx kernel have a stronger QBASIC background as opposed to PowerBASIC, this will open up development to more people, considering not everyone has access to (or wants to spend $100 for) PowerBASIC. Of course NextBASIC will be released as free software, and using an open source compiler will more strongly emphasize the Exelyx project's free software identity.
01/17/12 Preliminary results on execution core... and why there's an Easy68k icon on the homepage. Oh, yeah... and happy new year!
The execution core of the new series 2 kernel has undergone several refinements and enhancements over time as new features were added, designs were optimized and methods and throughput speed were increased. What's more, the latest iteration of this core – literally the heart of the Exelyx operating system – includes even more new optimizations. After the initial round of stress testing, the new features present in the core seem to be solid overall, however there are a few minor issues with instruction accuracy and the like. While these will be overcome with some good old fashioned bug squashing, a more serious problem lies in the core's inherent design. Previously, the designers of the kernel chose to go with the x86 instruction set for it's ubiquitous nature and widespread availability. This design choice was known to impose a tangible loss in execution speed, but with several new optimizations, it was believed that this could be balanced out once again. After speed testing the new core, however, it is apparent that this will be more significant problem than initially believed. The obvious solution would be to choose a different native instruction set which is more highly orthogonal, which would lend itself to shorter opcode-decoding times. However, after further consideration, a different approach was chosen which will retain [and ideally even further] the speeds achieved with former kernel cores, and yet retain the high level of instruction set compatibility with the widely available code base of the x86 family of processors. This new direction will start with a refined, highly orthogonal update of the previous Exelyx instruction set as it was used in the series 1 kernels. This will allow for the highest available execution speeds and easy tweaking and updating of the kernel and its native opcodes. “But wait! Isn't this totally undoing the point of the last several months of development and the big deal you guys made about picking a new instruction set?“ you say? This humble webdude's answer is: “Well, not really.” Stopping at this would in fact negate the direction the developers are trying to go with the new kernel... and pretty much leave you with just a new release of the old series 1 kernel. Definitely not how things should go; you'll be glad to hear that - thankfully - there's more. To keep the goal of being able to reuse the masses upon masses of already-existing code, the series 2 kernel will utilize a recompiler to translate existing object code into highly optimized Exelyx object code. This will allow developers to continue to use the language they currently use and whichever IDE, compiler, disassembler, debugger, et cetera they have in use now, and at the same time eliminate the critical speed hit incurred from having to decode all the complexities of the instructions on-the-fly. The aim is eventual 100% support for already-written executables. And, if the programmer is so inclined, existing applications could be modified to check for the Exelyx environment and then act accordingly. It this way, programs could be made which act in a traditional manner when in DOS and become full fledged, windowed applications when in Exelyx. Recompilation opens up other interesting avenues, as well. It would be theoretically possible to expand the horizons of the recompilation software as well, allowing translation of more than just one flavor of machine code. This means it would be possible to run multiple programs which were originally written for different processors – not just one specific family – all as native Exelyx applications at the same time. A user could run an application originally written with Intel x86 machine code right alongside a program initially coded for a Motorola 68k chip - as long as the dynamic recompiler is familiar with both instruction sets. And while we're on the topic of the 68k processor, the decision was made to make 68000 machine code the first target platform for the dynamic recompiler, for two reasons. First and foremost, it is highly orthogonal to start with, which will contribute greatly to reducing the coding time of the recompiler. Second, it will allow the adoption of a standard development platform for simple initial applications: enter Easy68k. Written and developed by Professor Chuck Kelly, Tim Larson and Paul McKee, this is an excellent 68000 emulator with an assembly code editor and an accompanying debugger, and can produce .bin files which contain 68k object code. This will, in turn, be able to be executed in the Exelyx environment after recompilation. Using Easy68k as a standard IDE will also allow more people to contribute to the project as they will now be able to write assembly code to run under Exelyx from within Windows, without having to boot to DOS or download and configure a DOS emulator. Implementing these things will be a demanding and time consuming process, but the goal of the Exelyx project does not allow for sloppy, patched, poorly written code. Bear with us as the new developments unfold...
05/02/11 Code execution core completed!
The heart of the new series 2 is at long last complete! Today the code execution module was finished and will now begin the customary rigorous round of bug testing. Provided everything tests with positive results, the kernel will be poised on the very brink of release to developers for the start of development of the initial batch of Exelyx applications. This module will be directly responsible for quite literally everything that happens in the Exelyx environment and will be the very center of all work that gets done inside the OS. Stand by for updates regarding stability and feature testing of this new addition to the series 2 kernel's code base!
04/28/11 Questions on functionality and MIDI demo.
Over the past few months we have received inquiries about the functionality of the Exelyx software and accessories and figured it would be helpful to clarify some things. First off, many are coming to the site and downloading Exelyx software and reporting that it does not work. This usually occurs when attempting to run the operating system software directly under Windows. Although past versions have striven to maintain Windows compatibility, the Series 2 kernels are becoming more advanced than their predecessors and therefore break this custom. If you need to run Exelyx or any of the demo programs [CD player demo, video demo, etc.] under Windows, you will most likely need a DOS emulator to do the job. An excellent example of one such emulator is DOSBox which you can get here. And this is the actual DOSBox config file we use on one of our Windows XP development machines if you need a guide to setting DOSBox up to run Exelyx software [although you will need to alter the drive letters and/or paths at the end of the file to suit your particular setup]. In development we also use a pair of very old drivers for sound and MIDI support, which can be obtained here as well as in the Downloads section. It is important to note that the proper execution order and settings are necessary to ensure the system is properly configured, as shown at the end of the aforementioned DOSBox config file. In other news, another piece of the retooled sound kit is showcased: the MIDI demo. Just to make life easier, we included both the sound and MIDI drivers, as well as the DOSBox config file and a collection of sample MIDI files to test it out. You can check it out in the Downloads section.
03/18/11 New look for the Exelyx HQ site.
Everyone's favorite project HQ is undergoing several small layout updates as we switch over to OpenOffice web publishing software. We hope everyone enjoys the new design!
01/07/11 More additions to the CD catalog and an added feature to the Display Module in the works.
Contributions to the CD catalog continue to come in! The CD interface demo contains the latest update of the file, and is available as always in the Downloads section. Also, support for reading .png format graphics is being added to the Display Module.
10/04/10 Sound Module CD interface demo.
The basic functions of the sound module have been written, all that remains is further optimization and integration. The audio CD interface is complete, and could not have been possible without contributions from Marco Koegler and Toshihiro Horie. A demo of the audio disk interface has been compiled and is available in the Downloads section. If you'd like, feel free to take it for a spin! Keep in mind it is only a demo, but the basics are there. You can use the arrow keys to change tracks and seek within a track. When you're done, press escape to leave the demo with music playing, or enter to stop the track and end the demo. The coders of the demo have also added a rudimentary disk checksum system, which creates a file called "checksum.txt" containing the hexadecimal identifier for the disk currently playing. When you begin playing a disk, the demo will automatically check the included catalog file ["catalog.txt"] to see if data for this CD exists and if so, it will load and display the track names, album name, year, and artist as found in the catalog file. We're also trying to grow the CD catalog as much as possible, so we invite you to add listings for all the CDs in your personal collection and email the resulting catalog files back to us! For an idea of how the demo stores this information, you can check out the existing CD catalog file which contains information for a handful of CDs. In final version of this system, fields will be added to hold the name of the person who contributed the album information to the official database, so if you'd like credit please include your name or other identifier so that we can give credit where it's due. We're looking forward to your contributions!
09/15/10 Work underway on Sound Module.
A new module was announced which is to become part of the new kernel release. The Sound Module will add support for asynchronous playback of standard 8-bit wave sounds in mono or stereo with complete volume and mixer functionality as well, including panning and fading of sounds. Despite the limitations to sound quality one would assume the 8-bit format would impose, the clarity of the demo was surprisingly crisp and had decent bass response as well. The module demo also showed a test of MIDI synthesizer support, and a collection of routines to interface with the CD playback features of CD-ROM drives will be added soon.
08/26/10 Display Module set to be split.
Plans were made today to split the Display Module code into a series of individual managers. Instead of having a single (quite large) module which handles all color depths, there will be the 8-bit Display Module [DM8], the 16-bit Display Module [DM16] and the true-color module which can handle 24-bit pixmaps [DM24]. The first of these to be completed will be DM8, which will provide a basic stable graphics platform for Exelyx. Afterward, focus will shift to DM24 since it will be the most widely used, followed by DM16 at last.
03/23/10 Update to the Display Module in the works.
It was announced today that some additional features of the Display Module are scheduled to become a reality sooner than planned. Thanks to the JPEG Encoder version 2, coded by Artelius, the ability to save and load images in JPEG format will be added to the module. The provisions in the JPEG format for saving at differing quality levels will be available. Work is also underway on an inverse rotation/scaling transform routine, giving the module capability to do smooth spinning and zooming on pixmaps.
02/21/10 X86 disassembler still in progress.
Updates have been few, but work is still underway on the x86 disassembly application.
10/26/09 Progress made on x86 disassembler.
Before any major work can be accomplished on the Exelyx instruction execution core, a comprehensive disassembler must be completed which can take x86 object code and translate it into assembly code, similar to the old DEBUG tool included with many DOS systems. A working model of this has been developed, and is being pushed toward completion. Images are available in the Screenshots section. As you can see, most of the basic instructions have already been implemented but some work remains before completion.
10/05/09 Decision on future Exelyx instruction set.
A conclusion has been reached on the issue of the Exelyx kernel instruction set. Although, due to the speed hit which is incurred, the authors of the kernel initially wanted to stay away from instruction sets which involved manipulating individual bits to execute instructions, they settled on using the Intel x86 architecture due to several reasons, the foremost being the reusability of code compiled for other x86 platforms such as DOS. This means that development of fully functional applications for the Exelyx platform will not be held up by the lack of an adequate compiler as has happened with the kernel series 1 releases. The move to x86 will, in essence, turn the Exelyx kernel into a DOS multithreader of sorts, allowing developers can reuse code they have already compiled with their favorite language and IDE and have the programs execute directly on the Exelyx kernel with the added benefits of multitasking, virtual memory and other trademarks of a modern operating system. Under this premise, traditional DOS apps will run as originally coded and programs designed to exploit the GUI and other features of Exelyx will be able to do so as well. Since all interfacing with the Exelyx GUI will be done via memory and/or interrupt calls, an application could also be designed in such a way so as to allow it to behave one way under plain DOS and behave as a Exelyx app while running with Exelyx.
09/07/09 Instruction set changes.
Recently the developers of Exelyx have agreed that it may be beneficial to change the Exelyx instruction to a clone of that a specific microprocessor or processor line. This would not only streamline developing, but would eliminate the need for a specific compiler since anything compiled for that chip would run natively in Exelyx. The instruction set that will be adopted will be from a platform which uses whole bytes to describe registers, memory locations, and the like. Among the platforms being considered are the DragonBall processor, the ARM series, and Motorola's 68K family. We are initially not researching the Intel 8088 and others which would involve splitting the instructions into individual bits in order for the kernel to determine what to do. So in short, we want your vote. Which instruction set should become the standard for Exelyx development? Let us know what you think.
05/22/09 The Exelyx Development HQ moves again!
Well, not only has the Development HQ moved its physical location, but now its web location is changing as well. Due to Yahoo's decision to shut down Geocities, the project's site has been moved here to Tripod.
03/14/09 Rewrite of Memory Module scheduled.
The Memory Module, in its past design, had little more to do than keep track of which memory blocks were allocated to which applications, and depended on the underlying memory driver to perform the actual allocating, releasing, and compacting. In the scheduled rewrite of the Memory Module, it will take over all these jobs, allowing a multitude of extra handles to be allocated. Even under pure DOS with the standard XMS driver, handles eventually reach a short supply. The first release may have an upper memory limit of 64MB, but this will quickly be changed to the full 3.5GB that Exelyx kernels past could work with.
02/14/09 New instruction set released.
Today marks another significant step in the development of the series 2 kernel. The new instruction set list has been completed and added to the Kernel 2 Series Specifications Document. The 61 instructions currently listed are definite at the time of this writing, but more may be added as development continues.
02/08/09 Work on the kernel resumes.
Even though the Exelyx Development HQ is not yet settled into its new location, this hasn't stopped everything. Work began again recently on the Memory Module for the new series 2 kernel, and is scheduled to be completed by the end of the month.
01/09/09 The move begins...
The Exelyx Development HQ has begun the moving process. Oh, for a simple MOV instruction to work in this case! After taking the majority of the month of December off for holiday activities, the staff will begin to assemble a collection of new hardware which will form the backbone of the new testing and development environment. Granted having to move the entirety of the Exelyx HQ will take some time, especially since it's being done in the middle of Winter, (good timing on our part, eh?) but the end result should be well worth it. On completion, some time in the next few months, development will get up to speed, and return to the regular schedule.
11/01/08 Exelyx Development HQ upgrades.
Some changes are in the wintry air! Over the next month the HQ will be relocating, so if updates to this site become a little sparse, don't worry, we're not disappearing! After the move, the HQ will be getting some new hardware for the explicit purpose of creating a more diverse environment for software testing. New test machines will be added to the existing ones already in use, allowing developers to test the upcoming series 2 kernel on desktops and laptops both new and old. So stay tuned!
10/21/08 We have a winner!
Just over two weeks after its release, the message has been cracked! We congratulate an obviously capable programmer known as Artelius, for being the first to obtain the solution to the ESEA encrypted text posted earlier this month. Of course, the challenge was not to see if the algorithm can be cracked, but to see how long it takes to start from scratch and hack the encryption, and the initial run of the Encryption Module fell horribly short. In an email, Artelius states that it took him a mere week to research the code, come up with several algorithms to do the job, refine them, write the final C language implementation, and come up with the winning text, running 12,884,901,888 combinations on three different computers simultaneously before achieving his solution. His findings, as well as those of the other testers will be rolled into the final implementation of the Encryption Module, which will support a more random means of generating keys, using a pass phrase to generate a key, and a key length four times that of the preliminary version, as well as more variance on the encryption algorithm. This should make it a tad more difficult to hack, so the challenge isn't over yet!
10/18/08 Yet another module added to the series 2 lineup.
That's right, another feature is added to the mix. This new module, currently known as "ascmath" is a system by which the computer will be able to work with extremely huge numbers. The API accomplishes this by treating numbers as ASCII strings, and mathematically manipulating them one digit at a time, much as one would do if performing the calculation by hand with the good old-fashioned pen-and-paper method. To date, the module supports addition, subtraction, multiplication, finding powers of numbers, all with negative, and floating point numbers as well as the obligatory positive ones. Bugs are being worked out which crop up if mathematics are performed on a negative floating point number, and of course division will be included as well. Upon completion, the current code will be speed optimized before being incorporated into the kernel. The code was found to be spot on under a variety of numerical conditions in recent tests. So much so, in fact, that the preliminary code was used to accurately calculate the total number of possible combinations required to crack the ESEA encryption method's key strength of 512 bits, as mentioned in the news article below.
10/12/08 ESEA remains uncracked.
Here we are, one week after the release of the info on the series 2 kernel's debut encryption technique, and there has yet to be a successful attempt in cracking the message! During this time, however, we have not been resting idly by. The creators of the ESEA technique state that the security of its keys is such that a brute force (trying every possible key in sequence) attempt at a crack would require 256 ^ 64 combinations. How secure is that, you ask? Well, 256 ^ 64 is equivalent to 65,536 ^ 8, or 4,294,967,296 ^ 4. The final implementation of ESEA for Exelyx will support these 512 bit keys, which raises the bar from it's current form to the ESEA standard, which comes out to a very huge number. What? You want to know how huge? What is this, math class? OK, here goes. The expression 4,294,967,296 ^ 16 equates to 13, 407, 807, 929, 942, 597, 099, 574, 024, 998, 205, 846, 127, 479, 365, 820, 592, 393, 377, 723, 561, 443, 721, 764, 030, 073, 546, 976, 801, 874, 298, 166, 903, 427, 690, 031, 858, 186, 486, 050, 853, 753, 882, 811, 946, 569, 946, 433, 649, 006, 084, 096. Seriously. We literally did the math on this one. Which, needless to say, is far beyond the sphere of computational feasibility.
10/05/08 Series 2 kernel to support data encryption- your help is requested!
A new module has been added to the list for the series 2 kernel. The new Encryption Module will enable basic encryption support for any block of data in an XMS handle using the ESEA (Enhanced Security Encryption Algorithm) method. The details were laid out in an introductory cryptography text written by Mercury0x000D:
"Normally when you use a password, the computer just stores it and sees if what you enter next time matches what you told it the password should be. But things would be much more secure if the computer actually encrypted the plaintext data based on the password you enter, morphing it into a different piece of data entirely. So if I have a special message, like THE WORLD IS FLAT, and I have a password, like BOB, the computer could do a mathematical formula on the letters to make a numeric password from it. In this case we'll use the number of letter, so BOB would be 2-15-2. Then we do a formula on the numeric password, so 2-15-2 would maybe become 2 - 15 + 2, which would give us -11, so we strip the sign, and get plain old 11, and 11 in binary is 1011. Next we could rotate the bits left once just to confuse prying eyes further, getting 0111. Now we take the rotated binary sum of the numeric password and get 7, then finally we go through every letter of the message and perform a math function with that letter's number and the password. So THE WORLD IS FLAT might become something like BRW MDPOE VP MUOE. Then, since we have everything down to numbers, we could checksum the final message and give this checksum back to the user. So if you typed in the password BOB, the software would work its magic and give you back a number, like a confirmation password, and you'd need the original password and the number generated by the software to unlock the message. Just to make things harder still, the checksum given back could include other information, like the length of the original message, things only its intended recipient would know. So then I was thinking... what if this still wasn't enough somehow? The software could be set to run the message through encryption several times, making it further from what it originally was each pass through, maybe even using a different password and checksum set each time. We could even perform math on the encrypted message too, and include that information in the checksum also. This method would have no stored password to be discovered by anyone. The message becomes its own password, of sorts. You may think nobody has things on their computer that need that much protection, but what if it's the other way around? Maybe nobody has things on their computer that need that much protection because they know that much protection isn't available. Until now, that is. This could be used down to the file system level, also, so it could not be bypassed. Another thing to consider is the fact that most systems will give you an error if you enter the wrong password and this software will not. So if someone tries to enter a bunch of passwords to guess their way through your security, they'll all simply work just fine, producing garbage if wrong. So yes, the hacker would get a plaintext message, but would be unable to tell if they got the correct one."
Okay, so it's not 1024 bit private key encryption, but it's complex enough to be useful. And to test it out, we are asking for your help. Interested? Here is a message that's been encrypted using a preliminary version of ESEA which does not yet implement password based encryption. The hexadecimal values in the message file represent the bytes of the encrypted data. If you're into cryptography, or know someone who is, and you think this cipher can be cracked without the key being provided, give it a try! We will be listing the results of any successes on the site in the near future, and using this information to further refine the algorithms used. If you need help, here is the source code for this pre-production version of the Cryptographic Module.
10/01/08 New function calling method in series 2.
All of you who have researched the original kernels are probably familiar with the KINT functions. Short for kernel interrupt, these functions comprised the Exelyx API, and will still be included in the series 2 kernel so that previous apps won't break. However, the new kernel will support having its internal functions called directly by a program executing a direct jump to it's code. The functionality for direct address jumping will be accomplished through a new opcode, DJMP. And how will application programmers know where the kernel's routines lie? After all, their internal location will vary widely from version to version. The Exelyx Function Header, a small .asm file that can be included in any program that calls kernel functions, will be created to address this issue. When the compiled app is run, the header's code will execute before the program containing it, at which time it will determine which version of the kernel it's running atop of and set the proper addresses to a set of standard pointers, thereby enabling programmers to only concern themselves with the function labels (actually variables that point to the function's address in base RAM) and bypass the old procedure of calling software interrupts that slow down program execution. If the program is being run on a version of the kernel that does not support direct address jumps (e.g. the entire series 1), it will trigger an error message.
09/18/08 Text Module finished today.
Today one more feature module is added to the downloads, marking one step closer to the series 2 kernel's completion. After performing a (somewhat lengthy) debug on the source (remember, kids, always check for nil handles! :]) the module is available for your review in the Downloads section. The Text Module provides routines for searching strings, returning certain words from text blocks, replacing entire ranges of characters and more. Next up: completion of the Memory Module.
09/15/08 Low memory sluggishness be gone!
The Text Module nears completion, and the Memory Module has seen several improvements, which bears mention of a major new feature announcement for the next release of the Memory Module: VRAM allocation. With this feature in place, the Exelyx kernel will automatically use excess memory on the system's graphics card to function as usable application-accessible RAM. For users with higher-end video cards, that could mean a quite sizeable chunk of extra memory to have available. Also, if anyone finds themselves needing to run programs on a machine with no XMS at all, the kernel will be able to adapt to that, too, by using this feature which is slated to debut in the second release of the series 2 kernel.
09/02/08 Hardware Module finished.
The Hardware Module was completed this week, bringing the overall project development to roughly 40%. It includes mouse support, and some other handy routines for querying the disk drives and such. The source for this module has been made available in the downloads section, along with that of the File Module, which has been done for some time.
08/31/08 First look at a piece of the Kernel 2.00 source code!
There have been several requests for a sneak peek at the innards of the new Exelyx kernel, so beginning today a new section is available in the Downloads area. Right now only the new Display Module code is available, which provides complete VESA support, shape drawing, and pixmap manipulation for the series 2 kernel. As more modules are completed they will be posted in this section, so check it out and get your hands on the latest in Exelyx development!
08/26/08 Kernel series 2 specifications document released.
The past months have seen a host of changes to roll into kernel 2.00, as well as vast progress on the kernel's inner workings. So how do you keep up with all the latest developments without having to sift through the News section all the time? You simply check out the newly released Kernel 2 Series Specifications Document, which is available here.
08/22/08 Text Editing Module announced.
As if there weren't already enough features in the new series 2 kernel to render it superior over its predecessor, now it has been announced that a collection of text editing routines will be included as well. The previous kernel series had nothing of the sort, so this is a welcome addition to the kernel 2.xx plans by developers and users alike.
07/30/08 File Module completed.
The File Module was completed today, and awaits its addition into the series 2 kernel's source. The demo is able to open multiple files, associating each with the thread ID of the process that opened it. When the thread closed, the File Module simply closes all its associated files with a single function call. No error messages, no lost file pointers, nothing of the sort. On a more impressive note, the module created and manipulated assigned drives (e.g. as you would with DOS's subst command) and its most special feature yet- the ability to rename open files. This may sound pointless at first, but its value becomes apparent when you're wanting to rename a file or folder while the system's using it without bringing everything to a grinding halt.
07/17/08 Progress update on the Display Module.
After approximately three months of coding, the Exelyx Display Module is finished! The result? A full-featured, double buffered, fast blitting image machine. Every promised feature in the video category is now a reality, making the visual capabilities of Exelyx rival those "other" operating systems. The testing demo was more than impressive, showing off images loaded from files in three formats (BMP, GIF, and PCX) being scrolled, blitted and color cycled. The time for the image to get from a pile of data on the hard drive to a coherent picture on the screen was decent for PCX files, much better for GIFs, and absolutely phenomenal for BMPs. The demo effortlessly loaded a 45 megabyte uncompressed BMP at 8000x6000 resolution in about seven tenths of a second. It then proceeded to allow the user to scroll about the image, with frame rates topping out at 54 fps at 640x480, 35 fps at 800x600, and 21 fps at 1024x768. The heart of all this is a highly efficient blitter routine which allows Exelyx to manipulate pixmaps entirely in XMS, breezing through millions of pixels per second. Although it currently only supports 8 bit color, future releases of the series 2 kernel will support 16 and 24 bit color as well.
07/03/08 Exelyx background file copying utility announced.
You've seen it mentioned in the Black Ice screenshot. You've wondered what new code powered the multiple operations shown in the Red Delicious pic. And now, brought directly to your computer monitor, is the straight info on the new piece of work known as the Asynchronous Operations Manager. The AOM works by hooking the kernel functions used to copy files and folders, and activating itself only when there's some file operation that needs performed. It is important to note that it does not stay resident in memory, consuming precious CPU cycles while it waits for you to need it. Instead, it uses a new mode of program loading introduced in the kernel 2 series in which a program is loaded, does a job, then terminates but leaves its code still accessible. This is nearly identical to the old DOS method of loading a TSR program, but thanks to the Exelyx kernel's totally protected memory architecture, there aren't any of the hang ups commonly associated with the methods of yore. Ok, now for the real world break down: You're happily using your AOM equipped Exelyx workstation one day, when suddenly you realize that you forgot to do a backup lately. No problem, you think, I'll just do it right now. You drag your documents folder to your backup drive, and a small window pops up indicating that the AOM has sprung into action. No pointless little animations, no perpetually incorrect estimates of exactly how many years it'll be before this procedure's done, just a simple window with a progress bar that begins ticking away as your files are copied to their destination. Suddenly you remember that you need to backup another folder too. Will you have to wait until the current copy operation is completed? What is this, 1983? Of course not! You drag the other folder to its new home, and notice that no new window appears to tell you that the second folder is copying also. Instead, the existing copy progress window is lengthened, and the new copy process is added to it. Clean and simple. Two massive folder copies, two progress bars, one little window. Then you reason, I guess I can delete my old backup folder, so you go to your backups folder, select your old folder, and click delete. Once again, no new window appears, only another line in the existing AOM window. Pleased with the capabilities of your computer, you decide to proceed writing the new BASIC compiler that you intend to contribute to the Exelyx project (hey, give me credit for trying, okay? :D) then you smack yourself on the forehead for forgetting to add the date on the folder you're copying your backup to. Here's one other small detail that would give other operating systems a headache. You navigate to the target folder, and click rename, then add the date. As you hit the enter button, you realize that, since the OS is copying to this folder while you're attempting to rename, you'll probably be greeted by an error message. To your surprise, though, no error window appears, and the system pleasantly accepts your name change. Why? The trusty AOM not only hooks the functions for file copying, but also the renaming functions, so that it can use the new name you specify seamlessly without losing step. Awesome, huh? Yeah, we thought so too.
06/30/08 New windowing environment unveiled.
At last, the Screenshots section has some new pics! Of what, you ask? A new windowing environment whose details were released today. It's called "Black Ice," and not only will it help you get the most out of your computer, just like its namesake implies it'll look pretty slick while it does the job. Most impressive is the new 'open desktop' approach, which leaves your entire monitor virtually free and uncluttered of any menus, task bars, and any other desktop ornaments, save one solitary tab in the upper left corner of the screen. Park your mouse over it for a moment, and it expands outward to show you all currently running tasks, all open windows, the date, time, and other vital stats about your system, such as background tasks and the like, all grouped by classification. Our overall impression... awesome. Even more awesome, it's been scheduled to be included in Exelyx Package 1 upon its release.
06/20/08 Release date of new kernel pushed back.
The long awaited Exelyx kernel version 2.00 is nearing completion, however the brains at Exelyx HQ are pushing back the deadline for release to further test and optimize its internal workings. Changes have also been announced concerning one of the basic capabilities of the new kernel. The first version of kernel 2.00 to be released (now scheduled for an unspecified date in 2009) will be a complete implementation of the kernel, sans multitasking. The reason for doing this is to aid developers who wish to test the basic structure of their applications in a single task environment. Shortly thereafter, version 2.01 will be released in its final form.
04/19/08 Code modules in place in kernel 2.00.
So far, the Hardware Module is completed, which takes care of interacting with the computer's devices. The Display Module is almost complete, only needing some minor tweaks, as are the Memory Module and the Resource Module.
04/12/08 Code execution core opcodes won't change.
It is being announced that the series 2 kernel will support the same opcodes as its predecessors. What this means for developers is that the existing code they have running under the kernel betas will work without modification under the new kernel specification. However, the instruction set will be modified to include new opcodes to support more versatile memory handling and some other features which will result in more efficient and compact code.
04/05/08 Display Module specifications released.
Specs were released today for the kernel 2.00 Display Module. It will support some pretty cool stuff, such as long-promised VESA support, multiple display pages which can be used as a double buffer for smoother scrolling, creating and manipulating pixmaps in XMS or even VM, saving and loading individual palettes, and the ability to save and load BMP, GIF, or PCX images. The ability to load JPG images will be added in a future release of the kernel 2 series, as well as the ability to quickly rotate and zoom pixmaps.
03/28/08 Memory Module near completion.
Work on the Memory Module for kernel 2.00 is almost done. It will now support virtual memory and auto release for all allocated handles. The Memory Module accomplishes this by keeping notes on which threads allocate which handles, and when a thread terminates it only takes the system one simple call to have the Memory Module release all the handles in use by that thread automatically. This approach will help reduce the occurrence of memory leaks and the like.
03/16/08 Details of new kernel released.
Work on the next Exelyx kernel is well underway, and approximately half of the development plan is completed. The Resource Module specs have been determined, as well as those of the new Memory Module and Display Module, complete with a set of functions for drawing lines, circles, loading images from files, pixmap manipulation, and more.
01/15/08 No more betas... the official first release of the kernel announced for next year release!
It's official! The next kernel released for download will be the finished product... the official first release of the Exelyx microkernel. Yes, to answer your question ahead of time, that means that development has proceeded to the point of near completion at Exelyx HQ. Within the next year, the current (and final!) kernel beta is expected to become obsolete, and be replaced with the long anticipated kernel version 2.00, bringing an end to the "Step One" phase of development. An updated version of the kernel technical manual is scheduled to follow the new kernel's release shortly thereafter. This kernel release will incorporate all the features long promised by past betas, will have the beginning of an application development API, and will most likely achieve its target speed of over 200,000 loops per second, as measured by the Speed applet. Currently, the kernel is undergoing further optimization and debugging of the thread execution core, which will be followed by a brief bug testing period. So, in short, the wait is almost over ... the countdown begins today!)
01/03/08 New kernel model announced... the kernel 2 series!
Development of the Exelyx kernel has seen sweeping changes in recent weeks, pressing it far beyond its humble beginnings. The current kernel version is the closest it has come to being a solid work, but at the same time the successive developments rolled into each new beta release have proved its inadequacies. Now is a time for change. With pleasure, we present to you a new design for the official release of the Exelyx kernel, which will allow developers more room for making awesome software for Exelyx. The next release of the Exelyx kernel will utilize this new model, which calls for the addition of floating point and integer registers, expansion of the universal registers already existing in the kernel, improved memory handling, as well as the implementation of several features not yet offered by the current kernel betas, namely fully protected memory, a drastically increased thread limit (breaking the current beta's 32 thread barrier) and virtual memory. Also available will be a fully redesigned code instruction core which will implement a set of new instructions for more efficient code, and optimize thread execution by using a large object code buffer in base RAM to execute hundreds of instructions per cycle, as opposed to the method used by today's betas, which run each instruction out of XMS directly as the thread does its work. This alone should provide even more speed out of the kernel due to the simple elimination of all the overhead incurred by constantly reading instructions out of XMS. One sorely missed feature, however, will be the built-in command prompt, which will be added once again to the project in the future as a stand-alone Exelyx application.
12/20/07 Instabilities found in kernel 1.40.
After a short round of testing, kernel version 1.40 has been found to have problems associated with the call and mov instructions. This is a result of the major modifications to the kernel's inner workings, which allowed it to achieve the phenomenal speeds that it was created to run at. The problems are scheduled to be fixed in the next release, which is expected to be completed soon.
12/16/07 Benchmark results: New kernel version hits record speeds.
The Exelyx kernel may be pretty stable, but speed has historically not been its strongest point... until now. The newest kernel beta, version 1.40, has far surpassed its predecessors, as shown in the following benchmark table. Kernel 1.40 boasts a speed gain of slightly over 75% compared to the previous release. It also weighs in as the largest kernel to date, with over 6,700 lines of source code... that's approximately 91 pages! Moreover, future releases are expected to push the envelope even further, resulting in a kernel that can execute well over 150,000 loops per second. The following results were achieved by running Speed under each kernel version to determine how many loops per second it can process on a mid range PC:
beta version highest average speed
01/20/07 Exelyx goes totally open source with the GNU GPL License!
If you've been following this website for any length of time, you probably already know that the Exelyx project has always been open source when it comes to all applications written for it, but the kernel itself and the PAC compiler have always been closed source. Well, to mass approval, the kernel .zip packages now include the PowerBASIC source code for the kernel itself. Now you, too, can contribute on a deeper level to the Exelyx project... just download the source and have some fun! The move to license the Exelyx Kernel with the GPLv3 provides the general public with a means to get involved with the project and (hopefully!) further its development. The full text of the GPL is now included in every package downloaded from this site, but if you're curious the text of the GNU GPL is also available here at the Free Software Foundation's website.
01/01/07 New look for the Exelyx website.
The web wizards in the Exelyx design group got together one day over lunch and, having exhausted all other valid points for conversation, decided to contemplate revamping this, the project's humble homepage. Yes, they were really, really, really bored. With that said, they hope you like the new, streamlined look which now includes a "Screenshots" section, the best-selling (okay, maybe not quite) Exelyx back-story, and this wonderful new "News!" area, among others.
12/15/06 PBASIC compiler under development.
Due to slow progress of someone completing a BASIC compiler, I have decided to finally resume development of mine. While not much has been done yet on it, progress is being made, so feel free to download it and see what you think and/or contribute your ideas and efforts to it.