Ready for Windows?

How much time do I need to spend on console programming before getting into Windows?

- or to put it another way -

What skill set is necessary to begin Windows programming?

I've been working at this on my own in my 'spare time' for a while now but I'd really like
to start working with MIDI on some musical applications. It seems like that requires some understanding of Windows programming and the 'MIDI API' whatever that is. (Already got the link, thank you - )

I've got the Petzold book across the room waiting for me - how much dues do I have to pay? How long do I have to stare at the black rectangle??

-JM

I think after a two years if you are a quick learner, or three-four if you are a little slower, should be fine. It's really not that hard, you just have to get used to a little different way of thinking (aka in messages).

Windows is just an API (you'll learn many APIs in a programming career).

Once you have the basics of C++ (like simple classes, some inheritance perhaps) and some bits of the STL, then you should be able to make a start. Experience with both will grow in time.

> How long do I have to stare at the black rectangle??
Forever (perhaps).
I still test new ideas out in simple console programs because they avoid all the fluff which comes with producing even simple "hello world" in a windows program (even with wizards).

Every algorithm and technique can be tested out (and learnt) at the console prompt.

Same here, Salem. I often test my algorithms and down low stuff in the console first to eliminate another level of complexity (the Win32 API), then put the code I know works into a pretty GUI window.

Hence the reason we all love and adore console. It's quick and simple(ish) for test programs

Quote:

---

How much time do I need to spend on console programming before getting into Windows?

---

Windows programming is a jungle. And the first time you enter, you'll get eaten alive.

>> Windows programming is a jungle. And the first time you enter, you'll get eaten alive.

It killed me ... it's deadly. Pits of despair. ROUS', lightening sand ... but I mainly lost patience. Not to say I didn't enjoy what I learnt, but didn't see the need for myself to learn it so wasn't really motivated to expand what I had learnt. Will pick it up again if I have time.

wxWidgets ftw.

Quote:

---

Originally Posted by Wraithan

wxWidgets ftw.

---

Couldn't have said it better. And... it's portable!

I also vote for wxWidgets. That being said, knowing the Win32 API will help you if you decide to persue this as a career.

Quote:

---

Originally Posted by manutd

I also vote for wxWidgets.

---

Me too. It's a much cleaner API, portable and it has a python binding too! However, compared to win32/mfc, almost no-one uses it.

Quote:

---

Originally Posted by manutd

That being said, knowing the Win32 API will help you if you decide to persue this as a career.

---

While I partially agree with this, I'd say that a large majority of new GUI application development on windows is now being done in C#, and quite rightly too. Win32 is one of the worst API's ever inflicted upon developers.

Bottom line:

• if you want to develop your own GUI programs on windows, you may as well use wxWidgets (it's better than Win32 and x-platform)
• if you want a job programming windows only GUIs, learn C#
• if you want to spend the rest of your life maintaining someone else's unreadable c code, Win32 is the API for you!

People do still use the Win32 API, but you are right about C# (ugly, ugly, UGLY). However, I like the seemingly lower level view that Win32 gives you. To me it seems that when one has a Win32 backround, one is better educated about how Windws works. But hey, that's just my two cents.

Since I already dropped the $$$ for Petzold I plan to work through it, but I'll definitely check out wxWidgets - if they based Audacity on it then it must be the shizznit.

Thanks guys, guess I'll - GULP - venture into Windows.

Also look at the links on top of the Windows board, particulary theforgers tutorial. Remember that MSDN is your most valuable resource.

> To me it seems that when one has a Win32 backround, one is better educated about how Windws works.

Partially, since the Win32 API is in fact an interface API, consequently just another framework. The windows native API is a much better choice if one wants access to the nuts and bolts of Win32. However, I'm not sure if the win32 native API is as broad in scope as the win32 API. Certainly not the documented bits.

ChaosEngine meanwhile was using ugly when referring to the win32 API, not C#. And quiet rightly so. Maybe not so much for what it offers, but for how it was presented to programmers. 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). All to the point of Microsoft being forced to develop MFC (a framework on top of what was already essentially a framework) to put some order in the chaos... which, didn't really help.

With the .Net framework becoming a de facto standard for windows programming, the windows API is now finally losing its importance... or visibility, if you want. Solutions like WxWidgets are now ever more interesting since they are no longer the third choice for windows development, but the second.

No, I was saying C# was ugly, but agreeing that it was very popular. And it is ugly.

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! :D

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.

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.

Quote:

---

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.

Quote:

---

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?

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.

Quote:

---

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.

Great pun 7stud. :)

Nothing is ever simple in programming

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

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.

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.

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

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. :D

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.

---

:D

Quote:

---

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

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

Quote:

---

Make it work. Make it work RIGHT. Then, make it fast.

---

Sure, you'd use all available resource's at work in order to get the job done, but at home or as a hobby I think it's very valuable to learned old but more efficient ways of doing things. Sure they take longer to develop, but in the end the greater understanding of other ways of doing things is a benefit to the coder in the long run. Hence why I learned assembly. There aren't that many practical applications (very low level kernel dev, some device drivers) but it helped me to get a greater understanding of how computers work.
Some say that you don't need to understand how things work at a base level. I disagree. In the end, one needs to understand the technology behind the magic of compiling a text file into something that runs on a screen that you can interact with. Even if you don't interact with the electricity running through your machine, you owe it to yourself to learn the infinitely complex mechanisms behind the things you see. Without this, all we have in programming is a couple of lines of text and repeating the same thing over and over again. How fun.

I could never wrap my head around how all the gates and switches and such made my application work... And I don't have to, I am a programmer the silicon is the EE guys job to understand and improve. I don't know Win32 aside from the basics to get a window up and going and accept keyboard input so I can put an OpenGL window in it and have fun. I can do a fair amount with wxWidgets and compile it on my Linux box or my Windows box (still want to get a Mac Box, just to play with.)

Learning some assembly is on my list of stuff to do eventually. I understand the basics of different pieces of code produce more or less instructions, which is all I really need to know as an applications programmer.

The argument that you get a more intimate knowledge of your system by using a lower level API has ground, but if that were the reason for using an API, then you need to switch to Linux, and play around and really be able to look under the hood to see how the nuts and bolts go together. Overall I find this debate silly, learn what ever API intrests you, same with programming languages, learn what ever you want to, the only time when you need to learn something without wanting to is in classes or for a job.

Something we should keep in mind is abstraction is part of the point of all these APIs and Languages(which I guess could be considered a form of API :D) to keep us away from reinventing the wheel to do the same thing, some of them allow use to abstract to a point where operating system doesn't mater, which is where I would love things to be, be able to use what ever OS I chose to and no be giving up loads of software.

I seem to have gotten side tracked, oh well, I think my point(s) got out there.

And of course I realize that it's not needed to understand switches to program. But I think that to be an excellent programmer, it helps to no that with which you are working. And I can't help but be interested in how my C++ code gets translated to assembler, then to an executable which is than executed and is handled by an OS, sending it to the CPU. Eventually my instructions in something I understand turn into a series of electrical signals running through tiny pathways. And if a somewhat outdated API shows me this, then fine. I will use what is expected of me on company time, but after (or before) that, I can (and will) experiment, because for me that is the essense of programming.

It's all personal preference in the end, y'all. Some people choose to focus on product production with the end justifying the means, some people choose to become more balanced programmers at large. Not every end-product programmer has to be a low-level wizard, and not every to-the-metal programmer has to put out commercial-grade applications for general consumption. It's all about what you want to do.

Quote:

---

Originally Posted by ChaosEngine

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.

---

Thats exactly the first group.

If you wanna add a third group then it would be the hacker kinda guy who uses all kinds of components to get the job done but who can, *when* needed, create such components himself because he knows the basic building blocks.

This whole conversation is becoming ridiculous.

Separating all programmers in the world in two groups is... just stupid.

KIBO, I really like your definition somehow. :)

