Building Win16 GUI Applications in C (2014)

Thanks for the mention! Creating FixDS was definitely one of those "aha!" moments for me. Like every other Windows programmer of that era, I just assumed that all the rigmarole with EXPORTS and MakeProcInstance() was necessary. It was simply How Things Are Done.

So seeing that EXPORTS and MakeProcInstance() existed solely for the purpose of loading the DS register, and finding that in application code the correct value was already in the SS register and could simply be copied over into DS? That was quite a surprise. Why were we all going to so much work when it wasn't necessary at all?

Ever since then, I've had my eye out for places where the conventional wisdom tells us to write code we don't need.

One that I've seen a lot lately - especially in StackOverflow answers - is an unnecessarily complicated way of creating closures in JavaScript.

Many JavaScript programmers seem to believe that the way you create a closure is by writing a function that returns a function. That works, of course, but unless you really need a function that returns a function, it's a complication you can do without. After all, a simple function call can create a closure all by itself.

For example, someone is writing a Google Maps API app that takes an array of data about different places, loops through the array with a for loop, and creates a marker for each of those places along with a click event handler for each marker.

Experienced JavaScript programmers can probably guess what the problem is going to be. I'll simplify the code a bit here to illustrate:

  var places = [
      { name: "One", lat: 34.1, lng: -80.7 },
      { name: "Two", lat: 35.2, lng: -81.8 }
  ];

  var infowindow = new google.maps.InfoWindow();

  for( var i = 0;  i < places.length;  i++ ) {
      var marker = new google.maps.Marker({
          position: new google.maps.LatLng(
              places[i].lat,
              places[i].lng
          ),
          map: map
      });

      google.maps.event.addListener( marker, 'click', function() {
          infowindow.setContent( places[i].name );
          infowindow.open( map, marker );
      });
  }

The problem here, of course, is that when the click callback function is called asynchronously, the for loop has already run to completion, and the i and marker variables no longer have the correct values for the marker that was clicked.

Inevitably, someone will now answer this question by suggesting a closure, and illustrating how you get a closure by using a function that returns a function:

  for( var i = 0;  i < places.length;  i++ ) {
      var marker = new google.maps.Marker({
          position: new google.maps.LatLng(
              places[i].lat,
              places[i].lng
          ),
          map: map
      });

      // Changes are below, using a function that returns a function
      google.maps.event.addListener( marker, 'click', (function( marker, i ) {
          return function() {
              infowindow.setContent( places[i].name );
              infowindow.open( map, marker );
          }
      })( marker, i );
  }

While that works, it's harder to understand than it needs to be. It's like using EXPORTS and MakeProcInstance() to load the DS register.

There is a simpler way:

  for( var i = 0;  i < places.length;  i++ ) {
      addMarker( places[i] );
  }

  function addMarker( place ) {
      var marker = new google.maps.Marker({
          position: new google.maps.LatLng(
              place.lat,
              place.lng
          ),
          map: map
      });

      google.maps.event.addListener( marker, 'click', function() {
          infowindow.setContent( place.name );
          infowindow.open( map, marker );
      });
  }

By simply calling a function in the loop, we create the closure we need, and we get simpler and more readable code too.

Of course you can achieve the same effect by using array.forEach(), because that calls a function and gives you a closure automatically:

  places.forEach( function( place ) {
      var marker = new google.maps.Marker({
          position: new google.maps.LatLng(
              place.lat,
              place.lng
          ),
          map: map
      });

      google.maps.event.addListener( marker, 'click', function() {
          infowindow.setContent( place.name );
          infowindow.open( map, marker );
      });
  });

Here's a search that will show numerous StackOverflow answers that promote the complicated function-returning-a-function pattern:

https://www.google.com/search?q=stackoverflow+maps+api+marke...

While i sit here watching gvfs shit itself randomly because of a minor glib version bump. This kind of crap is why there is still no "year of the desktop".

Say what you will about Microsoft, but one feature they really take seriously is backward compatibility, wherever feasible.

It's super impressive! But it won't run on 64 bit Windows.

I recently wrote a simple 32 bit Windows app that runs on 3.11 (with the 32 bit subsystem installed) through Windows 10. On the more recent Windows versions it supports theming and it's per-monitor high DPI aware. That is to say, it looks and works like a modern app.

To do this I had to build it as a freestanding binary with MingGW and do some version probing and dynamic DLL lookups but altogether it wasn't too hard.

Petzold's book that dom0 mentioned is/was the definitive Win32 reference albeit very dated now. It obviously will not cover anything in Windows 2000 and later(!).

MSDN is still the go to place for all Win32 documentation although it can be tricky to find exactly what you want as MS prefer to push you towards .NET related stuff. Even finding plain C++ can be a pain with them pushing you towards Android C++ development by default for some reason?!

For software you can go with MinGW-W64 or Visual Studio 2015 Community (you will need to do a custom install and select the VC++ tools as they are not included by default anymore).

I used theForger's Win32 tutorials back in the day to get started http://winprog.org/tutorial/

Programming Windows, 5th Edition (1998) is still practically completely valid, although it does of course not mention anything that came after it.

I'm learning bits and pieces via https://handmadehero.org/

With some minor (but annoying) changes, it was also the OS/2 Presentation Manager API.

Crazy times. A null pointer reference used to cause a full computer reboot. You had to read your printf logs to find where approximately the program stopped.

I spent a sizeable amount of my scholarship money on Microsoft Systems Journals, Charles Petzolds "Programming Windows" and "Undocumented Windows". The latter would teach you tricks like saving the Window position in an INI file so you could make it reappear in the same place where it was closed...

Books, magazines, abd CompuServe! PC Magazine had Win16 experts answering questions on CompuServe.

It was very funny making Dialogs with a randomly moving "OK" button responding on WM_MOUSEOVER (or something like it). Make them bigger, toolboxes, always on-top, and disable the top-right "x" button. Fun times :P

Worse was when those resources were not available. You were pretty much SOL.

I "invented" a dispatcher library back then for that. Marking and matching callbacks with strings and looping through in the proc [ was very proud with it :-) ]

Hmm. ELF and Mach-O should support fat/multiarch binaries IIRC (Mach-O certainly does, it was used in the days of Apple PowerPC=>Intel transition, not sure if it's still supported though), and I think it should also be possible to create COM/COFF binary that can be interpreted and/or run by Linux/Darwin kernel.