Windows, native coding and EZGUI !
So what does EZGUI have to do with native coding ?
It has taken me years to become proficient using the Windows API (Win32). The PowerBasic compiler combined with native coding using the Windows API has produced some amazing results, IMO. EZGUI 5.0 is the product of all these years of learning the Windows API.
The PowerBasic compiler can produce extremely small and fast applications. The problem though is that such native coding requires a good working knowledge of the Windows API and that is not easy. Likely Microsoft created MFC (Microsoft Foundation Classes) early on because working with the Windows API was not easy. The idea was to create a higher level framework to make developing applications easier. Obviously MFC wasn’t enough, because other frameworks were later developed. Today the dot.net frameworks are there to make programming easier and more rich, which they may do so, but the problem is that these frameworks are huge in size and resource hungry. Programmers like to use the term “bloated”.
I can understand why a framework may have some size to it, but why are the dot.net frameworks so huge ? I don’t know the answer, but I would venture a guess. OOP possibly ? It is interesting that as OOP (Object Oriented Programming) took hold in the programming world, the size of applications appear to have grown. At least the dot.net framework is huge and it is the epitome of OOP.
I don’t see what all the hype is about when it comes to OOP. Personally I find procedural style coding easier and more productive. Thats why I like Powerbasic. Now you can do some OOP with PowerBasic 10, but for me it (OOP) has no appeal. Why ?
I have had about ten years to see what one can do with procedural style coding and the Windows API (avoiding COM at all costs too) and guess what ? I have found that I can create software with an amazingly small footprint which also runs fast. Now I do see the benefits of a higher level GUI framework to make programming easier, since using the pure Windows API is slow going and complex. But does such a framework have to be huge and resource hungry like dot.net ?
I don’t think so. EZGUI 5.0 well demonstrates this. Now remember, that I am a lone programmer compared to the say the teams of programmers available to Microsoft. But if a lone programmer like me can develop a powerful GUI framework with the small footprint EZGUI has, then shouldn’t the big software companies be able to do so ? So what makes my software development different than the mainstream ?
The only things I can see are this:
(1) I use PowerBasic, a native code compiler. It compiles fast. It compiles to small and fast executables. The language is rich. The language is BASIC ! (Which I think is an advantage over C++).
(2) I write code using procedural style coding (using the Windows API) rather than OOP (Object Oriented Programming). I stay away from COM (which only adds extra overhead) and I stay away from classes (OOP). My idea of an external component is aDLL and thats it. I avoid ActiveX controls.
(3) Procedural code can be modular and try to reuse code as much as is possible. Us old time procedural coders use to call them “Libraries” (just kidding). OOP does not have the monopoly on code reusability. Procedural coding IMO can be even more efficient than OOP in code reusability.
(4) I avoid the dot.net framework and use low level API’s.
(5) I made the choice to build my owm GUI Framework (library) so I can shield myself from the Windows API as much as possible. The idea of a GUI framework is a good one. It is just the implimentation that can be a problem. So how well did I do ?
Consider this.
If I list just some of the major features of my GUI engine (EZGUI 5.0), consider that if you were asked to build such a GUI engine (framework) and the goal was to make it possible for a programmer to be able to build complex Windows applications using any or all of these features using this framework, but to never have to resort to using the Windows API , first could your do it and second how big would this framework have to be ?
Well let’s look at EZGUI 5.0 and some of its features:
– Complete Form creation engine with support for all the standard controls and their most common tasks.
– support for the majority of the Common Controls and their most common tasks.
– support for the RichEdit control and its most common tasks
– support for the common dialogs
– support for menus and right click menus
– event engine which converts window messages into easy to use events
Ok, that sounds like a lot so far. How big do you think it would have to be ?
The old Visual basic (5.0/6.0) had a 1.4 meg runtime and to have access to the common controls and common dialogs would require additional OCX controls which could add up to a total of a couple meg (possible 3 meg). So maybe you might say, yes it could be done with a 3 meg runtime.
Well, I am not done yet.
Most applications need to be able to print to the printer, so we need a decent print engine and while we are at it we need to have a Graphics engine for basic drawing. You might say, Visual basic could do much of that, so not a big deal.
To make things interesting, lets assume the default look and feel of controls won’t suffice, so maybe we would like to be able to do some customizing of the controls. In the Windows API this is referred to as ownerdraw. Now as far as I know, Visual basic does not do this. Some aspects of customization may require subclassing, so that would be necessary. Now EZGUI 5.0 has a built in ownerdraw and custom draw engine for advanced customizing of controls and even the common dialogs. This requires a bit more complex graphics engine, not just for printing, but also for drawing into controls for customizing. So how big does the GUI engine or framework need to be now ? Maybe 4 meg in size ? Maybe larger ?
Not done yet !
Not enough. Maybe we need a more advanced Canvas control to work with. It is not enough just to be able to draw lines, icons or bitmaps. Maybe we would like to be able to draw bitmaps and rotate them up to 360 degrees. Maybe we would like to draw them using some kind of image filter (ie. convert color to grayscale or black and white). Maybe we would like to be able to draw lines, icons, bitmaps, etc using visual effects (like alphablending and anti-aliasing). Ok, maybe we can push the envelope a little. How about a complte DIB engine so you can work at the pixel level directly so you can do all sorts of manipulation (ie. write your own image filters) ? How about a proprietary (not built into the Windows API) 2D sprite engine so you can have movable (non-rectangular) objects in front of the background image so you can animate your Canvas ?
What is this going to cost us in size for our GUI framework ? Now are you imagining it getting to be 5 or 6 meg in size, maybe bigger ?
Now done yet.
Maybe we would like to add a Thread engine so it would be easier to write worker threads to make an application more fluid. Maybe we need some kind of syncronization such as critical sections. Maybe we need a way for the worker threads to be able to communicate with the primary GUI thread (all GUI tasks should be handled by the primary thread). Ok, how about adding game loop support for maximum use of the CPU ? How about precision timing ?
So how big is our framework now ?
Well, let’s add some more stuff. How about support for Themes, so when we customize controls we cal draw either using themes or the GDI depending upon whether themes are available ? We just need some of the basics, but at least some theme drawing. We also need to make the application capable of being able to run on legacy operating systems such as Windows 95/98/ME while when run on more current operating systems dynamically loading features of the Windows API we may need.
Now let’s not forget all those little things, like Task bar icons (some call them tray icons), displaying Help files either hlp or chm (HTML help) files and the basic image loading routines for icons, imagelists , cursors and bitmaps.
Now how big will our GUI engine be ?
Ok, now you have my imagination running! Why not get a little bit creative ? Why not add some unique controls, not found in the Windows API. Yes, how about a few custom controls. Now we don’t want to load a bunch of custom controls from OCX files either. We want most of these controls in our primary runtime and if necessary a few can be in secondary DLL’s. So we already have our Canvas control with sprite engine, how some others such as a MCI control (makes MCI easy), masked Edit control, Turtle Graphic control (vector graphics using a 2D scripting language), shape/hotspot/splitterbar control and even 3D Button control (real colored buttons). Oh you are saying this framework is going to be many megabytes in size for all of this ! All those custom controls just adds significant size. Sorry, I forgot two other custom controls to add. How about a Files Listbox control and a real Property Listbox control. Everybody could use those. Now this is going too far you may say.
So how big is our GUI framework going to be now ? It is going to have to be 10 meg or more. Now this is sounding more like dot.net isn’t it ? Maybe not.
Just to make it fun, why don’t we add more than just 2D Graphics. Why don’t we just add another custom control, but one which does 3D ? Yes 3D. Now opengl is well suited to building a custom 3D control, more so than DirectX, so let’s just create a GLCanvas control which can do everything our Canvas control can do, but add a 3D layer on top to display 3D objects which can be fully animated, rotated, scaled, stretched etc. Now 3D can be a bit complex, so why not add a proprietary 3D scripting language so the programmer does not need to be able to know any OpenGL. We will throw in the ability to define simple 3D primitives using simple scripting. Also we will add the ability to load huge STL format 3D files so we can display complex 3D models with thousands of polygons, maybe even a million (if you have a dcent vide card).
Ok, I just went over the line, right ? Now I want 3D animation using OpenGL ? Not as full screen, but as a custom control so I can have multiple OpenGL windows at one time on a form. That is going to cost in size of our GUI engine, you may say. Why not add another 5 meg to the framework just for all the OpenGl stuff and scripting language ?
Well, I am not finished yet. You know, any GUI engine could benefit from drag and drop design, so why not add the ability to create WYSIWYG style applications using this framework. I mean, the ability ti build your own drag and drop Visual Designer using it so you don’t have to call a single Windows API. Now maybe we can make it easier too, by adding a subclassing engine just for handling drag and drop, so it will work with any control, even third party ones (in DLL form only of course). Now how do you do that fancy drag rectangle stuff ? Let’s add that too. How do you do those little drag handles used for drag and drop ? Let’s add that too. Yes, now we have a true drag and drop engine so anyone can build their own Visual Designer. This is hard stuff to do. Have you noticed that a number of independent developers have created their own programming languages today ? Yes, you can download all sorts of interesting independently developed compilers. One thing I have noticed though is that many of them don’t have a visual designer or the ones they do provide are terribly poor in design. Maybe it is just really difficult to build a visual designer. Actually, yes it is. So why not add this ability to our GUI framework, so it won’t be difficult anymore.
Ok, now you have done it, you may say to me. What are you trying to do ? Rewrite Windows ? No. I just want a GUI engine to be able to do many of the things we have seen done in Windows over the years. I know it is possible. Microsoft can build a visual designer, so why shouldn’t I be able to do so ?
Well, am I done now ? Not quite. Just to play it safe, I want to add just a few more little items before I am done. So here is my list of stuff not to forget:
I want to also add a superclassing engine so I can build upon existing controls to create new ones. How about also the ability to design forms which are not rectangular but use a complex region generated on the fly using a background bitmap ? I want the ability to read directly from the screen (Window DC’s) and to draw to it. I want the ability to copy any window or the desktop of a bitmap. I want a layer engine (kind of like what graphic apps do), but for use with controls, so I can show and hide controls in groups. I want to be able to store and retrieve data from the Registry. I need multiple monitor support. I need access to the clipboard. I need to be able to find all sorts of resources like all the installed fonts or the graphics in a DLL or EXE. And to finish it all up, how about plenty of ways to have low level access to this “black box” so I can override how it does things when I need to.
Lastly, all this needs to be in a complete framework so I don’t have to resort to the Windows API. All I want is to call the framework and let it do all the work.
So how big is this bloated framework going to be ? How big would it be if you developed it using your current programming tools ?
Guess what ? This framework already exists. It is called EZGUI 5.0 and it can run on all versions of Windows from Windows 95 to Windows 8. When it runs on later versions of Windows it dynamically loads features only found on them. EZGUI 5.0 was written using PowerBasic 9.3 using native code. Programmers who use EZGUI can use any version of PowerBasic from 6.0 to 10 and most of the time they do not need any knowledge of the Windows API. EZGUI is a true GUI framework. If you want to you can though integrate new native code with EZGUI applications in the rare case it does not do what you require.
So what is this going to cost me, in size ?
Not 20 megabytes !
Not 15 megabytes !
Not 10 megabytes !
Not even 5 megabytes !
How about all of this in a runtime (a couple of DLL’s) which is about 1 megabyte in size !
All of this was done using native coding, procedural style coding and the Powerbasic compiler.