No, I was saying C# was ugly, but agreeing that it was very popular. And it is ugly.
No, I was saying C# was ugly, but agreeing that it was very popular. And it is ugly.
next to your average c program using win32, C# is a fricking supermodel!Originally Posted by manutd
anyway I wasn't saying people don't still use win32 api, they obviously do. However from a career point of view, if you do a search of any job site you'll see a lot more jobs for C# than win32 gui programming. Plus the majority of win32 coding is maintenance as opposed to new application development.
and while I agree that knowing win32 gives you a more intimate knowledge of how windows works, most programmers (me included) are more than happy to abstract that away behind a nice API. It's like the STL; as a programmer you should know how to implement a linked list/dynamic array/associative map, but I'm damn sure I don't want to mess around with pointers and memory allocation every time I need a container.
"I saw a sign that said 'Drink Canada Dry', so I started"
-- Brendan Behan
Free Compiler: Visual C++ 2005 Express
If you program in C++, you need Boost. You should also know how to use the Standard Library (STL). Want to make games? After reading this, I don't like WxWidgets anymore. Want to add some scripting to your App?
Of course, and I'd recommend you'd learn both. But it's somewhat the same thing as learning assembly: not usually needed, but can be nice to know.
And then there's the whole winsock/libcurl nightmare(that I have come to appreciate in the last few days), which you have to assimilate to access the internet in your programs. I assume C# has simple facilities for doing so.The naming conventions and its incapacity to evolve with time are in my opinion the two worst characteristics of the win32 API. But I could also add the lack of higher level objects capable of simplifying the most common tasks (although some may argue that's not what an API should be... I, disagree).
Last edited by 7stud; 01-14-2007 at 09:35 PM.
Can you look at it and see if it has anything on sockets programming, e.g. connecting to the internet?I've got the Petzold book across the room waiting for me
Yeah, the whole last chapter - 'A Taste of the Internet'.
Of course I don't understand any of it but I'm sure you will, check it out.
Huh?
I've made two trips into the jungle. The first time I got mauled by a tiger. The second time I was gored by a wild boar. I've walked with a limp ever since.Of course I don't understand any of it but I'm sure you will, check it out.
Last edited by 7stud; 01-15-2007 at 04:11 AM.
Great pun 7stud.
Nothing is ever simple in programming
Double Helix STL
There's different kinds of programmers.Originally Posted by manutd
The one who just wants to make programs as quickly as possible and doesnt care what goes on under the hood. For those I'd recommend C# or VB a language like that
The one who is a hacker by nature and wants to know what goes on under the hood.
I think "the hacker" would be more attracted to the win32 API and once you create your own library with the right level of abstraction you can make real nice programs as fast as say a .NET language with the added advantage that you know how it works really well and when problems arise you have solutions ready quickly. The first group would have to start looking for components created by others.
Remember that win32 was already there in 1984 or so. In that regard it worked really well. You could create graphical programs completely in C and relatively quickly too. But yeah, in 22 years a lot has changed so it's kinda outdated now but yuo can still get everything done what you want in C
Hrm I dunno...my first venture into the world of the windows API was completely successful, and I've never left the jungle. I think it's because I had an extensive background in procedural languages as opposed to OOP. To me, it seems almost vulgar to use a third-party library (like wxWidgets) for something I can do in just a few more lines of code...not to mention the huge difference in executable size and resources taken up. Sure it's more work, but for me, the rewards are worth it...fewer dependencies and smaller executable that often performs a bit better since the only overhead is what I've coded in rather than what someone else thought I might need. But then again, I left the world of professional programming years ago and now mostly only do it as a hobby, and I guess the current trend is "get this out the door as fast as possible regardless of size or resources consumed and nevermind the bugs that crawl about, we can put out buttloads of patches to correct them". With that in mind, I'm glad I left the professional world behind.
Code:cout << "Language comparisons are dumb"; echo("Language comparisons are dumb"); PRINT "Language comparisons are dumb" alert ("Language comparisons are dumb")
I've made that same transition from professional programming to hobbyist last year and I'm terrifically glad I did.
As for the Win32 API, I'm still unsure of the weight of the argument "it lets you know how windows works". Probably a better argument would be it allows fine tuning of our application access and use of the GUI interface and its services. Which probably leads to the former in a way. But still isn't quiet exactly the same thing.
I'm also not sure if I should care on how windows works. After MFC "hit the shelves" access to the windows API became largely a matter of fine tunning our application here and there or accessing those bits the MFC hadn't wrapped. The API had by then lost much of its importance. "Knowing" the windows API was as simple as accessing the MSDN documentation which was even (and still is) readily accessible offline if you had the right licenses. There wasn't really a need to know or understand the API fully or even a large part of it.
As far as I know, C++ programmers adopted the MFC immediately and the first reactions were of awe. Even later, when MFC started to be criticized, for most C++ programmers going back to straight win32 API based programming was not an option.
If anything the windows API is a poor teacher of how windows operates since it is simply an interface between the real windows and the programmer. Open systems like Linux offer better APIs.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
thats indeed another argument, that's why I said:Originally Posted by Mario F.
"and when problems arise you have solutions ready quickly". If you know how things work at a low level you can make things that do not have predefined components anymore fast.
you shouldnt if you dont want, but there are people out there who do like to know things.Originally Posted by Mario F.
I work on embedded system and the experienced guys know exactly by looking at bit patterns on certain addresses whats going on currently, if everything is al right etc. They dont have to fire up a real machine at all anymore
Knowing how and when messages are sent and who handles messages that are not handled etc etc is also a way of knowing how windows works, not just the kernel of courseOriginally Posted by Mario F.
Well yeah, if I wanna know how a kernel is written I'd go to linux, but the messaging window GUI system is quite a nice and complex system to find out
I, of course, would be the hackish type But honestly, I ventured into the jungle once, fell and love, and have been exploring ever since. I've learned wxWidgets, but as you can see, I hate MFC. I look at the Win32 API as yes, a bit outdated, but very functional and with great documentation.
I'm not a huge fan of the MFC either. As far as I know, it's simply an additional layer built on top of the windows API anyways, and I could just simply write my OWN layer on top of the windows API if I wanted to. Meh...I guess I'm just a byte-and-CPU-cycle-saving freak.
Code:cout << "Language comparisons are dumb"; echo("Language comparisons are dumb"); PRINT "Language comparisons are dumb" alert ("Language comparisons are dumb")
There's also a third type of programmer. A professional who realises that someone is paying good money for his time and it shouldn't be wasted messing about reinventing the wheel. They want to deliver a high quality product on time and as such they use code and components that are already written, documented and tested in real world apps. Can you say that about your API layer?Originally Posted by KIBO
I'm going to rewrite that to reflect the real worldOriginally Posted by KIBO
Originally Posted by changes in bold
23 years ago, most machines were still running dos, and assembly was the "only way to do real programming". And even then the win32 api was a dog. You can still get everything you want done in assembler (hell you could build a custom chip for it), but you would be insane to. Times change, tools evolve. Honestly, I can imagine a bunch of software engineers put in charge of building a skyscraper. "What? you want to buy nail guns and cranes? but that's so inefficient! look, I've already got a hammer and we can use that to build a ladder to carry stuff up!"Remember that win32 was already there in 1984 or so. In that regard it worked really well. You could create graphical programs completely in C and relatively quickly too. But yeah, in 22 years a lot has changed so it's kinda outdated now but yuo can still get everything done what you want in C
As a side note embedded programming is a completely different beast from pc programming. There you have to be much more conscious of your resource usage, so sometimes you have to tailor a solution exclusively for your product. That said, I'm working for an embedded company at the moment, and you should still prefer a library solution until it absolutely will not work.
As a software engineer your priorities should look like this for any given product:
- the product works correctly
- as much as possible of the spec is implemented on time. (late spec changes etc, should result in dropping non-core functionality)
- the product works efficiently
1 is vital. 2 is REALLY important (although 2 should ideally never trump 1, it sometimes does). 3 is way behind the other 2.
In other words
Make it work. Make it work RIGHT. Then, make it fast.
"I saw a sign that said 'Drink Canada Dry', so I started"
-- Brendan Behan
Free Compiler: Visual C++ 2005 Express
If you program in C++, you need Boost. You should also know how to use the Standard Library (STL). Want to make games? After reading this, I don't like WxWidgets anymore. Want to add some scripting to your App?