Biography of David Lindauer

At work I do a mix of embedded systems and windows programming.  Our embedded systems these days run on windows CE and the programs usually are designed to run either on CE or on the desktop depending on compiler settings.    Mostly I am concerned with networking devices together via TCP/IP, or making devices like gateways to a frontend or web servers in C/C++.  Sometimes I've also been on a tangent working various Visual Basic or C# projects.   The work is loosely part of the field called 'building automation' - it is more on the 'building protection' side of that.

I've been involved with web development both at the GUI level and at the backend level, because we do our device configuration through web interfaces.   Although we basically rolled our own simple backend instead of using one of the standard platforms.  

I'm involved with encryption, xml, and various other technologies.   I do participate in a Saas project but not as a major contributor.   But still, I have a little taste of what is involved.

Before this job I had some time to work on various personal projects, and before that I worked another embedded systems job in the development of manufacturing equipment. We added touch screen controls to our products back in the 80's.   It is a fact that Steve Jobs saw the results of that work while buying manufacturing equipment for his plant...  but more of a rumor that perhaps seeing that work helped shape certain designs that have become somewhat ubiquitous in some of the devices he has had built.    No I didn't start that rumor but I thought it was interesting...

I did graduate from college with a bachelor's degree in Electrical Engineering...   I spent a year or so on coursework for the Master's but when push came to shove didn't finish the project work I was to do so never got the Master's.    To be honest I was somewhat relieved about that...   I was uneasy about the box having a Master's was going to put me in.

While working here I've done various things in my spare time, a lot of work was done with the CC386 compiler and tool chain for example.    CC386 was an amalgamation of tools that I found on the web, and I spent a lot of time making them work together and improving the C compiler from its original rather buggy ability to parse K&R C compatible programs.   I had written the run-time library from the ground up, however.  

This compiler saw a lot of use, and some people contributed major efforts in pointing out bugs.  There were some feature requests as well; one year I added far pointers to this 32-bit compiler so that a professor could use it to teach his students operating systems.  

As CC386 was originally an MSDOS compiler I ended up supporting targeting virtually every major DPMI system  that had been developed.   A contributor who has been a friend for a long time helped early on with that but writing a command line shell that would select the compiler options associated with the various DPMI platforms; a variant of that is still a part of Orange C.

One contributor passed a lot of C programs through CC386 to find issues, suggested improvements to the code generation especially for floating point, and also contributed bug fixes to the libraries.    Toward the end he also helped me improve the preprocessor to be standards-compliant.  I did have a version of CC386 that would generate 68020 code and people were interested in that as well.

I also worked on a PPP TSR for MSDOS back before broadband was readily available.   Kind of a fun little project, however, hard to debug because there was such a wide range of modems being used by the users.

There was also the GRDB debugger.  (which stood for 'Get Real Debugger' - a play on words as this is a 'real mode' debugger)  This is a jacked-up MSDOS debugger that has everything including the kitchen sink.   At the end it also had support for 32-bit and DPMI programming, as well as support for the so called 32-bit real mode.   It even had a symbol table, and a helper utility that will populate it from the map files from various assemblers of the day.  

Again it saw a lot of use, even gaining some traction in the BIOS community.   One of the bios developers had some major feature requests and bug fix requests for me...   I think I added SSE instructions to the list of instructions it would assemble and disassemble for him.   By that time GRDB already supported MMX.    I think the last thing major thing I did with GRDB was make it work with a serial port in addition to working with the PC's monitor - this for a company that wanted to give it to customers of an embedded board they were producing.   Hey, I netted a free board out of it :)

I've done a lot of other stuff in my free time including a simple OS.... one of my favorites is the 68020 simulator written in x86 assembly.   Not very efficient, but fun!  It of course had a built-in debugger, no symbol table though.

But eventually I grew tired of some major issues with the CC386 source code and also wanted to branch into code optimizations, which CC386 simply didn't do.   And I wanted to support embedded systems better, as well as design a system where all the pieces were designed to work together and some other things as well.    

So Orange C was born.   It has been around for a while now, with the preliminary work being started back in the 2006 time frame.   It has been maturing over the years.

The only major thing Orange C inherited from CC386 was the IDE, but even so there were major rewrites to it.   Orange C can generally do everything CC386 did, with one exception:   I haven't implemented far pointers.   As there was a period where I supported both CC386 and Orange C, I was also finding ways to improve the Orange C compiler when people suggested ways to improve CC386.

In my spare time I've meditated, and I like to eat out;  I used to do nearly every meal out but not so much any more.   But I still go out on weekends, or sometimes for a salad in the evenings.  And I've never married, which is why I can still affort to spend time on Orange C :)