As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does it make sense, having all of the C#-managed-bliss, to go back to Petzold's Programming Windows and try to produce code w/ pure WinAPI?
What can be learn from it? Isn't it just too outdated to be useful?
This question is bordering on religious :) But I'll give my thoughts anyway.
I do see value in learing the Win32 API. Most, if not all, GUI libraries (managed or unmanaged) result in calls to the Win32 API. Even the most thorough libraries don't cover 100% of the API, and hence there are always gaps which need to be plugged by direct API calls or P/invoking. Some of the names of the wrappers around the API calls have similar names to the underlying API calls, but those names aren't exactly self-documenting. So understanding the underlying API, and the terminology used therein, will aid in understanding the wrapper APIs and what they actually do.
Plus, if you understand the nature of the underlying APIs that are used by frameworks, then you will make better choices with regards to which library functionality you should use in a given scenario.
Cheers!
I kept to standard C/C++ for years before learning Win32 API, and to be quite blunt, the "learning Win32 API" part is not the best technical experience of my life.
In one hand Win32 API is quite cool. It's like an extension of the C standard API (who needs fopen when you can have CreateFile. But I guess UNIX/Linux/WhateverOS have the same gizmo functions. Anyway, in Unix/Linux, they have the "Everything is a file". In Windows, they have the "Everything is a... Window" (no kidding! See CreateWindow!).
In the other hand, this is a legacy API. You will be dealing with raw C, and raw C madness.
Like telling one's structure its own size to pass through a void * pointer to some Win32 function.
Messaging can be quite confusing, too: Mixing C++ objects with Win32 windows lead to very interesting examples of Chicken or Egg problem (funny moments when you write a kind of delete this ; in a class method).
Having to subclass a WinProc when you're more familiar with object inheritance is head-splitting and less than optimal.
And of course, there is the joy of "Why in this fracking world they did this thing this way ??" moments when you strike your keyboard with your head once too many and get back home with keys engraved in your forehead, just because someone thought it more logical to write an API to enable the changing of the color of a "Window", not by changing one of its properties, but by asking it to its parent window.
etc.
In the last hand (three hands ???), consider that some people working with legacy APIs are themselves using legacy code styling. The moment you hear "const is for dummies" or "I don't use namespaces because they decrease the runtime speed", or the even better "Hey, who needs C++? I code in my own brand of object-oriented C!!!" (No kidding... In a professional environment, and the result was quite a sight...), you'll feel the kind of dread only condemned feel in front of the guillotine.
So... All in all, it's an interesting experience.
Edit
After re-reading this post, I see it could be seen as overly negative. It is not.
It is sometimes interesting (as well as frustrating) to know how the things work under the hood. You'll understand that, despite enormous (impossible?) constraints, the Win32 API team did wonderful work to be sure everything, from you "olde Win16 program" to your "last Win64 over-the-top application", can work together, in the past, now, and in the future.
The question is: Do you really want to?
Because spending weeks to do things that could be done (and done better) in other more high-level and/or object-oriented API can be quite de-motivational (real life experience: 3 weeks for Win API, against 4 hours in three other languages and/or libraries).
Anyway, you'll find Raymond Chen's Blog very interesting because of his insider's view on both Win API and its evolution through the years:
https://blogs.msdn.microsoft.com/oldnewthing/
Absolutely. When nobody knows the low level, who will update and write the high level languages? Also, when you understand the low level stuff, you can write more efficient code in a higher level language, and also debug more efficiently.
The native APIs are the "real" operating system APIs. The .NET library is (with few exceptions) nothing more than a fancy wrapper around them. So yes, I'd say that anybody who can understand .NET with all its complexity, can understand relatively mundane things like talking to the API without the benefit of a middle-man.
Just try to do DLL Injection from managed code. It can't be done. You will be forced to write native code for this, for windowing tweaks, for real subclassing, and a dozen other things.
So yes: you should (must) know both.
Edit: even if you plan to use P/Invoke.
On the assumption that you're building apps targeted at Windows:
it can sure be informative to understand lower levels of the system - how they work, how your code interacts with them (even if only indirectly), and where you have additional options that aren't available in the higher-level abstractions
there are times when your code might not be as efficient, high-performance or precise enough for your requirements
However, in more and more cases, folks like us (who never learned "unmanaged coding") will be able to pull off the programming we're trying to do without "learning" Win32.
Further, there's plenty of sites that provide working samples, code fragments and even fully-functional source code that you can "leverage" (borrow, plagiarize - but check that you're complying with any re-use license or copyright!) to fill in any gaps that aren't handled by the .NET framework class libraries (or the libraries that you can download or license).
If you can pull off the feats you need without messing around in Win32, and you're doing a good job of developing well-formed, readable managed code, then I'd say mastering .NET would be a better choice than spreading yourself thin over two very different environments.
If you frequently need to leverage those features of Windows that haven't received good Framework class library coverage, then by all means, learn the skills you need.
I've personally spent far too much time worrying about the "other areas" of coding that I'm supposed to understand to produce "good programs", but there's plenty of masochists out there that think everyone's needs and desires are like their own. Misery loves company. :)
On the assumption that you're building apps for the "Web 2.0" world, or that would be just as useful/beneficial to *NIX & MacOS users:
Stick with languages and compilers that target as many cross-platform environments as possible.
pure .NET in Visual Studio is better than Win32 obviously, but developing against the MONO libraries, perhaps using the Sharp Develop IDE, is probably an even better approach.
you could also spend your time learning Java, and those skills would transfer very well to C# programming (plus the Java code would theoretically run on any platform with the matching JRE). I've heard it said that Java is more like "write once, debug everywhere", but that's probably as true as (or even moreso than) C#.
Analogy: If you build cars for a living (programming), then its very pertinent to know how the engine works (Win32).
Simple answer, YES.
This is the answer to any question that is like.. "does it make sense to learn a low level language/api X even when a higher level language/api Y is there"
YES
You are able to boot up your Windows PC (or any other OS) and ask this question in SO because a couple of guys in Microsoft wrote 16-bit assembly code that loads your OS.
Your browser works because someone wrote an OS kernel in C that serves all your browser's requests.
It goes all the way up to scripting languages.
Big or small, there is always a market and opportunity to write something in any level of abstraction. You just have to like it and fit in the right job.
No api/language at any level of abstraction is irrelevent unless there is a better one competing at the same level.
Another way of looking at it: A good example from one of Michael Abrash's book: A C programmer was given the task of writing a function to clear the screen. Since C was a better (higher level) abstraction over assembly and all, the programmer only knew C and knew it well. He did his best - he moved the cursor to each location on the screen and cleared the character there. He optimized the loop and made sure it ran as fast as it could. But still it was slow... until some guy came in and said there was some BIOS/VGA instruction or something that could clear the screen instantly.
It always helps to know what you are walking on.
Yes, for a few reasons:
1) .net wraps Win32 code. .net is usually a superior system to code against, but having some knowledge of the underlying Win32 layer (oops, WinAPI now that there is 64-bit code too) bolsters your knowledge of what is really happening.
2) in this economy, it is better to have some advantages over the other guy when you are looking for a job. Some WinAPI experience may provide this for you.
3) some system aspects are not available through the .net framework yet, and if you want to access those features you will need to use p/invoke (see http://www.pinvoke.net for some help there). Having at least a smattering of WinAPI experience will make your p/invoke development effort a lot more efficient.
4) (added) Now that Win8 has been around for awhile, it is still built on top of the WinAPI. iOS, Android, OS/X, and Linux are all out there, but the WinAPI will still be out there for many many years.
Learning a new programming language or technology is for one of three reasons:
1. Need: you're starting a project for building a web application and you don't know anything about ASP.NET
2. Enthusiasm: you're very excited about ASP.NET MVC. why not try that?
3. Free time: but who has that anyway.
The best reason to learn something new is Need. If you need to do something that the .NET framework can't do (like performance for example) then WinAPI is your solution. Until then we keep ourself busy with learning about .NET
For most needs on the desktop you wont need to know the Win32, however there is a LOT of Win32 not in .NET, but it is in the outlaying stuff that may end up being less than 1% of your application.
USB support, HID support, Windows Media Foundation just off the top of my head. There are many cool Vista API's only available from Win32.
You will do yourself a large favor by learning how to do interop with a Win32 API, if you do desktop programing, because when you do need to call Win32, and you will, you won't spend weeks scratching your head.
Personally I don't really like the Win32 API but there's value in learning it as the API will allow more control and efficiency using the GUI than a language like Visual Basic, and I believe that if you're going to make a living writing software you should know the API even if you don't use it directly. This is for reasons similar to the reasons it's good to learn C, like how a strcpy takes more time than copying an integer, or why you should use pointers to arrays as function parameters instead of arrays by value.
Learning C or a lower level language can definitely be useful. However, I don't see any obvious advantage in using the unmanaged WinAPI.
I've seen low level Windows API code... it ain't pretty... I wish I could unlearn it. I think it benefits to learn low level as in C, as you gain a better understanding of the hardware architecture and how all that stuff works. Learning old Windows API... I think that stuff can be left to the people at Microsoft who may need to learn it to build higher level languages and API... they built it, let them suffer with it ;-)
However, if you happen to find a situation where you feel you just can't do what you need to do in a higher level language (few and far between), then perhaps start the dangerous dive into that world.
yes. take a look at uTorrent, an amazing piece of software efficiency. Half of it's small size is due to the fact that much of it's core components were re-written to not use gargatuian libraries.
Much of this couldn't be done without understanding how these libraries interface with the lower level API's
It's important to know what is available with the Windows API. I don't think you need to crank out code with it, but you should know how it works. The .NET Framework contains a lot of functionality, but it doesn't provide managed code equivalents for the entire Windows API. Sometimes you have to get a bit closer to the metal, and knowing what's down there and how it behaves will give you a better understanding of how to use it.
This is really the same as the question, should I learn a low level language like C (or even assembler).
Coding in it is certainly slower (though of course the result is much faster), but its true advantage is you gain an insight into what is happening at close to the system level, rather than than just understanding someone else's metaphor for what is going on.
It can also be better when things won't work well, or fast enough or with the sort of granularity that you need. (And do at least some subclassing and superclassing.)
I'll put it this way. I don't like programming to the Win32 API. It can be a pain compared to managed code. BUT, I'm glad I know it because I can write programs that otherwise I wouldn't be able to. I can write programs that other people can't. Plus it gives you more insight into what your managed code is doing behind the scenes.
The amount of value you get out of learning the Win32 API, (aside from the sorts of general insights you get from learning about how the nuts and bolts of the machine fit together) depends on what you're trying to achieve. A lot of the Win32 API has been wrapped nicely in .NET library classes, but not all of it. If for instance you're looking to do some serious audio programming, that portion of the Win32 API would be an excellent subject of study because only the most basic of operations are available from .NET classes. Last I checked even the managed DirectX DirectSound library was awful.
At the risk of shameless self-promotion....
I just came across a situation where the Win32 API was my only option. I want to have different tooltips on each item in a listbox. I wrote up how I did it on this question.
Even in very very high level languages you still make use of the API. Why? Well not every aspect of the API has been replicated by the various libraries, frameworks, etc. You need to learn the API for as long as you will need the API to accomplish what you are trying to do. (And no longer.)
Apart from some very special cases when you need direct access to APIs, I would say NO.
There is considerable time and effort required to learn to implement the native API calls correctly and the returning value is just not worth it. I would rather spend the time learning some new hot technology or framework that will make your life easier and programming less painful. Not decades-old obsolete COM libraries that nobody really uses anymore (sorry to COM users).
Please don't stone me for this view. I know a lot of engineers here have really curious souls and there is nothing wrong with learning how things work. Curiousity is good and really helps understanding. But from a managerial point of view, I would rather spend a week learning how to develop Android apps than how to calls OLEs or COMs.
If you planning to develop a cross platform application, If you use win32, then your application could easily run on linux through WINE. This results in a highly maintainable application. This is one of the advantages of learning win32.
Related
I've spent the better part of my morning and afternoon playing around with GUI frameworks in Haskell, as I need some visualization and interaction capabilities and I'm not in love with writing my core functionality in Haskell then piping out to a front end written in another GUI; I'd prefer to do it all from one language. The better part of that better part has been spent compiling and patching source code, or Googling obscure compilation errors.
I've spent plenty of time reading SO questions, plenty of time on haskell.org, and plenty of time reading documentation. What I've encountered is a very large swath of outdated or poorly documented information. I can boil it down to these three things:
A glut of options built on top of Gtk+ bindings. I don't care for Gtk+ very much, mostly because I find it to be quite unpleasant to look at, especially on OS X. Griping about the UI looking out of place and/or just plain ugly might seem silly, but that's important to me. Especially if I want other people to utilize any of the programs that I create.
wxHaskell, which is stable and incredibly easy to install but many of the existing tutorials seem to be for wx-0.1x and the conventions for bridging the wxWidgets 2.9.x docs to wx-0.90.x are very very spotty and hard to grok, when they even exist.
qtHaskell, which seems to be mostly abandoned (correct me if I'm wrong), only compiles with newer versions of GHC after applying a year-old patch, and spits out a massive amount of warnings that indicate they will soon become compile errors in newer versions of GHC.
In effect, I'm looking for Haskell's answer to Java's Swing; a library that is robust, maintained, well documented, easy to get started with, makes an attempt to be native in look and feel, can keep up with GHC's development pace, and not at high risk for abandonment. This seems to be exactly zero GUI frameworks, but then it seems that most of the "official" resources/wikis/pages/docs related to GUI frameworks are woefully unmaintained so I decided to turn to the community to see if there was something I just wasn't finding. I'm not terribly worried about the framework being cross platform, just so long as it works on modern versions of OS X.
To reiterate, I'm not really looking for someone to send me a link to haskell.org or the WikiBook. I've been there, and I didn't like what I saw. Most of the information there is just so out of date that it only creates more work, not less.
I realize that my "demands" are a little extreme, especially for a language with a smaller community like Haskell, but I was hoping that someone out there could be of assistance to me. In the mean time, I intend to simply try and ride out wxHaskell or qtHaskell until I succeed or die.
I hope I'm not coming across as gruff or frazzled.
wxHaskell is good, yes, and my go-to GUI middle level library. I admit there's been a focus on updating the code before the docs in the new version.
For modern, functional-reactive-programming fun stuff on top of it I gor for reactive banana, which is actively maintained, and has the added benefit that Heinrich Apfelmus himself may well turn up here to answer your questions.
Threepenny-gui is the most recent contender in the space of Haskell GUI libraries.
Its main selling point is that it is very easy to install, because it uses the web browser as a display. It's also easy to get started with.
On the other hand, it doesn't even attempt to have a native look and feel – the UI is built solely on HTML. (This may change in the future, as we have the option of using XUL). Also, the API is still very much in flux, so be prepared that new major versions of the library are likely to break backwards compatibility. (On the other hand, this means that it's actively developed. :-))
(Disclosure: I'm the author / maintainer of the threepenny-gui package.)
I feel your pain; this answer is an attempt to provide some alternatives that may be good enough and perhaps help you with your search.
First, there is a language called Concurrent Clean. It is supposed to be similar to Haskell, has GUI support and is meant for writing real-world applications. It differs in some respects; for instance, its I/O is based on unique types rather than Monads, which as far as I'm concerned, is a good thing :). Here is a link:
http://wiki.clean.cs.ru.nl/Clean
Next, I dug around for a Haskell compiled to the JVM, in the hopes that it would piggy-back on the Java libraries, ala Clojure. No dice. What I did find was a SO thread discussing the lack and the challenges thereof:
Haskell on JVM?
From that thread however, two other options were brought up. One is Frege:
http://code.google.com/p/frege/
The other is CAL:
https://github.com/levans/Open-Quark
There's also work on functional reactive programming in Haskell. It's supposed to enable things like GUIs, although whether or not you'll actually get a GUI out of it is another matter:
http://www.haskell.org/haskellwiki/Functional_Reactive_Programming
It's sad. Here we have the JVM and .NET and yet zilch for Haskell. It's worse than that; .NET has shown an alarming tendency to ditch promising implementations. Whatever happened to IronScheme, IronLisp and IronHaskell? All dead as far as I can tell.
Not good :(
I'm a fairly advanced hobby programmer. I consider myself capable at Objective-C, Java, some straight C, Python, and general MVC design.
I've written quite a few programs but they have all been relatively self-contained, using external libraries occasionally.
When reading about larger projects, and/or more complicated programs, I hear a lot of language thrown around about "Writing one part in X, and writing this part in Y."
Since I have a lack of experience with this, I was wondering if someone could point me in the right direction. What general designs/mechanisms are employed for applications or projects written in more than one language? What is involved in a "scriptable" design?
Thanks for any guidance on the topic!
-Chase
There is no single "right way". A multitude of approaches exist, including the .NET-way, where all the languages are hosted inside a common runtime environment with well-specified interoperability constraints, and a good old Unix-way, where all the components are supposed to communicate via pipes or sockets, using simple text-based protocols.
For the latter you can read a classic book: http://en.wikipedia.org/wiki/The_Unix_Programming_Environment
Depends on what you need to do. For example if you want to build a poker game online then, most probably you would use java for the application and flash/flex for the interface. Java has the power of the libraries and the flash/flex are quite generally available and offer a rich interface.
If you have a software that receives input from an online application and offers output on a specific output (label printer for example) then your online-ready software (Java/PHP/Python) would best communicate with a specially designed program on the target computer. A program for which I'd use C++ for it's technical power, rigurosity and speed compared to java.
The idea is to identify the languages that suit your purpose best. In my opinion it is ideal that you use one language to do all the stuff, that is why I like java as it seems to fit everything although it has a more or less bad renown for slowness.
I see things in a kind of this way:
1. Engineered, machine oriented stuff then it is C++ (and languages of it's kind)
2. Mobile multifunctional stuff (middle-ware mainly) Java
3. Online , browser based stuff PHP especially for B2C(people oriented) applications
4. Python,Ruby etc are from my point of view somewhere between java and PHP but I never really worked with them so I can not give an exact opinion
You can link them together depending on your needs.
Is VCL dead, or does it have a future as a GUI library? As CLX ended, is there any chance for cross-platform support in future releases?
I've had to do some work with legacy app that uses Borland's VCL(BCB6). Now that new features have to be implemented, it's necessary to revalue alternatives. Whether to stick with VCL or migrate to some other library/framework.
I've never read much what's happening in the field Embarcadero(Borland) tools. At least there seems to be only few VCL tagged questions here in SO and no much luck with google either.
Whether to continue using VCL in your project, or migrate to an alternative depends alot on your requirements. The VCL framework is powerful and mature, with lots of 3rd party components, which makes it a good idea to consider. The alternatives have been improving rapidly, and to point out one as the ultimate choice really requires you to carefully consider your requirements, and validate the strengths and weaknesses of the different frameworks.
Considering that cross platform is on the road map, I remind you that so has 64 bit support been for quite a while. We might see cross platform support, perhaps on schedule, perhaps delayed as we have seen with many previous features. I want to believe its coming because I truly like the VCL framework, but I always have a natural doubt concerning the official road map of the RAD studio series - sorry David. ;)
If you've researched the different alternatives, and found VCL to be the best choice based on its relevance to your project, then I'd consider using the VCL framework, especially if it is a framework you are familiar with. Learning a new framework can - while often a good idea - be a time consuming job. So even though there might be a risk of the framework not being held alive (as will there be with any alternatives) you might save a lot of work staying with the familiar framework, if it is the framework that suits your project the most.
If you do consider going with C++ Builder and the VCL, you might find that the C++ Builder Journal is a valuable source of information, they have a relatively quite forum, but with some interesting posts in it, and some free hints on their website: www.bcbjournal.com.
Of course there is also the embarcadero forums, and this site, it may be a good idea to search the Delphi forums and categories, since it seems there are more active users on these, and by far more posts. One good thing though, is that conversion from Delphi to C++ in VCL related questions is quite simple.
VCL is undergoing continued development.
Cross platform is on the current roadmap.
The embarcadero forums are still a valuable resource.
As a user of VCL I must say that your observations are truly correct. VCL might appeal to you, but the resources available compared to QT and other toolkits is poor at least esp. at SO. Our team have also found several bugs in their components, and have more than once patched components to make our application stable. Still for me the main reason to migrate is that VCL locks you in with a single set of development tools. I must admit that I have a hard time trying to find any really good reasons to continue to use it if you have the resources to migrate.
Given that bcc32 and its libraries is also very buggy, the lockin gets even more serious, The last months me and my team have spent more time fixing issues caused by the compiler than actually developing features. For me this is such a serious impediment that its cost overweight its benefits tenfold. Unfortunately the costs of migrating for us is so high that we at least for now have to endure its pains.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was certain that somebody would have specifically asked this question, but from what I can see no-one has (there's been a question about learning win32 but that doesn't cover whether it's worthwhile doing so).
I am very interested in gaining a deeper understanding of all the systems I use (I mostly program in C#, at least professionally), so I wondered, very simply - is learning win32 worthwhile, or is it overkill? Am I wasting my time? Is the knowledge I'd gain worth the effort?
Similar / related questions on StackOverflow:
Does it still make sense to learn low level WinAPI programming?
How relevant is Win32 programming to modern professionals?
Having a working knowledge of how Win32 works at the lowest level will certainly be invaluable if you are planning on doing Windows development in the future. It gives you a level of insight into things like Windows, Messaging and GDI that are hidden by the time you get to the level of .NET.
I wouldn't recommend you try and use Win32 for writing all your applications, but I feel that any Windows developer would benefit from writing a simple Win32 application using C/C++.
This is less true for things like WPF where there is less dependency on Win32, but just knowing how Win32 works will help you understand or appreciate some of the design decisions in WPF.
I advocate learning the concepts behind low level windows programming if all of the following are true.
You are going to do any windows programming.
You want to be the "go to" guy when the unexplainable happens.
You love to learn.
Abstraction layers like .NET work create and allow developers to do incredible things without having to know a lot. However, when .NET is used in a way unanticipated by its authors which reveals one of its subtle bugs, then that is the time where some win32 API knowledge goes a long way.
Will you ever have to write a message pump? I doubt it. Can it help diagnose problems? You betcha!
The question is much like, "Is learning assembly worthwhile"; and the answer is the same:
"Yes, because you will understand the fundamentals, and be able to perceive deeper than those who only work at the top level of abstraction".
However, by the same token, you probably won't be writing Win32 API directly 99.5% of the time.
When they invented C to replace assembly language, people where probably asking: "is it worthwhile to learn assembly language?" The value in knowing both was being able to drop to assembly to do the things which were impossible to accomplish in C (eg. trigger an interrupt).
The same can be said for Win32. There are some things which are impossible to do in C#. If you didn't know the win32 api, then you would dismiss some things as being impossible. However, once you know what you are missing, in those rare situations, you would be able to "drop to win32" and do them.
Another way of looking at it is this: programming is all about being able to think in multiple levels of abstraction at the same time. For example, if you know your language uses immutable strings, you don't write an algorithm that adds a single character to one 10000 times, because it will be slow. If you know the win32 api, you will be able to think about how each line you write in C# is actually implemented and that will help you write better code.
At least for me, learning an API (I'm assuming that "in-depth" is implied) that I don't use is a waste of time. I'd rather spend my limited amount of time and brain power learning new concepts or exploring new tools than becoming intimately familiar with an existing tool that I don't need to use now. When I need a particular tool that I don't have or have to use a tool that I'm not familiar with, that's the time to learn it in some depth. Before that I might do enough investigation to know whether it is going to be useful to me or not, but not much more.
Yes, the principles of the Win32 API are useful to learn - these principles are the foundation on which everything else is built.
The .NET APIs for GUI development, both Windows.Forms and WPF, do what they do within the constraints of what is possible on top of the Win32 API. Key architectural decisions of these frameworks were constrained and informed by the Win32 API.
On the other hand, you are less likely to get a lot of value from diving deep into the API, as there is a lot to learn, and given that you spend most of your time working in C#, you'll have less opportunity to use the knowledge directly.
BTW, the same applies to other technologies as well - like networking, cryptography and hardware design. Learning the fundamentals will help you become a better developer.
Yes, you should learn the basics of how Windows (a lot of this stuff predates Win32) operates. Why? For the same reason as I understand how a mortise and tenon joint operates, even though I don't make my own furniture, or why I understand how an internal combustion engine works even though I don't do my own car maintenance.
You work at a higher level of abstraction, which is nice, but when that abstraction leaks - that's not an "if", that's a "when" - if you don't understand the basics of Windows, you'll be lost. If you don't know at least some of the API, you won't have a clue where to look if you need to P/Invoke functionality not available in .Net.
Quite apart from that, isn't curiousity reason enough?
If you are trying to write a VB6 application then the Win32 API allows you to do a lot of things that are not natively supported by VB6.
If you're writing a C# WinForms app then I would recommend learning the vast reaches of the .NET Framework first.
Edit
If you really want to know what's going on under the hood in Windows then you might want to check out a copy of Programming Windows 3.1 by Charles Petzold.
I personally think it's still worthwhile learning the Win32 API.
As far as I recall when I started learning Win32 (after doing some VB(A), Pascal, etc.) I learned a lot about Windows and understood how thing works in Windows. Everything was so clearer. :)
So, as per your question - you will learn a lot about Windows through learning Win32.
As you said - you're a C# programmer and I'm not sure if you'll use it often, because almost everything you need is already there, in .NET.
I won't repeat over and over what the others said many times already.
Here's a link to a Win32 tutorial with which I am currently learning along the basics of Win32's. I find it pretty interesting and easy to follow.
This tutorial helps me get what I didn't understand first, back when I've begun to program in my secondary school years.
If I were to start today, I wouldn't learn the entire API. However, I do think that the basic concepts are important to understand, with an understanding of how message loops work as the top priority.
You'll never be able to just "learn" the entire win32 API, it's too much to take in, and it will be a moving target. If you develop in C#, there's no real point.
That said, try creating Notepad using plain C and just API calls. That will teach you enough for a C# developer to at least appreciate it.
A lot of the "No" answers here seem to focus on learning the actual methods, structs, and what not available in the API. I'd say yes, but focus not on the individual components of the API, but the overall design and the way it functions. It's much easier to troubleshoot even .NET code when you understand what's happening at the core level of the operating system.
This question looks a bit dated, but I'll answer anyway.
Answer: Complicated: yes. Simple: probably not necessary.
It really depends on what you need to do. If you need to use a feature not current supported by .NET, have-at-er. But be careful, most of the coddling the Framework provides Win32 does not, and if you do something incredibly stupid, your machine WILL bluescreen.
I know when .NET first came out, I had have no interest to learn Win32, .NET was here and it was such an improvement. But the sad fact about Windows is this: all new features in Windows are implemented in native code first, period. If you want to use any part of Windows before .NET wraps it, you're either using Win32 from C++ or Win32 from C# or from VB.NET. .NET is a wrapper, for all the stuff in Win32. So if you can't wait, yes, you can Interop into the lower bowels of the OS if you'd like.
Knowing Win32 and probably one day Win64 (whatever they happen to call it) will always be a useful skill. Any whizzbang technology requires underpinnings somewhere.
.NET is implemented using win32 api, anyone wishing to possess deeper understanding of .NET would greatly benefit from having at least marginal knowlege of win32api.
In your career it will be unlikely that you will only be creating greenfield applications where you will have the freedom to choose the technology and programming languages used.
Sooner or later you will have to integrate with old code written in Win32 and C/C++. In that case, knowledge of Win32 will help, especially if you are integrating using PInvoke or C++/CLI.
Misuse the .NET framework and Win32 and your machine will blue screen? Somehow I doubt that.
The biggest value to knowing Win32 (or assembly language) is that when something doesn't work as expected and you have to debug it. The more you know about the underlying system, the easier time you will have debugging the problem.
I like to further add to this. I never formally studied Win32 API/MFC. I started using Visual C++ 4 when I first got interested in GUI programming. Anyway, I wish I kept that foundation then, as I never caught on quick enough (I was rather young then, actually), so I studied Visual Basic instead.
For some reason, Delphi never interested me even though I knew Pascal well enough, but I digress. These days, I work in IT and develop installer scripts in NSIS - and every so often I need additional functionality that NSIS doesn't provide, so I make my own plugin and to keep it quick and dependency free, I opt for Win32 API opposed to MFC or even full blown C++.
The main reason for this comment, is that my own curiosity got me hooked. I like to know more, so where is the best resource for learning the API. A book? Website?
Would MFC still be worth tackling as well? I did see a website about a fellow that develops Win32 GUI apps, in assembly! I think that is overkill, honestly, but it is compact, fast code, interesting, the concept, but I never was able to get the hang of 80x86 assembly (hell, even RISC assembly in college I never was able to do!)
I think it's always interesting to know how a system works if your work relies on it. I don't mean you should learn every bit of it, but still get a good understanding, at least to be able to search more by yourself the day you will have to.
Software is not magic - well... ok... for 99% of the cases :-)
Here is a link to an excellent article about "magical thinking" and "GUID goblins" from Eric Lippert's about that subject: It's not Magic
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have experience writing console and network client/server applications in C and C++, but I know next to nothing about using the win32 visual API, MFC, Qt, wxWidgets, etc. Where is a good place to start, and what method should I specialize in, so as to be future ready and robust?
This is a rather broad question, as programming GUI applications in Windows can be done in so many ways.
There are two main parts to developing any GUI app: the language and the API/framework. Considering you're interested in learning to build Windows GUI apps, the language isn't really a point of focus for you. Hence, you should pick a language you already know and work with a framework or API that can be harnessed by your chosen language.
If you want to use C you're pretty much restricted to dealing with the Win32 API yourself, in which case reading Petzold or Richter would be great places to start. The Win32 API can be quite daunting, but it's well worth the effort to learn (imho). There are plenty of tutorials on Win32 on the web, and there's always MSDN, with a complete reference/guide to the Win32 API. Make sure you cover not just the API, but other areas such as resources/dialogs as they are building blocks for your Win32 application.
If you want to use C++ you have all of the options that you have when using C plus a few others. I'd recommend going with the Win32 API directly, and then moving on to a known framework such as MFC, Qt, wxWindows or GTK so that you can spend less time working with boilerplate code and instead focus on writing your application logic. The last 3 options I just listed have the added benefit of being cross-platform, so you don't have to worry too much about platform-specific issues. Given that you said you want to work with Windows, I'll assume you're keen to focus on that rather than cross-platform -- so go with MFC, but spend some time with the Win32 API first to get familiar with some of the concepts.
When dealing with MFC and the Win32 API, it's a good idea to try and get a solid understanding of the terminology prior to writing code. For example, you need to understand what the message pump is, and how it works. You need to know about concepts such as "owner-drawn controls", and subclassing. When you understand these things (and more), you'll find it easier to work with MFC because it uses similar terminology in its class interfaces (eg. you need to know what "translate messages" means before you can understand how and when to use PreTranslateMessage).
You could also use Managed C++ to write .NET GUI applications, but I've read in a few places that Managed C++ wasn't really intended to be used in this manner. Instead it should be used as a gateway between native/unmanaged code and managed code. If you're using .NET it's best to use a .NET language such as VB.NET or C# to build your GUIs.
So if you are going to use .NET, you currently have the choice of the WinForms library, or WPF. I personally feel that you'd be wasting time learning to build WinForms applications given that WPF is designed to replace it. Over time WPF will become more prevelant and Winforms will most likely die off. WPF has a much richer API set, and doesn't suffer from many of the limitations that Winforms does. If you do choose this route, however, you'll no doubt have to learn XAML, which is a markup language that drives WPF applications. This technology is coming of age, and there are many great places to learn about it. First, there are sites such as LearnWPF, and DrWPF which have some really great articles. Secondly, there are plenty of quality books on the topic.
So, to sum up, once you've picked your language and tech, the path is actually quite easy. Just pick up a book or two, read some blogs, get into some code samples.. and most importantly ... write code. Keep writing, keep making mistakes, and keep learning from them.
As a final note...
In other words, Silverlight. If you don't want to go the MS route you might give Adobe's Flash/Flex a look see. Both Silverlight and Flash/Flex build RIA's. Which I think is where we are headed. They days of Office like apps are numbered
I don't agree at all. Silverlight is not the same as WPF. Silverlight is web-specific, and only has a subset of WPF's features. Given that the question asks for Windows GUI apps, Flash/Flex Rich Internet Apps are not really a fitting suggestion. I also don't agree that the days of Rich Client Applications (such as office) are numbered at all.
I hope that helps. Good luck :)
I don't know if I'd call it a good place to start, but if you want to be future ready, take a look at the windows presentation foundation which is built entirely for the purpose of programming GUI's for windows
My first experience writing simple GUI applications for Windows was with C# and Visual Studio. The GUI-building interface is a simple drag and drop deal that generates skeleton methods based on potential user actions. I only did fairly basic programming with this, but I imagine it would be an excellent place to start to learn the basics and extend into the more advanced capabilities as you go.
There are plenty of online Win32 tutorials:
http://www.zeusedit.com/forum/viewtopic.php?t=1218
There are plenty of compilers to choose from:
http://www.zeusedit.com/forum/viewtopic.php?t=238
I would also recommend getting the Borland Win32 SDK documentation in WinHelp file format:
http://www.zeusedit.com/forum/viewtopic.php?t=7
It only covers the bare basics of the Win32, but when starting, this can be helpful as it is less daunting and less bloated than the MSDN.
I'd never go down the Silverlight, Flash/Flex or any similar route. It does look nice, but the main problem is that the code of the engine that runs it is completely closed-box and controlled by a single company. Take, for example 64bit versions of both of those. If some new platform emerges, you won't be able to migrate your existing code to it.
For business apps, Windows Forms is very mature. It provides a gentle path from auto-generating a lot for you into allowing fine-grained control and rolling your own. There are tons of high-quality third party controls and a large body of examples, docs, etc out there. It's hard to run into a problem that someone else hasn't solved. I highly recommend acquiring some background Win32 knowledge (e.g. Petzold) as the WinForms framework lives on top of it.
I have no WPF experience, but from the sample apps I've seen it looks like a good choice for apps whose interfaces would benefit from more graphical metaphors. So if you're doing a banking app, probably not worth the extra design overhead. But if you're doing, say, a warehouse management app it could be improved by dropping pretty boxes into pretty bins.
#StephenCox: wrong answer to the wrong question. OP is asking about desktop client apps, and moreover, WPF != Silverlight.
For a simple starting point to get your head around the "event-driven" nature basically all frameworks are created around look at FLTK.
Here are some quick starting videos Link
For professional use I'd recommend Qt, expensive but often worth it in commercial situations.
Since you are already familiar with C and C++ I would recommend learning how to write a simple Windows GUI app using Charles Petzold's book. It will give you the fundamental understanding of how Windows works. It's good to understand that most everything that you see is a window (a button is a window for example) and that these windows respond to messages. I wouldnt' spend a lot of time on this though and you don't necessarily need to do this first if you are going to chose WPF. I just think it's good to have a basic understanding of this.
There was a good podcast recently on .Net Rocks called "Kate Gregory Develops in C++ for Vista!" on there she recommends that someone starting out now should not use/learn MFC (even though it has been recently updated).
As far as getting ready for the future you need to learn WPF, but it isn't complete yet, so depending on the kinds of client side apps you want to create, you will probably need to learn WinForms. The majority of people aren't using WPF yet, so it's a good time to start learning. I think you will find it easier using C# to learn it instead of doing managed code with C++.
Get your basics right first. Best tutorial I've found is: http://winprog.org/tutorial/start.html
After that, although the homepage is hatefully distasteful, the tutorial pages are good in content and aesthetics: http://www.tenouk.com/cplusmfcdotnet.html
Then of course there's MSDN.