News!
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
1.33
64,559
1.34
65,462
1.35
80,389
1.40 142,077
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.