In case anyone ever struggles, this provides an excellent explanation.
Although they are being a bit naughty with the first code section on that page. I was reading the other day that when you create a device context, it does actually have a default bitmap selected into it so you do actually need to save the old bitmap when you select one in and ensure you select it back in before you delete the DC.
The code should really have been:
HBITMAP Old=(HBITMAP)SelectObject(hdcMem, g_hbmMask); BitBlt(hdc, 0, 0, bm.bmWidth, bm.bmHeight, hdcMem, 0, 0, SRCAND); SelectObject(hdcMem, g_hbmBall); BitBlt(hdc, 0, bm.bmHeight, bm.bmWidth, bm.bmHeight, hdcMem, 0, 0, SRCPAINT); SelectObject(hdcMem, Old); // okay to DeleteDC(hdcMem) now
or I think you get a resource leak.
I struggle to find any definitive information on resource leaks these days so I play it as safe as possible. You can test Win32 GDI stuff for resource leaks with Task Manager by going to Processes then doing View -> Columns and selecting GDI Objects.
You can then run your app, note the number used, perform an operation and check it against the total shown in Task Manager.
I know it is less of a problem from Win2000 onwards but it feels icky to not be thinking about things like that.
Mad-obsessive-rant ends.
I just loved this idea of a 'virtual assembler', never thought of that, but like you said, it should be tremendously useful! I just had another idea though: what about if you could provide a basic definition like this, and use it aftwards with named variables:
#byte
#enum { mid begin end }
#double
#struct waypoint {x y byte:flag=mid } //default value for "flag"
#waypoint 10 20 begin
#waypoint 12 50
//another way
#waypoint x=10 y=70
#waypoint flag=end x=40 y=20