Friday, 19 of December of 2014

EZGUI, the missing part to PowerBasic

Having used PowerBasic for a good 15 years now, I think I have a good feel of the strengths and weaknesses of the compiler. I started programming with PowerBasic (version 5.0) before the compiler implimented any GUI features, which is why I created EZGUI in the first place. When PowerBasic first added the GUI command set (called DDT or Dynamic Dialog Tools), I questioned myself about whether this would make EZGUI obsolete. It did not take long to realize that the compilers GUI command set would not make EZGUI obsolete, but instead it demonstrated how far ahead EZGUI was (and would continue to be) as far as GUI features are concerned.

The EZGUI 1.0 version predated the first PowerBasic compiler (6.0) with DDT, by a year or two and PowerBasic’s PB Forms came out some time after PowerBasic 6.0 did. PowerBasic’s first compiler with GUI features only supported the standard Windows controls and none of the common controls or even the common dialogs. EZGUI 1.0 not only supported the standard controls, but also supported a number of the common controls such as the Toolbar, Tab control, ProgressBar, UpDown control and Tooltips. It also supported a number of the common dialogs, such as fonts, colors and file dialogs. EZGUI 1.0 had a number of proprietary engines in it, such as its Layer engine and Drag and Drop engine (for building visual designers). EZGUI came with its own visual designer/code generator, while it was a year or so after Powerbasic 6.0 was released that they released the first PB Forms visual designer.

Now it is true that PowerBasic always supported coding directly using the Windows API (often refered to as SDK style coding), but coding using the WIN32 API is quite difficult and it takes a long time to learn to become proficient with it. I am a WIN32 programmer and I know how much effort it takes to become proficient with it. Most modern programming languages do not resort to using the WIN32 API for doing GUI tasks, but they normally provide some kind of high level GUI command set or framework. This is what PowerBasic always needed. Its DDT command set, while sufficient for typical usage, lacks important features when one wants to build a more complex user interface which takes advantage of some of the more powerful features in Windows. From its first compiler with the DDT command set, PowerBasic has continually added more and more GUI features (versions 6.0 to 10).  For each new version of PowerBasic, there is also a similar new version of EZGUI Professional  (1.0 to 5.0) and in each version, once again EZGUI was years ahead of the compiler when it comes to GUI features.

PowerBasic, an excellent compiler

PowerBasic is an excellent compiler, despite any lacks it may have had. The compiler is fast (compile speed) and produces amazingly small executables which are also perform very well. It is comparable to any C compiler in performance. One thing which always struck me about PowerBasic, was how reliable it was. When they added new features to the compiler, they worked and they worked well, that one could be sure of. Reliability has always been one of my priorities when it comes to software development. The language is also very rich in all the low level stuff and general commands. It has one of the best string engines in the industry (it uses OLE for handling variable length string data types, which most compilers do not). No other BASIC compiler, that I know of, comes close to the richness of the language, especially in how it handles data types, like strings. For a WIN32 programmer, PowerBasic is rich with features for low level coding, with things like code and data pointers, embeded arrays (embed an array into any memory location, even a string) and even different calling methods for subroutines and functions. It also has an inline assembler for those who need really low level.

Here are some past blog posts where I talk about why I like PowerBasic:

PowerBasic, worth the investment

The PowerBasic advantage

PowerBasic, why ?


EZGUI, the missing part of the compiler

EZGUI is what is missing in the compiler. Yes, you can code user interfaces using the DDT command set in the compiler, but you will quickly find that you most likely will have to resort to the WIN32 API for a number of things. You could also simply write your application just using the WIN32 API, but the average programmer today usually lacks enough experience with the low level WIN32 API or they may simply find that even with the necessary experience it is a very slow process writing applications that way.

EZGUI, is more than just some extra GUI commands. It is a GUI framework specifically designed for use with PowerBasic. EZGUI 5.0 Professional (current version) was written using PowerBasic 9.0. It is the integration of features into a single GUI framework which gives EZGUI its power and features. The EZGUI engine takes advantage of some of its own features to build even higher level features. For example, two custom controls in EZGUI, the Files Listbox and Property Listbox controls, are hybrid controls. They are superclasses of the listbox class, but they also are ownerdraw and EZGUI uses its ownerdraw engine to impliment the visual look of the controls. EZGUI uses its own graphic engine for drawing the controls.

EZGUI has a number of proprietary engines, you not only won’t find in the PowerBasic compile but, you won’t find in the Windows WIN32 API. For example its Layer engine, allows one to easily work with Tab controls or build Wizard style dialogs without the need for child forms. Layers make designing such interfaces easy visually in the designer. The layer engine is one of the most popular features of EZGUI and no other visual designer for PowerBasic provides a similar feature (as far as I know). I don’t think I have ever seen a similar feature in other BASIC programming languages. EZGUI also has its own proprietary Canvas control. Unlike PowerBasic’s graphic control, which is only an ownerdraw STATIC control, EZGUI’s Canvas control is a high level custom control I wrote from scratch. I wrote a graphic command set for it and also designed it to use double buffers and DIB buffers so you cna have direct access to the pixel data. But the most powerful feature of the Canvas control is its proprietary 2D Sprite engine, which even has alphablending and anti-aliasing. It was designed for speed and while it does not use DirectX, it performs quite well. Its 100% software based design (rather than hardware support) makes it compatible with most versions of Windows, from Windows 95 to Windows 10, and even works well on Linux using WINE.

But the real power of EZGUI is how it taps into many of the low level customization features in Windows. For example, PowerBasic’s DDT can display an Open File dialog simply enough, but EZGUI allows you to customize the dialog and change its controls and even add a child form to the dialog. EZGUI taps into the low level “hook” features of many of the WIN32 API’s so it can provide customization features. Even with controls, EZGUI subclasses every control so it can add features to it via a low level subclass engine. EZGUI also taps into important features of later versions of Windows such as multi-monitor support, theme support (you can draw in ownerdraw using some theme effects).

EZGUI even goes beyond the compiler, by implimenting similar features in a better way. For example, PowerBasic supports defining Thread functions, but EZGUI provides mechanisms which can improve Thread functions and it even impliments its own, easier to use Thread engine which even support syncronization using Critical Sections. Syncronization is important to make Threads play well with each other. EZGUI also follows the rule of “Threads only for non-GUI tasks” and doing all GUI tasks in the primary thread (the main thread of the applications process). This is something I learned from an excellent book on how to properly use threads in Windows.

Want to learn more about what makes EZGUI different ?

Here are some blog posts where I discuss more about what makes EZGUI different and how it can benefit programmers:

EZGUI, compared to Visual Basic

Why I created EZGUI

Why EZGUI ? (why use it)

EZGUI, the backend to some important industry software


Windows devices getting smaller and the Internet of Things

The coming “Internet of Things” means smaller and smaller Windows capable (x86) devices are coming. Right now, 7 inch Windows tablets are available for only $99. But such devices may have limited memory, limited disk space and even limited CPU performance. So how does one build applications which thrive on such minimal hardware ?

Combine PowerBasic with the EZGUI framework and you have a powerful combination. PowerBasic produces very tiny applications which perform very well. EZGUI is one of the tiniest GUI frameworks around. It does many high level things like 2D sprites, 3D graphics (OpenGL based) and more, but the entire GUI framework only takes up about 1 megabyte of disk space. This means it also takes up less RAM when loaded into memory (DLL’s are loaded in memory). EZGUI was designed so it can run even on legacy PC’s with 1/4 of the resources of the least powerful PC (or tablet) found today. It can thrive on minimal hardware.

So EZGUI makes a great tool for those interested in building applications for small Windows tablets and GUI capable Internet of Things devices.

Here are some blog posts about how EZGUI benefits developers for such devices:

EZGUI, the solution to bloatware

EZGUI and small tablets

How to develop for minimal hardware


EZGUI is now priced at a more affordable price !

EZGUI 5.0 normally sells for $249 and in my opinion it is worth every penny. But for a limited time, you can purchase EZGUI for only $99 . If you already own a previous version of EZGUI you upgrade now for only $49 (limited time offer).

If you are not a PowerBasic user, then consider buying the PowerBasic compiler and then add EZGUi to your toolbox for this low price. Now most new users of PowerBasic probably prefer the latest compiler, which currently sells for $199. The typical PowerBasic user also tends to use the built in DDT command set, so they likely will also purchase the PB Forms designer (a PowerBasic product) for an extra $99, for a total of $298.  EZGUI though has all the GUI features of latest compiler and much more, so you can save money by purchasing the Classic PowerBasic for Windows compiler (which is simply their previous version) for only $99 and then purchase EZGUI on sale for only $99 and save.












Comments Off

IOT, makers and Windows

