About Us And Our Journery

At Blaiz Enterprises we have always strived for the very best in software creation.  From its initial conception right through to the end user experience, with a strong focus on lightweight code that is intuitively easy to use by all users, whilst being of very high quality.  This hasn't always been an easy road to travel.  In the past, a lot of the software industry had the tendency to throw code together, which made the task of creating reliable applications more difficult.  At Blaiz Enterprises, we don't move fast and break stuff - we make solid code designed for the long haul, and a typical life cycle of ten to twenty years.

The journey to where we stand now has been a long and difficult one, fraught with many pitfalls and a few epic disasters along the way.  We never gave up.  Coding is as much a process of discovery about what shouldn't be done, as it is about how to do things the right way.  Often success comes after several failed or sub-standard attempts.

Our latest software applications are engineered exclusively "in house" to our own high standards.  And as a general rule, they are natively portable.  They do not need to be installed to run.  And remain contained in the folder they are stored in.  Typically they run right off the bat, requiring little to no setup to get working. No additional "dll libraries" are required, and no unnecessary registry modifications are made, and no updating or alteration of existing computer files are made.

A lot of hidden work has gone into making their footprint small, their appearance highly customisable, and their execution over 25+ years of operating systems possible.

We first created the concept of user management back in 2005, as an attempt to allow our users greater freedom at changing the appearance and functionality of our applications.  A not so trivial task back then.  It doesn't take much for a user management system to go horribly wrong.  Think black text rendered onto black background.  Nothing says disaster louder than black on black.

Our applications have come a long way since then.  Our latest generation of software supports customisation of scrollbars, font, colors etc. With many built-in color schemes, ranging from black to some exotic color mixes.  You can even devise your own color scheme and save it to disk, or share it via social media or email - our color schemes are plain text which makes them quite safe to share as they use no code.

Countless thousands of technological challenges had to be overcome to make a single program run right.  This required a common code base that could be used over and over for each new application.  It was critical therefore, this code came as close to being flawless as humanly possible.  No code is ever perfect.  Though we try.

We named this new code foundation Gossamer, after it's meaning of thin and lightweight.  It aptly describes our intention.  Our latest software applications are now being built upon Gossamer, the 4th generation code foundation.  Currently weighing in under 130,000 lines of code, it is extremely compact and fast for what it does.  Being engineered exclusively 'in house' to our rigorously high standards, it achieves impressive functionality, stability and reliability under extreme pressure, across all flavors of Microsoft Windows, as far back even as Windows 95.

Ironically this makes our new applications natively compatible with Wine, as they use minimal functionality provided by the operating system.

Almost all the heavy lifting is done internally by Gossamer.  Specially designed multi-mode visual controls operate on orders of magnitude less code, significantly reducing overhead, permitting complex graphical user interfaces (GUIs) to be constructed in a few lines of code.  A lean graphics subsystem natively supports the most common 24 and 32 bit graphic functions, eliminating the majority of graphic API calls.

Reducing memory consumption is always a good idea.  And with Gossamer's realtime decode-to-paint TEA image format technology, the need for GUI image buffering is eliminated, allowing more images to be rendered, more simply, and with less memory consumed.  And with pixel level text rendering and multi-level anti-alias support built right in, fonts can be captured and drawn without the video card.

Higher resolution monitors bring obvious benefits, like more screen real estate, but a downside can be smaller than intended application windows.  Gossamer compensates by scaling up images and text to maintain an appropriate end user experience.  This might sound like a lot of work for an application, and you would be right.  The modern application requires an awful lot of code at its base to look, feel and perform correctly.  It takes clever code and precise engineering to pull it off.  Properly.

At Gossamer's heart is the GUI.  A library of specially built visual controls for the end user to interact with.  From the humble common dialog window, for performing such common tasks as saving a file, opening a file, or choosing a color or font, through to typing a large body of text in a multi-line text box.  Gossamer does it on its own.  Utilising a specialised window management and rendering system, free of the underlying operating system and video card hardware, using neither to perform the all important and complicated, window and control management and rendering process.  A coding task not for the faint-of-heart.  Nor a trivial feat of engineering by any means.

Gossamer is the first code foundation by Blaiz Enterprises to trully implement a full, overlapping window environment, complete with curved corners, and up to 250+ window depth support.  Honestly, Gossamer started out as a application code foundation and morphed into a mini-operating-system-like beast.

