how long did it took you to understand how to make an win32 program

[xellos]

how long did it took you to understand how to make an standard win32 program?
if i look at the tut in masm folder its a bit overwelming :eek

[ecube]

Coming from C/C++ it didnt take long at all, most of win32 programming is just calling windows API +3rd party API, and interacting with COM and other services.You shud read Icezlions tut and follow along with the sources, to get caught up. If you have no programming experience I recommend you start with visual basic and google for things, like "how to use listview control in vb" etc...

[Jimg]

It been 20 years since I tried my first real windows program, and I still don't understand it.

[dedndave]

xellos - it does appear to be overwhelming
start very simple and add one function at a time
you will find it is way more powerful than 16-bit code
it is well worth the effort
also, much of what you are learning for 16-bit does not apply to 32-bit
and, 16-bit is becoming obsolete
learning 32-bit code will be time well spent
just be patient and don't let it frustrate you
when your program crashes - you have to laugh about it
if you get angry, your computer will be smashed, then the 16-bit code won't work, either

[Astro]

when your program crashes - you have to laugh about it
if you get angry, your computer will be smashed, then the 16-bit code won't work, either

:lol  :cheekygreen:

Read the Iczelion tutorials. Take your time, read each line in turn, and understand it. You will then wonder what you were worried about when you reach the end!  :U  I was  :dance: after I spent a couple of hours on it.

Best regards,
Astro.

[BATSoftware]

Took me a few hours, but then I came from the VMS world so the concept of DLLs (Shared images inreality) and systems programing was just a matter of locating which routine wasneeded. I also knew GEM back way before Windows even existed. Just keep in mind Windows API is just a bunch of subroutines that Microsoft didnt want to document and today do everything in their power to hide from you. Nevertheless, WINAPI is still Windows...not .NET, not C# not Java not OLE/COM. All those "technologies" are nothing more that layers of crap piled upon the WinAPI.

One thing special about Windows programming vs console programming....Message quege!!!!! Windows is driven by the sending and receiving of messages. These messages are reflected in Visual Basic by the varous event routines a particular control responds to, or to the various events a COM control will issue. In short Windows is event-based. This differs from traditional mainfram/DOS programming which is linear and only responds to events when a special event system is constructed (ie interupts, interprocess status bits and so forth).

[Farabi]

6 month.
I studied it by modificating a working example, cut the procedure into a tiny procedure, and rearrange it to see if it will work.

[dancho]

After reading first 3 chapters from this book :
http://www.charlespetzold.com/pw5/index.html
it tooks me a few hours ( knowledge of C and masm required  :green )...
I'm highly recommend it...

[arroso]

coming from 8/16 bits pc asm and years of mainframe HASM once I found a precious WinApi hlp file
(a huge one of W2K times) and met Radasm and Iczelion, it all shaped up.
For a couple of years played on a heavily customized Win98 on a PIII and enjoyed "pairing" anything I could :D
Then switched to Win2K (still today) and have some fun with multithreading and 3D.
Right now my answer is "I don't know!". 2D it's ok - Ultrano libraries were a great starting point - but 3D could be a pita
on the long run.

@BATSoftware  100% agreed. Although both IMS and Win msg queues have affinities.

[hutch--]

 :bg

Nevertheless, WINAPI is still Windows...not .NET, not C# not Java not OLE/COM. All those "technologies" are nothing more that layers of crap piled upon the WinAPI.

Yes, for all the "gee whiz", gooeys and the like, its all good old fashioned procedural programming based on the Windows API.

[ramguru]

...not .NET, not C# not Java not OLE/COM. All those "technologies" are nothing more that layers of crap piled upon the WinAPI.

DirectWrite & Direct2D are next generation API for 2d graphic & text rendering. And all those API can only used through COM interface. So OLE/COM is not another layer .. which core is WinAPI, it's an independent layer of procedures (that interacts with hardware in this case) that you can take advantage of or ignore.

[Slugsnack]

i wasn't aware java had winapi at its core either..

[dedndave]

it would seem logical that java uses win api calls to do it's tasks
.net - i am not so sure - certainly, much of it is api
but, because it comes from ms, they could have added low-level functions not available through api calls
i have no idea what they would be, though - lol

[Rockoon]

.net - i am not so sure - certainly, much of it is api
but, because it comes from ms, they could have added low-level functions not available through api calls
i have no idea what they would be, though - lol

The source to most of the .NET framework libraries is available, and is even source-level debuggable under .NET (step right into the framework libraries while debugging)

I don't know why .NET gets such a bad rep here. Its actualy very nice for what it is. Sure, its not at all powerfull from a low-level programmer standpoint, but its extremely powerfull from a high-level programmer standpoint. C# is winning over C++ programers in droves because its got all the good things that template programming allows (generics, first class functions, anonymous functions, etc..) without the need for an insane preprocessing language and without much sacrifice in performance. It is almost exactly what C++ should have been, and probably would have been if C++ didnt start off as a preprocessing hack for C compilers.

[Slugsnack]

it would seem logical that java uses win api calls to do it's tasks
.net - i am not so sure - certainly, much of it is api
but, because it comes from ms, they could have added low-level functions not available through api calls
i have no idea what they would be, though - lol

wouldn't make much sense for java to use winapi. i mean i THOUGHT it didn't because it ran multiplatform so the point would be that there was no dependency on any particular architecture/operating system