Quote:

---

Originally Posted by Mario F.

This whole conversation is becoming ridiculous.

Separating all programmers in the world in two groups is... just stupid.

---

no, if you look at other aspects of programming theres of course endless groups!
Considering the discussion about a low level graphical windowing system API, dividing programmers in these groups is useful. If it was a discussion about designing software you could look at programmers as some who wanna design and plan everything they can and some who just start coding. But thats not really handy now in this thread is it.

Of course there's still the gay and hetero groups!

The problem with the whole reasoning is that every programmer is the "hacker type"... But hey! Let's have fan creating tags. Life is not more entertaining this way, but at least we can pretend we understand about it.

There's also another problem with the whole reasoning... and that is simply the fact no one really knows the windows API. Well, let me say almost no one in case you can come up with some round out geek. It's a thing you consult. You use when you need to, not because you like saying to your friends "look how cool I am. I program with the API. I'm an hacker, and you that don't use the API as much as I do, are not."

Of course, the fact your friends program in assembler is totally irrelevant.

Is wxWidgets meant only for GUIs?

When you use word 'API'.. Do you mean native windows functions or something else?

Quote:

---

Originally Posted by l2u

Is wxWidgets meant only for GUIs?

---

No, it has networking features, file handling, and more. Check their website for more.

Quote:

---

Originally Posted by l2u

When you use word 'API'.. Do you mean native windows functions or something else?

---

No, API means Application programming interface. Wikipedia it.