The first time we ever attempted some form of window management, was back in 2006 with our 3rd generation code foundation code named VUN, which was known as Visual Engine, User Management and Network Management.  Though it was not a true window management system, the rendering and area mapping was mainly performed by Microsoft Windows using video card calls to include and exclude the appropriate control and window paint areas.  A slow, buggy, and extremely difficult process to get right.  It took 3 whole months of around-the-clock coding to get the first iteration off the ground.  And that was only the control mapping and management handler.  It took another 5 to 15 years to smooth out the bugs and get it working to an acceptable level of performance and reliability.  Though it never reached the stability or performance levels of Gossamer, it did scale up.  VUN easily handled thousands of visual controls in a single application running on Windows 95/98, far exceeding the operating system and hardware limitations of the day.

In stark contrast, Gossamer took only 12-36 months to fully mature, with an extensive set of visual controls, stable window management and rendering system, and multi-format graphics subsystem.  A light-year-leap forward in both production and engineering achievement.  The coding philosophy behind Gossamer was KISS - Keep It Simple Stupid.

Every trick was employed to make Gossamer smaller, simpler, and more direct to use.  Specially crafted functions built right into the visual controls themselves are called on to construct a stable, sizeable, predictable, and often complex GUI layout.  This makes crafting a GUI potentially very quick, easy, and less prone to error.  Of course, from lessons learnt in the past, Gossamer doesn't lockout the extreme custom options either.  In fact, a GUI can be constructed from right inside the paint handler in realtime and on-the-fly.  An almost impossible consideration with other GUI based languages.  A case in point is Favourite Icon Maker, an application that generates its GUI from below the window header and above the button bar entirely within the paint handler, allowing for the app to flex as required.  It does this by employing the paint and map technique.  A technique that requires no visual controls to render an interactive GUI on the screen.

And all this from an 'old fashioned' 32-bit code base, which itself permits broad execution over a large range of Microsoft operating systems.  Be it on the oldest 32-bit Windows 95, through to the latest 64-bit flavours, like Windows 11.  Gossamer runs well on Linux too, via Wine.  Though Wine requires an Intel x86 / AMD64 CPU in order to run our applications, or any Windows Desktop Application.

An example of a deceptively simple looking application is Cynthia, pictured below, running on Ubuntu v20 happily playing a midi.  A little known fact is that playing a midi file reliably is a very difficult and technically challenging mathematical operation.  Made more difficult by the poor midi handling on Microsoft Windows, which has generally been unreliable and buggy, ironically, in later more advanced versions.  A simple thing like running a thread, pausing it and resuming it, is a nightmare if you want it done right.  There are more ways to handle a thread then there are ways of doing it right.  And that's not to mention the headache of Windows 95, where threads tend to crash just for the fun of it.  It took us 9 months of extensive midi testing and the advent of a custom built inter-thread communicator for Cynthia to play a midi reliably for more than 24 hours at speeds of 1,000% on Windows 95 to Windows 11.  Each generation of operating system, hardware and some audio drivers had quirks that prevented the well established and straight forward approach of coding inside a thread and pumping out notes to the audio driver from working as expected, if not flatout failing.

Threads don't run well on Windows 95.  Audio drivers and hardware don't always cooperate, some won't start a midi session from inside a thread, even though they should.  For Cynthia, her solution was to start a midi session outside of a thread, pass notes to the audio driver from inside a thread, and control the internal processing of the thread externally from her GUI without interrupting the flow of the thread directly.  Sounds complicated, but was actually quite achievable in the end.  And it works on everything.  At least as far as we could test.  It took 9 solid months and a lot of wrong code to get right, but Cynthia was well worth it in the end.




A Brief History Of Our Code Foundations And What They Achieved

1997 / 1st Generation
The 1st generation of our software focused on basic infrustructure automation, and data sharing at the low level and at the user level. This allowed many of our programs to share common data quickly and easily, making for a flexible work enviroment.

No significant custom GUI system/handling at this point. Programs tendered to suffer from flicker and slow resize/sluggish graphics work, as well as some unreliable GUI components, for instance, the drop down combobox that tendered to forget what was selected, and the notoriously unreliable richedit text control, which more often than not spat out RTF code on the screen, was unable to select large portions of text, presumably due to an out-of-date 16 bit number handler, and would often fail to handle large text documents without first being primed correctly, though even then, it would randomly fail at times or scramble the text entirely.  Something Microsoft seemed powerless to fix over some twenty plus years.  Eventually, we would go on to build our own text box from scratch, and replace Microsoft's richedit control altogether.



