Thread: Ready for Windows?

  1. #16
    MFC killed my cat! manutd's Avatar
    Join Date
    Sep 2006
    Location
    Boston, Massachusetts
    Posts
    870
    No, I was saying C# was ugly, but agreeing that it was very popular. And it is ugly.
    Silence is better than unmeaning words.
    - Pythagoras
    My blog

  2. #17
    semi-colon generator ChaosEngine's Avatar
    Join Date
    Sep 2005
    Location
    Chch, NZ
    Posts
    597
    Quote Originally Posted by manutd
    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!

    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?

  3. #18
    MFC killed my cat! manutd's Avatar
    Join Date
    Sep 2006
    Location
    Boston, Massachusetts
    Posts
    870
    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.
    Silence is better than unmeaning words.
    - Pythagoras
    My blog

  4. #19
    Registered User
    Join Date
    Apr 2003
    Posts
    2,663
    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).
    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.
    Last edited by 7stud; 01-14-2007 at 09:35 PM.

  5. #20
    Registered User
    Join Date
    Apr 2003
    Posts
    2,663
    I've got the Petzold book across the room waiting for me
    Can you look at it and see if it has anything on sockets programming, e.g. connecting to the internet?

  6. #21
    Registered Usurer
    Join Date
    Apr 2005
    Location
    upstate NY
    Posts
    79
    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?

  7. #22
    Registered User
    Join Date
    Apr 2003
    Posts
    2,663
    Of course I don't understand any of it but I'm sure you will, check it out.
    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.
    Last edited by 7stud; 01-15-2007 at 04:11 AM.

  8. #23
    Its hard... But im here swgh's Avatar
    Join Date
    Apr 2005
    Location
    England
    Posts
    1,688
    Great pun 7stud.

    Nothing is ever simple in programming
    Double Helix STL

  9. #24
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    Quote Originally Posted by manutd
    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.
    There's different kinds of programmers.

    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

  10. #25
    Insane Game Developer Nodtveidt's Avatar
    Join Date
    Nov 2006
    Location
    Isabela, PR
    Posts
    105
    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")

  11. #26
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    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.

  12. #27
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    Quote Originally Posted by Mario F.
    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.
    thats indeed another argument, that's why I said:
    "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.


    Quote Originally Posted by Mario F.
    I'm also not sure if I should care on how windows works.
    you shouldnt if you dont want, but there are people out there who do like to know things.
    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

    Quote Originally Posted by Mario F.
    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.
    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 course

    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

  13. #28
    MFC killed my cat! manutd's Avatar
    Join Date
    Sep 2006
    Location
    Boston, Massachusetts
    Posts
    870
    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.
    Silence is better than unmeaning words.
    - Pythagoras
    My blog

  14. #29
    Insane Game Developer Nodtveidt's Avatar
    Join Date
    Nov 2006
    Location
    Isabela, PR
    Posts
    105
    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")

  15. #30
    semi-colon generator ChaosEngine's Avatar
    Join Date
    Sep 2005
    Location
    Chch, NZ
    Posts
    597
    Quote Originally Posted by KIBO
    There's different kinds of programmers.

    The one who just wants to make programs as quickly as possible and doesn't 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.
    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?

    Quote Originally Posted by KIBO
    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.
    I'm going to rewrite that to reflect the real world
    Quote Originally Posted by changes in bold
    you have to write, document and test your own library with what you hope is the right level of abstraction you can make real nice programs as fast as say a .NET language (.NET langs are pretty good, but I wouldn't hold them up as a poster boy for speed) with the added problems that you think know how it works really well but it doesn't so when problems arise you have to write and test a solution. The first group have the luxury of looking for components created by others, and since they're using common components they can search the web for help.


    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
    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!"

    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:
    1. the product works correctly
    2. as much as possible of the spec is implemented on time. (late spec changes etc, should result in dropping non-core functionality)
    3. 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?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. continuing program until ready to stop
    By jlmac2001 in forum C++ Programming
    Replies: 2
    Last Post: 01-19-2003, 07:19 PM
  2. Am i ready for openGL???
    By tetra in forum Game Programming
    Replies: 9
    Last Post: 01-14-2003, 05:19 AM
  3. trim string function (code)
    By ipe in forum C Programming
    Replies: 9
    Last Post: 01-06-2003, 12:28 AM
  4. Is Linux ready to enter the desktop market?
    By carrja99 in forum Tech Board
    Replies: 20
    Last Post: 11-04-2002, 01:11 AM
  5. Am I ready????
    By aresashura in forum Game Programming
    Replies: 12
    Last Post: 12-20-2001, 11:08 PM