It is exciting to see all the new computing devices that are being released in 2014. The latest Raspberry PI A+ device is a full PC motherboard at only $20 and is even smaller than its previous versions. In the 3D printing world, tiny computing devices have made it possible for the “maker” (those who like to make things from scratch) world to build all sorts of affordable 3D printers. The coming Internet of Things (IOT) depends upon creative people building inexpensive computing devices with a tiny footprint which can be embedded in small areas of common objects used in everyday life.

While I am not personally a fan of simply building such devices, simply for the sake of the latest fad, likely there are some real world and practical applications for such devices. In the business world there are endless uses possible. In the medical world, affordable technology can have many benefits. So from a practical point of view, the Internet of Things, could have some real world benefits.

But to be truly useful, such devices need to be in the hands of more than simply the technology geniuses of the world. Technology needs to be in the hands of the common person who can see ways to use it in everyday life. A farmer who comes up with a practical idea which could prove useful on the job is more likely to produce something truly useful to others than the highly trained computer programmer sitting in the back room. Why ? Because, the Internet of Things is not about producing some fancy gadget which pushes the limits of technology which impresses people, while at the same time ends up being, simply put, totally impractical for everyday life.  While scanning the internet (the web) to see what others are doing with these amazing prototyping computing devices, does not one often walk away with the sense that much of it is simply useless. Consumers get excited about some fancy computing device on a watch, which does little more than check your pulse or some other body function, which costs many hundreds of dollars, but often is impractical because the price is beyond the average person and its benefits are too little for the expense. True, there will always be people who are willing to throw away their money for the latest gadget, but as a computer programmer who spent years writing custom software for local businesses, to me it only makes sense to build things which are more useful and at an affordable price.

Where really useful ideas come from

Good ideas often come out of necessity, rather than from the science lab or computing lab.  For example,  in the programming world, most software is built using the latest scripting language or C++ compiler, which for the average person is so complex, that even those who write the code when they come back months or years later find it difficult to read their own code. Programming languages today are not designed for the typical person, but for a different mindset. One programming language (in different variants over the years) which though was designed for the average person, is BASIC. How many people have learned to program by being self taught, did so using BASIC ? Many ! But it gets better. Consider one of the most popular programming languages ever, classic Visual Basic. Why did it succeed far beyond the expectations of its developers ? Visual Basic was not originally developed by Microsoft, but they purchased it from another company (was not Visual Basic at first) and then turned it into what we today know as classic Visual Basic. My impression of this is that likely Microsoft did not plan on Visual Basic being a professional programming language. Yet, in the long run, classic Visual Basic became extremely popular and many a commercial application was written in it. But why ?

The real inventors of software, have often not been classically trained programmers, but self taught programmers who simply needed a solution for their business or job. They knew their job well and understood what was needed and because classic Visual Basic (especially the early versions) was so easy to learn, they could build a custom solution to their problem. Classic Visual Basic, in particular versions 1.0 and 2.0, were very affordable too, which made it a tool which the average person could afford. They became “makers” in the true sense of the word. The coming Internet of Things needs something similar today. The two elements needed to promote more “makers” today are easy to use programming tools and low cost tools (software and the prototyping devices).

The really good ideas likely will come from such common place “makers”, rather than the elite programming world. Call it “real world Agile programming” or common people solving common problems they face day to day. Such “makers” need to be able to quickly build solutions, but easily and using affordable resources (both the hardware and the software tools).

IOT and the Windows world

Classic Visual Basic eventually became overly complex and also expensive (its PRO versions in later iterations). It also lost much of its roots of simplicity, when VB.NET later turned programming upside down and it lost much of is appeal to the common person, the real “makers” in the software world.  Windows was left behind in the maker world too, being a costly operating system (if purchased separately) and the smaller a Windows device became the more expensive it became. Windows programming languages (aka. or managed languages) lost qualities such as ease of use as well as performance on minimal hardware. If you are programmer, be honest here. When it comes to your favorite development PC, would you be satisfied with anything less than the latest ICore CPU with huge amounts of RAM and the fastest disk drive (ie. SSD) you can get ? Likely not. So working with managed languages may be fine for you and productive, but what about the common man (or women) ? What about the real “makers” in the world ?  Should they not be able to write code using something which is simple, easy to use and affordable, including the hardware it runs on ?

