Hey! Today I went to Barnes and Noble and said to myself "Now, I'm not going to buy anything. If I do, it really better be worth it." Obviously, I made a bee-line to the computer section, thumbed thru some books about AI, and then found this book.
"Hmm, hey! I've been wanting to learn assembly for a while now, and heres a book relevant to modern ASM!"
The book was pretty sweet. I have only seen disassembly in my VC++ debugger and tried to figure it out, but thats next to impossible. When I started seeing some familiar asm, and a pretty detailed tutorial on how to get started, I needed to get it. (paid ~$64 w/ tax)
So far I've read to page 34, and had a bit of trouble setting up the dev environment. I had to laugh when I finally had to open up the documentation for installation.
"Now the HLA documentation does explain how to install HLA properly to avoid these problems, but, of course, no one reads the documentation before trying to run the compiler (of course, who's reading this paragraph, right?). "
lol, that was written for me! I got stuck before I realized I needed to have a few of the MASM32 files in the root directory of HLA as the documentation details so clearly. (readme's are if you run into problems, right? ;) ) Got my "hello world" to work though.
Anyways, initial impression so far: great book, gotta re-read some parts to get it to sink in and assosciate actions with functions(?). I was saying to self initially "hey, I'm disappointed. HLA isn't ASM; Its a wrapper!" but it looks like the text is moving towards assembly and using HLA as a means to ease into ASM from a higher level language like C/C++, instead of dropping you into assembly details right away. HLA is very similar to C, so its easy to skim past how the logical operators work (&&, ||, !, <>) and most C-style statements. I hope there'll be a lot of correlation to win32!
Assembly: Everyone knows C/C++ and can write a few lines of code. But, the true guru's of code write in assembly instead for optimization, efficiency and size, and that makes you worthy of being called a computer expert. I met a coder @ Surreal who would actually disassemble & debug windows every time it crashed and do the right tweak to fix it on his machine using assembly. Some day, that will be me too!
~Slayemin
"Hmm, hey! I've been wanting to learn assembly for a while now, and heres a book relevant to modern ASM!"
The book was pretty sweet. I have only seen disassembly in my VC++ debugger and tried to figure it out, but thats next to impossible. When I started seeing some familiar asm, and a pretty detailed tutorial on how to get started, I needed to get it. (paid ~$64 w/ tax)
So far I've read to page 34, and had a bit of trouble setting up the dev environment. I had to laugh when I finally had to open up the documentation for installation.
"Now the HLA documentation does explain how to install HLA properly to avoid these problems, but, of course, no one reads the documentation before trying to run the compiler (of course, who's reading this paragraph, right?). "
lol, that was written for me! I got stuck before I realized I needed to have a few of the MASM32 files in the root directory of HLA as the documentation details so clearly. (readme's are if you run into problems, right? ;) ) Got my "hello world" to work though.
Anyways, initial impression so far: great book, gotta re-read some parts to get it to sink in and assosciate actions with functions(?). I was saying to self initially "hey, I'm disappointed. HLA isn't ASM; Its a wrapper!" but it looks like the text is moving towards assembly and using HLA as a means to ease into ASM from a higher level language like C/C++, instead of dropping you into assembly details right away. HLA is very similar to C, so its easy to skim past how the logical operators work (&&, ||, !, <>) and most C-style statements. I hope there'll be a lot of correlation to win32!
Assembly: Everyone knows C/C++ and can write a few lines of code. But, the true guru's of code write in assembly instead for optimization, efficiency and size, and that makes you worthy of being called a computer expert. I met a coder @ Surreal who would actually disassemble & debug windows every time it crashed and do the right tweak to fix it on his machine using assembly. Some day, that will be me too!
~Slayemin
By the way,
You might want to go to Webster (http://webster.cs.ucr.edu)
and visit the HLA downloads page. I've just uploaded HLA v1.58
yesterday (and this morning). Grab the HLASETUP.EXE program
and it will automatically install everything (including RadASM) for
you.
I've added several new files to the RadASM/HLA combination so
now beginners can use RadASM without messing around with
the .ini files. HLASETUP.EXE does all that work for you (hopefully,
anyway).
Good luck on your adventure.
Cheers,
Randy Hyde
You might want to go to Webster (http://webster.cs.ucr.edu)
and visit the HLA downloads page. I've just uploaded HLA v1.58
yesterday (and this morning). Grab the HLASETUP.EXE program
and it will automatically install everything (including RadASM) for
you.
I've added several new files to the RadASM/HLA combination so
now beginners can use RadASM without messing around with
the .ini files. HLASETUP.EXE does all that work for you (hopefully,
anyway).
Good luck on your adventure.
Cheers,
Randy Hyde
BTW, I encourage you to head over to
Amazon.com and share your experiences via
a book review.
Check out:
http://www.amazon.com/exec/obidos/ASIN/1886411972/102-9663888-4308123
Cheers,
Randy Hyde
Amazon.com and share your experiences via
a book review.
Check out:
http://www.amazon.com/exec/obidos/ASIN/1886411972/102-9663888-4308123
Cheers,
Randy Hyde
Randall,
About the RadASM patcher for HLA... I tried it and it stopped right after printing the first little message of what appeared to be a pathname. All of my HLA, MASM32, and other development files are on my D: drive, not my system C: drive. I think your patcher is hardcoded to look on drive C: ? Then I got stuck with a slew of HLA ini files that all appeared to be almost the same, and all calling on the nmake utility. I had to restructure everything so I still haven't got to see if your patcher works for me better than my current setup which uses the stock RadASM and a one-time manual edit session.
My RadASM setup for 2.0.3.4 works okay with building HLA DLLs and apps.... using only one HLA.ini file.
For instance, I have a splash.dll that my app calls on, and I can build it with RadASM from the HLA source, only you have to click on several build buttons for the whole process to happen. Still.... beats the console prompt!
Actually, to build the DLL, I have to click in "Go!", then "assemble". Strange, but that's what does it.
out comes the working .dll file
About the RadASM patcher for HLA... I tried it and it stopped right after printing the first little message of what appeared to be a pathname. All of my HLA, MASM32, and other development files are on my D: drive, not my system C: drive. I think your patcher is hardcoded to look on drive C: ? Then I got stuck with a slew of HLA ini files that all appeared to be almost the same, and all calling on the nmake utility. I had to restructure everything so I still haven't got to see if your patcher works for me better than my current setup which uses the stock RadASM and a one-time manual edit session.
My RadASM setup for 2.0.3.4 works okay with building HLA DLLs and apps.... using only one HLA.ini file.
For instance, I have a splash.dll that my app calls on, and I can build it with RadASM from the HLA source, only you have to click on several build buttons for the whole process to happen. Still.... beats the console prompt!
Actually, to build the DLL, I have to click in "Go!", then "assemble". Strange, but that's what does it.
out comes the working .dll file
Originally posted by CoCoTower
Randall,
About the RadASM patcher for HLA... I tried it and it stopped right after printing the first little message of what appeared to be a pathname. All of my HLA, MASM32, and other development files are on my D: drive, not my system C: drive. I think your patcher is hardcoded to look on drive C: ?
Randall,
About the RadASM patcher for HLA... I tried it and it stopped right after printing the first little message of what appeared to be a pathname. All of my HLA, MASM32, and other development files are on my D: drive, not my system C: drive. I think your patcher is hardcoded to look on drive C: ?
It's supposed to work when run directly from the X:\hla subdirectory. I'll have to verify that this is where the installation script runs it from. You should be able to manually CD into the X:\hla subdirectory and run PatchRadASM.exe from there, though.
The original *.ini files are hard-coded for C:\hla, the whole purpose of PatchRadASM is to go in and tweak those strings. BTW, the PatchRadASM program only displays the path to the console window before closing (this is actually for debugging, I probably should make it interactive). So the operation you've described is expected (at least until I clean it up a little).
Cheers,
Randy Hyde
Oops! I will run the program from within my HLA directory. Thanks.
why!!!
why!!!
Because PatchRadASM is a utility intended to be run by the hlasetup.exe program, not something I'd normally expect someone to run manually :-) I kinda figured that people who are installing RadASM manually would have read the documentation about setting up the paths.
Cheers,
Randy Hyde
I'm at the point where I'm afraid to run the RadASM patcher for HLA, either automatically or from the HLAsetup.exe program. I've got RadASM set to where it doesn't rely on makefiles to do all the build work. This might not be good, but it works. I can build HLA DLLs and Win32 apps, etc.
I think these settings are in my project file, because when I upgrade RadASM, it's not wiping out those settings. It does wipe out the HLA.ini file, though. All I have to do is go back in and change the C: to D: since that's where I do my developing.
I understand that *some* kind of default values must be set in order for software to get a kickstart and work to some degree, so this is not a problem for me. It's a problem if the build parameters get wiped out. Now, that's a mess... everything else in RadASM seems to be HLA-friendly.
My issue with having to deal with batch and makefiles with RadASM is that you have to go in and manually edit those files if you add files to your project? I could be mistaken.
I think these settings are in my project file, because when I upgrade RadASM, it's not wiping out those settings. It does wipe out the HLA.ini file, though. All I have to do is go back in and change the C: to D: since that's where I do my developing.
I understand that *some* kind of default values must be set in order for software to get a kickstart and work to some degree, so this is not a problem for me. It's a problem if the build parameters get wiped out. Now, that's a mess... everything else in RadASM seems to be HLA-friendly.
My issue with having to deal with batch and makefiles with RadASM is that you have to go in and manually edit those files if you add files to your project? I could be mistaken.
I'm at the point where I'm afraid to run the RadASM patcher for HLA, either automatically or from the HLAsetup.exe program. I've got RadASM set to where it doesn't rely on makefiles to do all the build work. This might not be good, but it works. I can build HLA DLLs and Win32 apps, etc.
I think these settings are in my project file, because when I upgrade RadASM, it's not wiping out those settings. It does wipe out the HLA.ini file, though. All I have to do is go back in and change the C: to D: since that's where I do my developing.
I understand that *some* kind of default values must be set in order for software to get a kickstart and work to some degree, so this is not a problem for me. It's a problem if the build parameters get wiped out. Now, that's a mess... everything else in RadASM seems to be HLA-friendly.
My issue with having to deal with batch and makefiles with RadASM is that you have to go in and manually edit those files if you add files to your project? I could be mistaken.
All the RadASM patcher does is set the paths to RadASM in the X:\HLA subdirectory. If you've already got RadASM running, there is absolutely no reason to run this software. As I stated earlier, the purpose of this utility is strictly to set up paths when hlasetup.exe install a virgin copy of RadASM in the HLA subdirectory. If you've installed RadASM manually, it makes no sense at all to run the RadASM patcher.
Cheers,
Randy Hyde
Those are my thoughts, exactly. But, I am only a user so anytime you or the RadASM author posts updates, I always pay close attention and follow directions so I won't screw something up. :)
:grin:
:grin: