Reputation:
I'm coding in assembly under Windows 10 using x64 masm, and really enjoying it! Haven't touched assembly in something like 25 years - Uni days. Currently learning and doing basic stuff, and getting up to speed rather quickly.
I would like to have a GUI front-end, like a Window, and down the track have a menu and child windows...
The 2 traditional ways (I guess) to achieve this are:
In assembly use CreateWindowEx and related Windows API functions, OR
Build the front-end with Visual C++ then code with masm for other areas for your program
Now since I'm programming purely for fun, and want to stick with assembly language only, the first option is the only one for me.
But I read on one assembly forums that it's not recommended to build/call Windows via assembly. I'm not sure why? I can only imagine because it's somewhat painful when compared to building a front-end via a high level language such as VC++.
Questions:
Any reason not to build a GUI Windows front-end via assembly/CreateWindowEx...?
Would building Windows via DirectX be a crazy idea?
Any other techniques to build a front-end using assembly only?
Upvotes: 1
Views: 1406
Reputation: 44146
I haven't done any programming in Windows 10 specifically, so this may be a bit outdated.
When you build a GUI in Windows you end up calling a well known and mostly standard set of APIs1 in sequence, usually with very basic control flow like single branch ifs. This, of course, is not true for every application but it is for mostly.
Long story short, in this context, coding a GUI in C or in assembly doesn't make a big difference, the most important one being the different way you call the API functions2.
From an OS and CPU point of view there is no difference between a program written in
assembly and a program written in any other language compiled to native instructions.
Also, if you use a good coding style, or high level directives like MASM INVOKE
, there is little to no difference in efforts between C and assembly when creating a GUI.
Answers
I can't think of any reason not to build a GUI in assembly. I actually have done that many times and I have become as fast as doing it in C.
I can't think of any advantage either, but fun.
What you can do in assembly that is related to
the GUI creation3 can be done in C too.
This is not a crazy idea at all, indeed is what WPF actually does as far as I know.
Doing that from scratch, while being a very fun and interesting exercise, will take quite a long time however, because you have to write the code to draw every control/widget plus the code to control them.
Using DirectX from assembly, or any language without natural support for COM, will be a very nasty thing however. I have once used DirectX in assembly and it is easy to get lost in the pointers to pointers to interfaces to get pointers to the methods.
Furthermore, you need to have a thorough understanding of how COM works and look back and forth into the IDL files.
As you said in your second point, you can use a WYSIWYG IDE like Visual C++ for creating
a resource file with a Dialog definition and then use functions like DialogBoxParam
to make a dialog out of the resource.
There is no C code involved, just a resource file4 that you can compile using the resource compiler of Visual Studio and link with your executable. Any modern linker, including the old TLINK, can link resource files.
1 The well known RegisterClassEx
, CreateWindowsEx
, GetMessage
, TranslateMessage
, DispatchMessage
, DefWindowProc
APIs.
2 X64 calling convention may be a little more tricky than the x86 one.
3 You mostly store/load values, some times you need a pointer and other times you can make things more elegant with pointers to functions. You never need specific architecture instructions, which is the main reason for using assembly beside fun.
4 It is a simple text file, with very easy format. You can code it your self with notepad if you are good a picturing coordinates in your mind, I was used to do so to avoid using Visual C++.
Upvotes: 3