In the past Windows was not the most “maker” friendly of operating systems and the hardware it ran on wasn’t either. But this is changing and quite rapidly.  Let’s consider some of those changes and also some of the things going on in the “maker” or “hobby” side of the Windows world. Let’s first consider software. BASIC has not died. Just scan the web for different variants of BASIC and one will quickly see that no matter how many BASIC languages disappear, more replace them. In the hobby world of programming BASIC still remains a favorite. Even some experienced professional programmers, like myself, still prefer BASIC. In my case I write low level WIN32 code using BASIC, so it can still appeal to a professional, but there are many variants of BASIC for Windows with a higher level command set which even the common person, self taught, can use to build all sorts of software.

But the biggest changes now have to do with Windows (the operating system) and the devices it can run on. First, consider Windows. Despite all the layers put on top of Windows, such as DOT.NET and WINRT, Windows still maintains its core, the WIN32. While I don’t expect the common person, the real “makers” to start coding in WIN32 style, there are experienced developers who are creating frameworks and programming languages which tap into that core WIN32 API, but in a much more friendly form, such as BASIC programming languages. One example, is a BASIC scripting language which has brought back the excitement for hobby programmers, which is called ThinBasic. ThinBasic, like many BASIC’s of the past appeals to hobby programmers, yet provides many higher level features. It was written in PowerBasic (WIN32 style), so the core scripting language has decent performance, even though it is a scripting language, yet it does not require a lot of hardware resources to run, so it is well fitted to tiny Windows devices with minimal hardware. If a hobby programmer finds they need more power, as they gain experience, they can easily move to a more powerful compiler like PowerBasic (which ThinBasic is patterned after, as well as written in). The core WIN32 API of Windows has not changed much over the years and Windows has a core engine, well suited to tiny devices and the Internet of Things.

The big change in Windows is the price. With Microsofts efforts to make Windows either free or very inexpensive for low cost devices or devices small in size, the hardware is now coming down in price and more and more tiny prototyping devices, even full blown computers such as tablets are becoming available. Intels efforts with the Edison and Galileo devices is good, but what really is needed is more efforts with devices which have full PC capabilities, like the Raspberry PI computer, but in a tiny form factor and affordable. One such effort is the MinnowBoard. This is the right direction, but I think more is needed. While the price is somewhat affordable at $99 now (original version was $199), it still needs to come down even more. The $50 range, or less, is a better target. But what is still missing is easier ways to code such devices, which the average person can learn. This is why making such devices capable of running a full version of Windows is so important, as well as they being provided the free version of Windows right in the package. Once the price point is met, with a full version of Windows (if you can buy a $99 Windows tablet now, surely these mini-computers can be manufactured for $50 and come with Windows) all sorts of possibilities arise.. Things are going in the right direction currently, but we are not there yet.

But some more is needed to make Windows the operating system of choice for the Internet of Things and to spur on development. The size of these tiny PC’s needs to get smaller and follow the path set by the Raspberry PI. The new Raspberry PI A+ is only about 2.2  x  2.5  inches in size. Now that is small. The price is only $20 too! Now when we get Windows devices that small, running real Windows, then we have something.  But another key to Windows becoming the operating system of choice for the average “maker” (not just tech geniuses) is building software. is not well suited to minimum hardware, so maybe a downsized version of or WINRT would be helpful. But the real power in Windows is the core WIN32 API and while professional programmers can use the WIN32 API directly, easy to use programming languages, much like the BASIC flavor, which don’t require, but tap into the raw WIN32 API, could make a big difference. Rather than C like languages, simpler languages, with features specific to the Internet of Things, more like BASIC would provide the tools for the real “makers” , the everyday person who simply wants to build a solution to a real world problem. The success of classic Visual Basic demonstrates that this is practical. How about a new Visual Basic, just for tiny Windows based Internet of Things devices. If Microsoft came out first with something like this, it would take all the other platforms years to catch up. With Windows being free (or low cost) for this effort, Intel’s efforts with miniaturizing the PC and easy to use languages, like BASIC adding IOT specific features, then you have something. Maybe something really practical could come out of this. Real people working on the job could become the next generation of “makers” of practical IOT devices.



Comments Off

IOT and Windows – what is needed, a lesson from the past

The exciting Internet of Things is the next frontier for programmers. Most interesting is the possiblity of Windows running such devices. But what is need to make this possible ? Is a shift in mindset needed to make this possible ?

A lesson from the past