2005 / 2nd Generation
This was a bold attempt at extensive customisation.  Though we only achieved a small step away from the standard operating system overhead for all GUI processing and window handling, it was our first real attempt at managing a greater GUI workload and the intricate art of visual control rendering for ourselves.

It was also the first time we had implemented a graphics subsystem specifically for the task of rendering GUI components onto the screen.  It remained heavily reliant on the operating system for many functions, which actually worked against us.  In hindsight, working too closely with the operating system reduced our chances for success.

However, it was a win in terms of graphic freedom and power.  And we had a taste for it now.  And we weren't going to back down.  But stability issues and some graphical limitations required a major rethink going forward.  We needed something simpler and more radically independent of the operating system in order for it to work.  Simply, we needed more room for creative freedom.  It'd been a vivid lesson about doing too much of the wrong stuff first, and neglecting the basics, which made it a recipe for failure.

Quite soon a new, vastly more ambitious code foundation was planned.  One where extreme scalability was at its core.  We had learned that basic, raw power was far more important than complex graphical effects, which could always be bolted on later, if the system was built right.



2006 VUN / 3rd Generation
This time we built the code foundation for scalability.  Graphical appearance was secondary, but remained important.  What became our 3rd code foundation yielded tremendous success.  Far beyond our own lofty expectations.  Not only did we achieve a high level of GUI freedom, but we also managed a level of solid stability and massive performance increase over our previous code foundations.  It was almost like magic.

For the first time we could build an application with thousands of controls on the screen at the same time, without any loss of performance or significant memory or operating system penalty.

A little fun fact back in the day, Windows 95 could only support a few hundred controls before losing system stability and inevitably crashing.  For example, an application that attempted to load and display a 100 single line text boxes would cause great instability, and eventual, if not immediate failure of the operating system.

Consequently, building a complex application up to this point was an extremely challenging ordeal, often mitigated by countless dialog windows that would temporarily use a few controls and release them once it was closed.  But we no longer had to suffer this limitation.  In addition, we brought a new graphics subsystem online, one designed specially to work around the limitations of Windows 95/98+.  One example, the enlarging of an area of an image to a high zoom level, for instance by a hundred times or more.  Windows limited this differential to 16 bit, whereas we increased it to 32 bit.  Our new graphics subsystem could zoom without failure, in realtime, with little to no additional memory or processor overhead.

Along with many more enhancements, this 3rd generation code foundation allowed our software applications to perform with great stability whilst performing challenging tasks on limited hardware and software.

In fact, the new system proved so flexible and scalable, that we managed to run our own search engine on a cluster of Windows 98 machines - it was called Rawgrunt.  And yes, we managed every aspect of our search engine via a host of networked GUI panels and controls, all in realtime.



2021 Gossamer / 4th Generation
But our latest code foundation is by far the most impressive to date.  Being far lighter, even more powerful, more stable, and just as scalable, and almost completely automatic behind the scenes.  Gossamer is a different beast altogether.  Swift application development can be achieved through the use of predictable and structured GUI layout functions, many of which are baked right into the system itself.

Sporting a brand new graphics subsystem, capable of seamlessly handling multiple different image handlers, and designed to be operating system independent, Gossamer at last takes full charge of the window and visual control eco system.  From management through to pixel level rendering, everything is handled internally.  All this and more from an extremely compact code base of 130,000 lines of code.

Applications are now natively portable, with extensive 24 and 32 bit graphic procedures, sound support, io file handling with hugh file support (64 bit), native dialog windows, and internal drag and drop support.

Unlike past code foundations, Gossamer was written from scratch from the bare metal up.  And only what was required was included.  Using various techniques, the overal size of the code was considerably reduced.  In some instances, especially with visual controls, we were able to drastically reduce the amount of code.

One significant way in which we achieved this result was through repurposing core visual controls.  We did this by switching the internal mode of the control to a new state in order for it's appearance and/or behaviour to be modified.  At times only slightly, and other times more significantly.  This method allowed us to gain significant functionality at greatly reduced cost.  And less code means less errors, and less time spent hunting them down.

Amazingly, Gossamer is fully backward compatible to Windows 95.  And the same source code can now be compiled in Delphi 3, circa 1996, and modern day Lazarus 2, via the Delphi 7 compatibility compiler option.




A Comparison Between Code Foundations
Here's a quick overview of some of the key differences between the four generations of our code foundations, which have formed the basis of all our software applications over the decades.

It's quite clear glancing at the table below the significant improvement in our latest 4th generation code foundation, Gossamer.  The more green ticks in the table below, the more beneficial the code foundation.