|
Article Publishing
|
~ using the windows api directly is masochism |
Tools like Delphi (and cough, Visual Basic) exist because using the windows API is being a masochist.
The only problem is that when your tool like delphi doesn't do exactly what you need to do, then you need to be a masochist again and make some windows API calls directly to accomplish the desired behavior.
With all due respect to the geniuses at Sysinternals, who wrote pure Win API software with no wrappers and all just direct API calls (beautiful code and tools they wrote), anyone who suffers using the Windows API directly is a masochist, or an aspergers genius, or likely a combination of both.
When your high level wrapper tool like Delphi doesn't do what you need to do, by all means return to being a masochist temporarily, but long term Windows API masochism (using the API directly) is a suffering mechanism for fools, or possibly an enjoyment mechanism for aspergers folk who can memorize what parameters have to be sent in to to 1200 different functions all with different specifications.
What do I mean by masochism? The issue is that if you send in one parameter that is not exactly correct, your whole app can blow to pieces, whereas wrappers like the Delphi VCL (or supposedly .Net framework, I don't know much about it) do all this for you without the serious risks of making a tiny mistake that causes serious misbehaved apps.
The other issue with using windows API directly, is that if Windows decides to change something (like MS adds themes in xp/7/8/10 which weren't available in Windows NT or Windows 98, some of your windows api calls may be broken even though they worked perfectly before - or some new window style available, or new border thickness default, etc. etc.). A high level wrapper usually handles this all for you, definitely at the cost of someone maintaining the wrapper which does take time.
I think the GoLang authors have come up with some supposed solutions to the "sending in parameters" to functions issue, but I've had little time to research what the solutions are and if they work, without doing some magical crazy functional programming wizbang.
Often a WinAPI function will be picky about sending in empty parameters or null, or zero, and could even change the behaviour in the future of such a parameter. Then there is the issue of the API not writing too many wrappers of its own with defaults set, because then the API becomes bloated and is a wrapper itself, not a low level API (or mid level?) api.
API's are often picky, and one little mistake can barf up an application.. hence it is masochism and self suffering to use API's directly.
Indeed you've got the issue of wrappers not being written the way you wish them to be written, so you end up writing your own wrappers around the API anyway at some point.
This API hell is not just prevalent in windows api programming but also OpenGL, X11, GTK, and basically any API.
There is no clear silver bullet solution to this problem as you can't have it both ways: a wrapper that is too high level will not offer you enough knobs to customize, but a wrapper that is too low level is arcane, tricky, and even obfuscated to use.
|
|