jWinLib: Forcing Elegance upon Windows code
Last Update: 3/21/2004
Quick Update:
Erm ... I recently found an awesome, awesome tool already in beta that does nearly the same thing we are
attempting to create ... we will be examining this library carefully to see if it can give us a head start on the
directx section, thereby changing our purpose to working mainly with wrapping directx calls.
(We don't need to wrap opengl calls, since opengl is a lot easier to work with than DirectX !)
In the meantime, I suggest that you visit the link above and give them a try, if you were hoping
for a more complete project.
Purpose:
This Project will take the Windows API calls for making and manipulating windows, window components,threads and
critical sections, device contexts, and certain directx calls, and wrap them into java-like C++ wrapper classes.
In general, we will be making wrapper classes that contain default values and methods/member functions that allow
for tweaking individual aspects to be done upon object creation, instead of Windows' original functions, which typically
include all component settings as parameters in single functions, which creates messy and hard-to-read code.
Personally, some of the programmers for NukeCD will be using this code for future projects as it will provide maximum
simplicity and compatability. We will attempt to follow the Java API Documentation faithfully ... although much
thought will be put into the use of throwing exceptions.
But why not just use Java or DotNet ?
Both Java and DotNet still require that each of your clients download their runtime components,
either the Java Virtual Machine, or the DotNet Common Language Runtime (Not including DotNet Web Services),
which is a hefty, hefty download for those of us without fast internet connections - And it's still a bit of
an annoyance with the scaled down CLR framework. By implementing java's window code and graphics code in C++
and Windows API calls, we hope to make using the older Windows COM and API calls a bit less frightening, and
far more readable, as well as create a niche for it in allowing for 'baggage-free' executables to be downloaded
and executed with no extra steps in between.
For this reason, Java's window code and graphics code were decided upon because of its popularity and similarity
to C# -- this way, Java programmers can get introduced to Windows API calls, and veteran Windows programmers can
clean up their code more significantly than before.
Long Term Goals?
As stated above, we hope to create a niche for the Windows API functions in allowing for 'baggage-free' executables to be downloaded
and executed with no extra steps in between.
Also, depending on the usefulness and success of this project, we may continue to write several more wrapper classes
for other COM components: essentially writing a barebones DotNet framework on top of COM without the DotNet.
We are also considering a continuation along this line for linux/x11/gui components