Programmers who got their start back in the 1970’s and 80’s remember what it was like to write software for computers with very little raw power.  It amazes me how the current mini-devices like the Raspberry PI and in the Windows world the existing x86 mini-PC devices seem so underpowered and it is a wonder why they don’t perform better. In considering this, an old time programmer may come to a number of conclusions.

In the old days, the key to performance in computers was the software and even the operating systems (past home some computers didn’t have a full operating system in the same way they do today, but simply supported basic input and output via direct hardware access). Let’s consider one example that demonstrates how powerful even limited hardware can be with the right software.

How any computer device today with a CPU (or SOC , System on a Chip) running at 1 gigahertz or better can have a problem with performance boggles the mind. Consider a home computer from the past, the Commodore 64 (C64). The C64 was a powerful little computer back in the day. Its CPU ran a blistering 1 megahertz (that is megahertz, not gigahertz). Ok, I am using some humor here. By todays standard one would not refer to 1 megahertz as blistering (fast). Yet back in the old days, some programmers felt that such a computer was capable of much more than most would think. C64 users likely remember how slow interprted BASIC was on those machines. It was “turtle slow” be correct. But programmers back then found that when they learned how to write software using a real native code compiler or even by using machine language they could make that turtle slow computer do some amazing things. Personally, I started using the Abacus BASIC 64 compiler which was a huge improvement. One could actually write software with some decent performance. Using that compiler, I then wrote my own mini-compiler with a limited command set so I could write code which would perform closer to assembly language speeds. My mini-BASIC compiler generated machine code directly (no assembler in the middle). I quickly found out that how you write software makes a big difference. Using my mini-compiler I wrote a family friendly video game and sold it to Compute Gazette magazine, earning myself $1500 for just a few weeks work, which was not bad for a self taught hobby programmer back in the late 1980’s.

Some amazing programmers, likely using assembler to code, built an amazing operating system for the Commodore 64, called Geos. Geos turned the Commodore 64 into a Macintosh (Apple) like computer (which cost 4 times as much and has 8 times the speed as the C64). Berkeley Softworks, which created Geos pushed the limits of the C64 far beyond what even its manufacturer (Commodore) ever considered. All of this on a computer with a 1 megahertz CPU, 64 kilobytes of ram and an external disk drive with only 170 kilobytes of disk space.

The lesson learned ? Software written using native code compilers and which are closer to the hardware can perform at amazing speeds. How you write software makes a difference.

The Windows world

In the early years of 32 bit Windows (Windows 95), a typical PC likely was only using a CPU which ran at 100 megahertz or better, likely with less than 24 megabytes of ram. Compared to todays PC’s (ie. 1.5 ghz CPU, 2 gig ram) this would be nothing. Most current software for Windows likely could not run on hardware with so little power. Now consider some of the mini-PC, hobby prototyping devices which are now coming out which are x86 based. In the ARM world the Raspberry PI has been a big successful among hobbiests. In the x86 world devices like the Intel Galileo, MinnowBoard and SharksCove are being offered, but at prices still a bit too high for the typical hobbiest. While I do think they need to get the prices down for such devices to the $50 range and add in the free version of Windows 8.1 now being offered OEMs building tablets to make a complete package, the real challenge will be writing software for these devices which push them to their limits.

As a programmer I have been looking at such devices with excitement, but two barriers still exist which I feel need to be addressed. First, is as mentioned, price. To be compariable to the Raspberry PI and to be affordable so they can be the basis of the coming “Internet of Things” devices the price needs to come way down, even if it means less raw power (CPU, memory, etc.) in the hardware. Manufacturers of such devices are still thinking with the Windows PC mindset so the hardware specs are probably too high, which may explain the higher costs than ARM devices. With the next generation of small Windows tablets (7 inch) coming out selling at $100, surely a prototyping, hobby mini computer device could be built for much less. Second, Windows needs to be sheared down a bit to make it more practical for smaller devices, yet with full user interface features. Now some may think that will be difficult. The typical Windows PC is so over powered today, yet most don’t realize it. Why ? Because of how software is written today. So how could Windows be pared down to make it more friendly to the coming Internet of Things ?

Get rid of all managed language engines in the operating system. Get rid of Get rid of WINRT. Leave just the core WIN32 API. This would decrease the overhead needed hardware wise. This would make Windows better suited to use on “tiny, tiny” devices. Target smaller screen sizes with resolutions as low as 1024 x 600 (even if you have to fake it like the Toshiba mini tablet does, making Windows think the display is larger than it is). The Windows API is a very, very lean and fast API. The core API likely requires a lot less memory and CPU speed than does the full blown operating system today.

