Related
I'd like to learn how to write application for Mac OS X.
Like how to use XCode properly, Cocoa syntaxes and examples, etc.
I'm already a web developer using ruby, php, mysql, rails, etc.
I looked through google quite some times but never found something palpable to learn from.
But I really want to make my own application, for fun and maybe business later.
Thanks a whole bunch for your tips!
Aaron Hillegass's book "Cocoa Programming for Mac OS X" is certainly up there. It would also be well worth your time to learn the C language well.
To jump right in as quickly as possible, I'd recommend going through the following Cocoa Dev Central tutorials:
http://cocoadevcentral.com/articles/000081.php (C)
http://cocoadevcentral.com/d/learn_objectivec/ (Obj-C)
http://cocoadevcentral.com/d/learn_cocoa/ (Cocoa part 1)
http://cocoadevcentral.com/d/learn_cocoa_two/ (Cocoa part 2)
http://cocoadevcentral.com/articles/000082.php (Style part 1)
http://cocoadevcentral.com/articles/000083.php (Style part 2)
Once you've read those, you should be able to do quite a bit on your own, just using the documentation in Xcode (option-double-click on a class name in Xcode) and Apple's developer site.
You should start by learning Objective-C. Programming in Objective-C is an excellencent introduction to the language
If you're looking for a free resource this is an excellent web-site
Only after you have a solid understanding of the language would I worry about the different frameworks available.
The first thing I would start with is Automator. In fact, it's what I did start with. Solve a couple of easy problems with it, like renaming iTunes songs or photo manipulation. In the process, you'll probably think of an action you want that's not included. You can write it yourself using AppleScript.
Now you've got the basics of two desktop programming systems for MacOS in about a day. It might seem silly to learn these two super-basic systems, but in the process you'll learn the flow of desktop development and get a couple of "quick wins" in before you move on to XCode. You'll begin to think of your Mac as more than just a web client.
If I were you, I'd check out RubyCocoa next. It's a language you're already familiar with, so you'll be able to score another couple of wins here, too.
When you're ready to take on Objective-C, Cocoa Is My Girlfriend is a great introductory resource.
I would start with the currency converter sample Apple provides.
This gives a nice introduction to Xcode and Interface Builder.
You could then try to implement the same basic application but with bindings.
As you seem to have experience in some interpreted languages, you may have troubles with the memory management in Objective-C at the beginning.
You can turn on Garbage Collection to make your life easier.
If you want to use your knowledge to create iPhone apps, you should learn the memory management concepts as there is no garbage collector available on the phone.
The podcasts on the Mac Developer Network also contain some good information.
I was in the same situation some time ago, struggling to learn mac dev, read a lot of books, and it was hard for me to retain all that information, but I stumbled across CocoaCast where you can find lots of video tutorials on Mac Development! And it's totally free to watch them, even to download them.
Stanford recently put out a course on iTunes U that teaches you how to program on the iPhone. Because the iPhone uses the same programming language as OSX, a lot of what they talk about can be transferred to Mac app development. Best of all, the course is free to download and watch, and has a bunch of sample material that goes along with it. Click the link below to open it in iTunes.
iPhone Application Programming
Check out Apple's Developer Documentation, which seems to be getting more and more attention over time, and has become quite good for beginners to start with.
What resources would you recommend to pick up AppleScript. I come with a traditional C/C++ with Objective-C background.
I am also looking for tips on how to develop better and get faster documentation from the script editor. A sample tip would be 'lookup the sdef file of the app you want to script.
I learned from AppleScript: the Definitive Guide. The free documentation available online at that time was quite confusing and incomplete, but that book taught me everything I needed to know. I'm not sure if the docs have improved since then (2005-ish).
As for tips on getting documentation, the script editor's "Open Dictionary" command is about the only documentation you'll get for most applications.
I recommend Applescript: The Definitive Guide like Ryan Ballantyne. Apple's own documentation is very good: Scripting and Automation: Applescript. I would seriously recommend reading lots of Applescript code as well, this is as important, if not more important, than reading these other resources. It is important to get a feel for what makes good and bad Applescript because there is an ocean of difference in readability between the good and the bad. You can find lots of code to read in Apple's material and at macscripter.net.
If you are going to be doing any, even remotely, serious development with Applescript, I highly recommend getting a copy of Script Debugger from Late Night Software.
Apple's own Script Editor and Applescript Studio (which is simple Script Editor wrapped in Xcode) offers no debugging tools, you'll rely solely on their (sometimes esoteric) error messages and your own cowboy debugging (the "log" command). Script Debugger picks up where Script Editor leaves off—proper debugging, code stepping, code completion—and also runs scripts much faster. I can learn a lot about how a an unfamilar application implements Applescript with Script Debugger because the dictionary reader will actually give the exact syntax needed to use a command in most cases.
I agree with the folks above. Start with Soghoian's book. Very good. And then The Definitive Guide. Also, get on the Applescript Discussion list. Very good, with the author of the Definitive Guide being a major contributor to that.
And get ScriptDebugger 5. Absolutely necessary for serious Applescripting. I use it to automate Photoshop, Filemaker, and my Mac do to pretty complex things in managing photos and metadata for my employer.
Another suggestion: while reading up on AppleScript, take a look at Appscript which makes the Apple Event technology underneath AppleScript available in Python, Ruby, or even Objective-C. Why? Many people find the AppleScript language itself lacking compared to more modern languages like Python or Ruby. But whichever way you choose, be prepared for a certain level of frustration. Much of the power of Apple Events and scripting comes from the richness of the data models that AppleScript-able applications can implement. Unfortunately, every AppleScript-able application has its own implementation quirks and often there is a fair amount of hunting and pecking guesswork until you find the incantation that works for a particular operation. HAS touches on some of this here.
Appscript also provides some developer tools, like ASDictionary which exports applications' terminology as plain text or HTML files and in AppleScript or appscript formats.
http://osxnotes.net/applescript.html: notes, scripts, and AppleScript oneliners
https://developer.apple.com/library/mac/documentation/applescript/conceptual/applescriptlangguide/AppleScriptLanguageGuide.pdf
http://www.apeth.net/matt/downloads/ASTDG2Scripts.txt: example scripts from AppleScript: The Definitive Guide
http://www.amazon.com/Learn-AppleScript-Comprehensive-Scripting-Automation/dp/1430223618: my favorite book about AppleScript
http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
http://www.cs.utexas.edu/~wcook/papers/AppleScript/AppleScript95.pdf
http://dl.acm.org/ft_gateway.cfm?id=1238845&type=pdf&path=%2F1240000%2F1238845%2Fsupp%2FAppleScript%2Epdf&supp=1&dwn=1&CFID=334275816&CFTOKEN=16694215
This isn't exactly a good place to start, but the document that I found most useful was a discussion on the design of AppleScript written by one of its original designers.
It mostly talks about the evolution of AppleScript from an idea to an implementation. There's a technical part in the middle, though, that really glued a lot of things together for me. I was interested to learn that most of AppleScript's design stemmed from limitations in MacOS at the time. There's also a bit at the end reflecting on how AppleScript has fared over the years.
I'm trying to learn as well.
Currently reading http://macscripter.net/viewtopic.php?id=24729
It's really good. But the link in the post is broken, so you have to search for the next post.
And my next stop is: http://mac.appstorm.net/how-to/applescript/the-ultimate-beginners-guide-to-applescript/
I'm in the middle of AppleScript 1-2-3 by Sal Soghoian who is in charge of the AppleScript program at Apple; step-by-step, good
I am trying to get started writing scalable, telecom-grade applications with Asterisk and Ruby. I had originally intended to use the Adhearsion framework for this, but it does not have the required maturity and its documentation is severely lacking. AsteriskRuby seems to be a good alternative, as it's well documented and appears to be written by Vonage.
Does anyone have experience deploying AGI-based IVR applications? What framework, if any, did you use? I'd even consider a non-Ruby one if it's justified. Thanks!
SipX is really the wrong answer. I've written some extremely complicated VoiceXML on SipX 3.10.2 and it's been all for naught since SipX 4 is dropping SipXVXML for an interface that requires IVRs to be compiled JARs. Top that off with Nortel filing bankruptcy, extremely poor documentation on the open-source version, poor compliance with VXML 2.0 (as of 3.10.2) and SIP standards (as of 3.10.2, does not trunk well with ITSPs). I will applaud it for a bangup job doing what it was designed to do, be a PBX. But as an IVR, if I had it to do all over again, I'd do something different. I don't know what for sure, but something different. I'm toying with Trixbox CE now and working on tying it into JVoiceXML or VoiceGlue.
Also, don't read that SipX wiki crap. It compares SipX 3.10 to AsteriskNOW 1 to Trixbox 1. Come on. It's like comparing Mac OS X to Win95! A more realistic comparison would be SipX 4 (due out 1Q 2009) to Asterisk 1.6 and Trixbox 2.6, which would show that they accomplish near identical results except in the arena of scalibility and high-availability; SipX wins at that. But, for maturity and stability, I'd advocate Asterisk.
Also, my real world performance results with SipXVXML:
Dell PowerEdge R200, Xeon Dual Core 3.2GHz, handles 17 calls before jitters.
HP DL380 G4, Dual Xeon HT 3.2 GHz, handles 30 calles before long pauses.
I'll post my findings when I finish evaluating VoiceGlue and JVoiceXML but I think I'm going to end up writing a custom PHP called from AGI since all the tools are native to Asterisk.
You should revisit Adhearsion as v0.8.1 is out, and the documentation has gotten much better quite recently. Have a look here:
http://adhearsion.com
http://docs.adhearsion.com
http://api.adhearsion.com
If you're looking for "telecom-grade" applications, you may want to look into SipXecs instead of asterisk. It's featureful, free, and open source, with commercial support available from Nortel. You can interact with it via a Web Services API in ruby (or any other language).
See the SipXecs wiki for more information. There's a comparison matrix on that site, comparing features with AsteriskNOW and TrixBox.
There really aren't any other frameworks out there. There's of course AGI bindings to every language, but as far as full-fledged frameworks for developing telephony applications, we're just not there yet. At least in the open-source world.
I have asked somewhat related questions here, here, and here. I'm using Microsoft's Speech Server, and I'm very intested to learn about any alternatives that are out there, especially open source ones. You might find some good info in the answers to one of those questions.
I used JAGIServer extensively, even though it's not under development anymore, and it's pretty good and easy to use. It's an interface for FastAGI, which I recommend you use instead of simple AGI.
The new version of this framework is OrderlyCalls which seems to have a lot more features but since I haven't needed them, I haven't tried it.
I guess it all depends on what you want to do with AGI; usually I have a somewhat complex dialplan to gather and validate all user input and then just use AGI to connect to a Java application which will read some variables, do some stuff with it (perform operations, queries, etc etc) and then sets some more variables on the AGI channel and disconnects. At this point, the dialplan continues depending on the result of the variables set by the Java app.
This works really fast because you have a ServerSocket on the Java app, which receives incoming connections from AGI, creates a JAGIClient with the new socket and a new instance of a JAGIProcessor (which you have to write, it's the object that will do all your processing), and then run the JAGIClient inside a thread pool.
Your JAGIProcessor implements the processCall method where it does all the work it needs, interacting with the JAGIClient passed as a parameter, to read and set variables or do whatever stuff the AGI interface allows you to.
So you have a Java app running all the time and it can be a simple J2SE app or an EE app on a container, doesn't matter; once it's running, it will process AGI requests really fast, since no new processes have to be started (in contrast to simple AGI which runs a program for every AGI call).
Smee again. After migrating my client's IVR's over from SipX to Asterisk utilizing PHPAGI, I must say that I haven't encountered any other architecture that anywhere near as simple and capable. I'll be stress testing Trixbox CE 2.8 today on the same hardware I had tested SipX on earlier. But I must say, using PHPAGI for the IVR and the Asterisk CLI for debugging has worked perfectly and allowed me to develop IVR's far faster than any other company out there. I'm working on implementing TTS and ASR today and I'll post my stress test results when I can.
Simple small flexible Asterisk AGI IVR written on PHP
http://freshmeat.net/projects/phpivr
For small and easy applications I use Asterisk::AGI in perl. There are also extensions for the Fast AGI. For bigger applications, like VoIP operator's backends I use something similar to OrderlyCalls written in Java (my own code). OrderlyCalls is great though to start with java fastagi engine and extend it to your needs.
I'd like to start experimenting with Cocoa and programming for Mac OSX. I'm not terribly concerned with Objective C syntax/constructs/bheaviors at this point, but more curious as to an efficient setup on in terms of an editor and/or IDE that will get me going quickly. Is there any IDE even remotely similar to Visual Studio (since that's where I've spent most of my time over the last 7 years) in terms of it's solution/project concept? Any other tools, tips, suggestions and/or resources to get up and experimenting quickly?
I'd like to avoid a lot of the intro stuff and get into things like "If you want to create an Mac desktop application, you can use Acme IDE and set up your project like this."
I was afraid Xcode was going to be the answer! :P I tried playing around with that -- literally just getting it off the DVD and just diving in with no idea what to expect (before I even knew that you used Objective C as the language). I figured, the wise guy that I am, that I could just sort of fumble around and get a simple app working ... wrong.
#Andrew - Thanks for the insight on those config settings. Based on my Xcode first impression, I think those may help.
I'd suggest you pick a fun little product and dive in. If you're looking for a book I'd suggest Cocoa Programming for Max OSX which is a very good introduction both to Objective-C and Cocoa.
XCode is pretty much the de facto IDE and free with OSX. It should be on your original install DVD. It's good but not as good as Visual Studio (sorry, it's really not).
As a long-time VS user I found the default XCode config a little odd and hard to adjust to, particularly the way a new floating window would open for every sourcefile. Some tweaks I found particularly helpful;
Settings/General -> All-In-One (unifies editor/debugger window)
Settings/General -> Open counterparts in same editor (single-window edit)
Settings/Debugging - "In Editor Debugger Controls"
Settings/Debugging - "Auto Clear Debug Console"
Settings/Key-binding - lots of binding to match VS (Ctrl+F5/Shift+F5,Shift+Home, Shift+End etc)
I find the debugger has some annoying issues such as breakpoints not correctly mapping to lines and exceptions aren't immediately trapped by the debugger. Nothing deal-breaking but a bit cumbersome.
I would recommend that you make use of the new property syntax that was introduced for Objective-C 2.0. They make for a heck of a lot less typing in many many places. They're limited to OSX 10.5 only though (yeah, language features are tied to OS versions which is a bit odd).
Also don't be fooled into downplaying the differences between C/C++ and Objective-C. They're very much related but ARE different languages. Try and start Objective-C without thinking about how you'd do X,Y,Z in C/C++. It'll make it a lot easier.
The first document to read and digest is the Mem management guide, understand this before moving on. This is a great guide to objective-c too. Infact the developer site at Apple is very good - but you would probably want to read the Hillegas book first.
In regards to Xcode vs Visual Studio - they are different. I wouldn't say one is better than the other - Windows developers come over from VS and expect it to be the same. This is just an arrogant attitude and please don't fall into this crowd. Having used VS since the AppStudio days and Xcode for a year or so now, both have strengths and weaknesses. Xcode is something that out of the box (and especially when coming from VS) doesn't seem that good, but once you start using and understanding it - it becomes very powerful.
Also, there are a lot more tools included with Xcode et al, such as Instruments and Shark that you simply can't get with VS, unless you open your wallet, and even then IMHO aren't as good.
Anyway, good luck. I still enjoy C#, but Objective-C/Cocoa somehow makes programming fun again once you get into it...
Don't bother digging up your OSX DVD as they've released a new version (3.1) of XCode since then.
First, you'll want to join Apple Developer Connection (it's free, and you need it to access their version of MSDN) - it uses your Apple ID so if you've ever had one for the itunes store etc, it's that same username/password
Once you've done that, click on downloads, then click on developer tools, to view this page, and go for the XCode 3.1 Developer DVD
One other suggestion: If you have feature or enhancement requests, or bugs that you've run into, be sure to file them at Apple's Bug Reporter. It's the best way for developers to communicate their needs to Apple, because every issue is tracked through the system.
You might try the demo of textmate and see how you like it for working with objective-c or any other type of text really. It will import xcode project settings so you can still compile and run from textmate rather than having to go back to xcode.
Xcode is the standard for editing source files, though you can use another editor in conjunction with the command line xcodebuild tool if you really want. I used Vim for all my Cocoa editing before finally giving in to Xcode. It's not the greatest IDE in the world, but it gets the job done, and the recent 3.x releases have had some nice improvements.
The real power tool of Cocoa development is Interface Builder. IB does not generate source code like many UI tools. Instead it manipulates real Cocoa views, controls, and objects which it then bundles into an archive (nib) that is loaded by your program at runtime. Most Cocoa programs use at least one nib file, and often many more.
No matter what IDE/editor combination you choose for hacking on source files, I recommend using IB where you can. Even if you're not a fan of other UI layout/generation tools, I suggest keeping an open mind, giving "the Cocoa way" a chance and at least learning what Interface Builder can do for your development process.
AFAIK, pretty much every OS X developer uses Xcode.
That, and Interface Builder for creating the GUIs.
FWIW, try to get hold of a copy of Hillegas's book, as it's a great introductory tutorial, and the reference Docs Apple provides really aren't. (They are generally very good reference docs, however).
Cocoa is huge. The hardest part of learning how to write apps on Mac is learning Cocoa. By the way. You do not need to know ObjC (though it helps tons). You can write Cocoa apps with Python or Ruby (right in the IDE).
I agree VS is a better IDE then Xcode. But if you throw in Interface Builder and all the other tools, I'm not so sure. Mac development is not about 1 giant IDE for everything. But VS is "kinder" on the developer then Xcode is.
Also if you want to do cross platform apps look at RealBasic. A fine tool (Basic though. But it runs on Linux too.) You'd be surprised how many Mac apps are written with RB.
I've heard the books currently out there are pretty out of date. The whole ecosystem seems to evolve very fast with dramatic changes made in every OS release.
He wrote a tutorial which pulls together some Apple documentation and other tutorials which should get you started. I think it covers the basics of using the IDE, writing simple apps, and then goes on to more advanced stuff.
I've been dabbling in Cocoa for the past couple years, and recently picked up Fritz Anderson's "Xcode 3 Unleashed." Highly recommended for getting into Xcode — especially with some of the big changes 3.0/Leopard brought.
Don't forget Hillegass' defacto Cocoa bible, "Cocoa Programming for Mac OS X - Third Edition."
#peter I don't know why you had trouble with getting a simple app working, right off the bat without doing anything your app gets a lot of benefits from the Cocoa framework. If you mean you were trying to do stuff like connect a button to an action and have it print a alert on screen or something like that then yes I could see where your going with it being difficult.
The problem for me starting with Cocoa many years back is that it was so different from anything else that it had a little bit of a learning curve. Whereas many other systems are compile time oriented Cocoa is very dynamic and runtime oriented. Once you get past learning how actions hook up to classes it just becomes a matter of learning how the Cocoa frameworks work.
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.