Towards a native windows GUI

[Michael Leonhard]

Hello Joe,

Your idea to write an interface of the basic Win32 API to Erlang is
very intriguing.  I think it is a great idea.  I have written some
programs using the pure Win32 API.  None of them were very good, but
they worked.  In my experience, it was necessary to use more than the
message handling functions.  It may be possible to replicate the
action of some functions, like DestroyWindow() but one would have to
dig really deep into the sources of user32.lib.  It would probably be
necessary to implement an Erlang interface to many functions outside
those which handle messages.  Perhaps 20 would be needed from
user32.lib and then another 30 from gdi32.lib for the graphics
primitives.

Basic functions that must be interfaced:
RegisterClassEx
CreateWindowEx
DestroyWindow
GetMessage
PostMessage
SendMessage
ShellExecuteEx
Registry functions (~10)
BeginPaint
EndPaint
InvalidateRect
Other GDI functions (~30)

Using the functions above, it may be possible to emulate these
necessary functions:
SetFocus
GetFocus
GetWindowInfo
GetWindowText
SetWindowText
GetClientRect
MoveWindow
ShowWindow
TranslateMessage
DispatchMessage

I compiled these lists from the source code of pure Win32 applications
that I wrote many years ago.  Though there are many functions, most of
them have simple parameters and return values.  Writing the interface
may be tedious, but it is certainly doable.

* Extra Erlang node
The extra node would be "patched" to support extra BIFs that perform
Win32 calls.  These BIFs would manage C objects like HANDLEs and
various C structs that are required by some calls.  HANDLEs are just
pointers in the Win32 process's address space.  Exposing these to
Erlang code would allow a process to crash the node.  Where should the
tradeoff between safety and simplicity be made?

To save us application developers from the horror of building a
patched version of Erlang on Win32, some experts could build it and
distribute the binaries.  Preferrably, these would be distributed in a
self-installing executable, in the longstanding Windows tradition.

* C port driver
I have never worked with a port driver, but it seems that it would be
easier to build an application using a port driver than to set up a
second custom Erlang node.  A self-installing executable could drop
the port driver binaries right into the local Erlang installation.

Some of the Win32 calls may block for periods of time (GetMessage()). 
Would the erl +A option enable the port driver to run in a separate
thread?

>> what is a "dynamic GUI"?
> One that is created by a program
> Think "Higher order functions"
> F is a function which returns a GUI

Windows programming has waited a long time for this concept.

The idea of writing Win32 GUIs with Erlang is very exciting.  I think
that the concurrency of Erlang is perfectly suited to writing good
GUIs.  I look forward to writing some widgets and applications in
Erlang for Win32.

-Michael