Now at first glance, one might think this would seriously limit Windows development, but I would be more inclined to think that like the Commodore 64 and Geos, developers would learn how to tap into the raw power of Windows and they would find ways to push the limits of even minimal hardware. If Microsoft wants to put Windows everywhere (meaning devices in all areas of life), then the mindset towards Windows needs to be changed.

Not possible, some would say

Some might say, nice ideas but it simply is not possible , nor practical. I would beg to differ though and I have good reason. Unlike most Windows developers today, using managed languages via Visual Studio, for the last 15 years my company has been primarily using simple native code compilers and the raw WIN32 API. Likely because of my past experience in the “old days” of computing, back in the 1980’s, I purposely worked with older, legacy, computers for actual everyday software development so as to force myself to get used to minimal hardware. For example, back when Windows XP was the current Windows, I instead did most of my development on a 233 mhz computer running Windows 95, instead of Windows XP. I did supe it up a bit with 256 meg ram (a lot for Win95) , but it was still only a 233 mhz CPU. I would develop my software on this PC and then test it on a more current PC. By forcing myself to get use to less hardware resources, it helped me learn how to write software which performed well no matter the hardware. Amazingly the raw WIN32 API was well suited to this and it was designed for raw performance.

Also I found that software developed with the WIN32 API required little memory and the executables were so small it was amazing. It felt like the old days, writing software which could fit on a floppy disk ( less than 1.4 megabytes). Now some may think, with the WIN32 API programmers would not have a higher level GUI framework to work with, like While initially true, I am sure in time that developers with the right mindset would start building GUI frameworks (which only required the WIN32 API) which would be small in size and fast, like they did for the Commodore 64 with Geos. Not possible you may say ! Well, actually it is and my own company has been for the last 15 years following in the footsteps of those Geos developers, building a GUI framework designed for minimal hardware. I know it is possible, because it is already being done. Other companies should consider this approach as well, if they would like to build the next generation of software for Windows based Internet of Things devices. I am still amazed at powerful the WIN32 API is and what can be done with it. Having built a GUI framework with nearly 1000 commands in it which still can fit on a floppy disk (with room to spare at only about 1 megabyte) tells me that tiny, IOT (Internet of Thing) devices should not pose a problem.

WIN32 programming, a lost art

WIN32 programming appears to have become a lost art, but it need not be. There are plenty of resources available for companies interested in adding this to their software development methods. You can still develop software using managed languages for PC’s and some Windows tablets, but for the coming Internet of Things, why not consider adding WIN32 programming. Maybe you are wondering, most programming sites cator to managed languages, so where can I find information about WIN32 programming ? A quick search on can help you find plenty of older books on WIN32 programming (sadly there are none that I know of which are current). Some of the best resources can be found on support forums provided by companies which make native code Windows compilers . Microsofts web site, while not teaching WIN32 programming, does have extensive documentation about the WIN32 flat API’s. While some may refer to these as legacy API’s, they are actually at the core of Windows. What do you think runs on ? You can skip the “middleman” and go to the core of the operating system.

Not convinced ?

Let me provide an example of a company which has leveraged the WIN32 APIs so you can better appreciate what it is capable of (note: this company is not associated with mine). The point is to demonstrate what is possible when programmers write software using the core WIN32 API, rather than with managed languages, for Windows. This company is one of the best Graphic engine developers I have personally come across in a long time. One tool they write is called GDImage, a graphic engine, which can leverage multiple low level graphic APIs and merge them together, including the GDI, GDIplus and OpenGL. The original version was written using the PowerBasic 32 bit native code compiler, but the developer has ported it over to Microsoft C to get the benefit of 64 bit compilation. The developer also shares his knowledge of WIN32 programming on a number of programming forums.  The point here is that the graphic library (DLL) is feature rich, performs very well (speed), was designed to only use the core WIN32 API and the entire runtime library is only 315 KB (kilobytes) in size. Now that is the size developers want to reach for the coming Internet of Things devices. That is 1/5th the size of an old fashioned floppy disk. Download this developers demo to better appreciate this. This developer even avoids using the C++ classes for GDIplus, but used the Flat GDIplus API’s provided in Windows.  There are developers out there who are currently leveraging the raw WIN32 API (and OpenGL, etc.). There are still sources available for programmers to learn WIN32 programming.


Comments Off