"Every time you sit down, and write a piece of code, you should try and better yourself. Don't worry about keeping up with the Jones'. Just do your best and the rest will fall into place with time." -- Chris Hobbs, in his 'Eliminating Screen Flicker' tutorial i found this tutorial when i skimmed through the files on my old cd-rw's 7 weeks ago. i must have got this file when i tried to study directx w/ vc++ about a year ago. somehow it got saved in the directx tutorials folder. anyway, that's when i decided to get serious w/ win32 assembly. those words kinda settled into my subconcious mind. i thought i'll just grab every chance i get to sit down and write asm code which is better than the last. anyway, if i just get 25% off my sleep time, get rid of my afternoon siesta, and be quick w/ my tasks at work, i could come up with 5 to 6 hours for asm everyday. easy, or so i thought. for the past 7 weeks i have tried different approaches in learning this language. i started with 'translating' the small vc++ apps i once wrote for engineering students in a university. then i tried hacking ms mplayer7 and sonique for their cool ui. of course i also did iczelion's tutorials. i'm sure they're the best there is but i wonder why it's been 1 tutorial forward, 2 tutorials back for me. now i still can't tell what it is exactly that i have accomplished as far as win32 asm programming is concerned. i'm a self-taught guitar player. after less than 2 years of learning the instrument i managed to get a job as an instructor in a yamaha music training center where i worked for 2 years. most of my co-instructors had 4 years of formal training and many more years of teaching experience behind them, and i've had some students who were already professional players for more than 5 years. i managed to do that because of one thing - organized approach. the best 3 of the books i had taught that doctrine. mastering one skill after the other, getting the most out of the shortest possible time. my first experience with programming was with pascal and c for dos in a computer college where i went. i didn't like what i was getting so i quit, got some books, e-books, and software, and started teaching myself vc++. (btw, i live in a country where you can buy from stores copies of visual studio enterprise and the whole msdn package for under u.s. $15, all 3 cd's of coreldraw 10 under $10, and 1 cd installer of all macromedia stuff for $5. each disk costs about twice the price of blank cd-r's. no one bothers making & selling copies because it takes longer.) i can say that vc++ and mfc were more of common sense than programming/technical prowess. you got lego blocks that form into a space rocket so you make a space rocket. want to make a boat? you can too, but you might want to try vb first. maybe that's why they come in one package. but the point is i learned vc++ through an organized approach (too organized, actually. i had it spoon-fed). if what i've said so far gives you the notion that i'm in such a hurry to learn win32 asm, believe me i'm not. i love knowledge and i like learning. in fact at times it's like copulation, the longer the process the better. when i say 'organized approach' it's not about how the instructional books i use are written, but rather how i am able to put the information i get from them into practice. it's knowing what particular skill i'm honing and why i'm doing it. it's knowing at what particular point in the learning process i'm in and where i'm heading. but i'm not talking about being spoon-fed either. i don't like that since it takes away the thrill of learning. in fact, i've never followed any instructional material one chapter after the other. i'd rather come up with what for me is the most logical sequence of exercises and follow it. i like the idea of being self-taught better, (although i think there's really no such thing, but that's another story). but my experience so far w/ win32 asm is different. there's this huge mass of knowledge before me. i pick som
pixelwise, Really, one day it DOES click, and your mind actually WANTS to first write a value to a register, then move the register to memory. A=B will look strange. (How can it just do memory to memory? there's no opcode for that!) Getting there does take work. Actually writing code. Making stoopid mistakes you REMEMBER and LEARN FROM. I had one advantage in learning win32asm. I already knew assembly programming from other platforms (I couldn't list how many processors I've done asm for). Be that as it may, doing win32 asm is like finally entering the big leagues, making the show, where everything is realer then real, the newspapers will write about your every sneeze in the outfeild, and if you screw up, thousands of little kids go to bed crying. I can't say AoA ever did anything for me. It's kind of pedantic, overly organized, and far too inclusive of 16 bit methods. I have zero interest in 16 bit, gimmy flat out 4 gigabite pointers or give me death! You already have the first two most importaint tools you need: Icz's tutorials, and MSDN on CD. Icz opens the door. MSDN is the flashlight you need to see what's inside. I ALWAYS run MSDN (keep it #2 on the taskbar so I can click on it wothout thought)(#1 is file explorer). Now since I've already trashed AoA for being 16 bit, it's funny I like my third choice so much: the MASM "Programmer's Reference" book. I *bought* MASM a few years back, never got it to work until I got MASM32 off hutch though. THAT threw the door wide open. Having this book always mede me feel like I had an edge over other people working in MASM. I had the secrets they needed. This book is available somewhere on this site to download. Get it. Print it out, no matter how many pages it is. Bind it up. Live with it. Take it camping with you. Read it on the toilet. It has stuff you need. And code, code, code. ----------------------- "Our lives are in the hands of men no smarter than you or I. Many of them incompetent boobs. I know this because Iíve worked alongside them, gone bowling with them, watch them pass me over for promotions time and again."
Hi. I think that is necessary to learn a little about chip (Intel or others), memory, system bus, PC architecture, etc... to program in win32asm. The AoA helped me very much with that stuff, in spite it was for 16 bit codes. I really liked that book. :rolleyes:
Chris Hobb's idea is a fundamentally sound one, forget what the scene may be and write code that you like and understand. If I get the drift of your post, you tend to go after knowledge for its value and this is a very good approach to learning asm well. Many programmers found a lot of value in Randy Hyde's Art Of Assembler and it served to keep assembler alive in a time when garbage-ware was in the ascendence but it is very DOS segmented style architecture and its use in win32 is very limited. I don't know enough about Randy's latest toy in HLA to really comment but I know its a conceptually different idea. The stuff that will come back to you as useful is the mountain of hack work necessary to learn the mnemonics and API calls and then have the practice at knowing where to find the rest. There is a scene in Europe of writing demos but starting out to write demos is doomed to failure as the amount of low level knowledge is very large, this is the same with any area in the computer game, what you are doing is the most useful to you in the long term, heaps of low level knowledge that you will be able to apply in whatever direction you wish to take. Just keep up the good work and it will come back to you it terms of capacity and ease. Regards, email@example.com
HLA is up to 1440 pages, Jan. 17, version (I read it). Then there are all of the samples, tests, source, and other stuff included. Hard to beat. No it won't appeal much to experienced assembly programmers, however for me, I frequently need several examples, written and/or explained in different styles, so I will use HLA along with anything else I can get my eyes around. I don't know if I will use the compiler. The HLA compiler will not prevent you from writing your own asm code and using it anywhere you want, but why do the drudgework on code it writes adequately, and consistently? There are some serious deficiencies (dereferencing explanation for one), possibly due to HLA still being written, or because the instructor would fill in the blanks. HLA, in a structured classroom setting (what it is written for), probably will live up to the claims of the author, by accelerating the learning curve, and allowing more material to be covered in a semester. Just my take.
Pixelwise reminds me of me. My attitude and philosophy of programming is much like that. I love when there are problems, that means I get to flex all I've learned, and learn what I haven't... somewhere along the line, perhaps from the corporate atmosphere, I've slowly started to "do it for the job"... You see, I started programming 6502 BASIC and 8-bit assembly, er, 65c02 (Apple //c - gs) when I was started. Kept it a hobby in-case doing it as a job would deter me from it. I started working as a techie for a custom laptop manufacturer (and sales)... I learned much about PC (which I haven't worked with in the past) and got to the point where I could solve just about any problem (even that senior techs gave up on)... I started college and came back to California once I couldn't continue college and started as a techie once again. I got so sick of the support position that when they needed a database done, I said I could do it... took longer than usual, but I pushed myself hard. For the next few years, I did the same throughout other jobs, except I was a programmer by position at other places. I didn't actually own my own computer until about a year and a half ago, or so. All the other time, I had to read books, books, books, books... and practice at work while I could. I digested much more and even got to the point where I could program the things in my head and then, when I would actually write, it would be like I already wrote it. Once I got my computer, my whole attitude shifted and I took it for granted. I think the more into the corporate atmosphere I got, the less I was inclinded to go where I wanted to go. All that is changing. The best approach is to do what you like and you'll do it well. In work atmosphere, it's not easy to find a place that lets you do so, they usually force you to comply with bad coding standards, and less documentation, less planning, and more beauracracy that most programmers want. But, you just have to laugh it off, I suppose. Since I'm one of few who understands (somewhat, at least) win32 assembly, that makes my a much better problem solver and much more on my efficiency, and all people recognize that, no matter where I go. The bottom line, is, when it's what you want and you can keep it alive, there are no limits. _Shawn
What Win32asm looks like to me so far:
When you start writing useful applications, some other things you'll want to know include: menus, file I/O, registry or profiles (for saving app info, like window positions). This message was edited by tank, on 3/28/2001 10:01:01 PM
storage used directly by ASM code registers in CPU memory (RAM) data types - the basics are byte, word, dword (there's no such thing as decimal, hex, or char. It's all binary) instruction types moves - loads and stores arithmetic and logic jumps - conditional, unconditional, subroutine addressing modes system stuff you're not able to manipulate under Windows this stuff includes performance issues this stuff includes what Windows uses to restrict you assembling and linking Windows programming Win32 API basic window class registration and message pump essential input (mouse and keyboard) basic window management dialogs and basic controls basic graphics ******************* Everything else !!! *******************