On march 2004, we introduced the first official release of ObjAsm32. Since then, thanks to your critics and feedback, we worked out a new and more powerful version and now we want to present it to you.
We set our attention to the following points:
- Model improvements and extensions to make it more versatile and easy to work with, including a new and more powerful syntax.
Library support to speedup compilation time by a factor of 30 - 70%. By this way, it is now possible to precompile all objects to libraries and link them to your projects.
Component Object Model (COM) compatibility to integrate this important technology to the OOP model. Thanks to this, we can interface i.e. DirectX, MS Speech Engine and other important SW constructs.
A complete string handling support library to handle ANSI, UNICODE and BSTR strings.
Additionally, in this new release you will find new and more powerful objects like a 3D Engine, Skin windows, GIFs, etc., a new Source Code analysis tool, a new HTML Help file and a lot of novel examples.
All the sources have been included in an installation package called OA32INST.ZIP, which can be downloaded from the http://objasm32.tripod.com website (2.5 MB).
We hope you enjoy this new ObjAsm32 release and as always, your feedback is welcome!
Enjoy programming!
Your ObjAsm32 Team
Biterider/NaN
Konstantin Usanov has found a bug in the Collection::DeleteAt object method.
The corrected file is attached at the end of this post.
The best way to compile this new object version is to use Demo12, following this instructions:
The corrected file is attached at the end of this post.
The best way to compile this new object version is to use Demo12, following this instructions:
- 1. Replace the Collection.inc file in the \Masm32\ObjAsm32\Code\Objects directory
2. Start \Masm32\ObjAsm32\Examples\Demo12
3. Select Menu ? Compile ? Object - \Masm32\ObjAsm32\Code\Objects\Collection.asm
4. Compile it
The new lib file will be generated in the \Masm32\Lib directory and is now ready to use.
Thanks Konstantin! :)
Regards,
Biterider
I suspect people are trying to learn the format and Layout of the new OOP structure. I hope there is enough documentation to give you guys the gist of it. If anyone is confused or wondering 'how to do this', please ask. It will also give us an idea of how it is received and seen from a third party point of view.
We hope people find the restructuring of the model more intuative. BiteRider did *alot* of work trying to address the various feedback that was received from v1.2.
Regards,
:NaN:
We hope people find the restructuring of the model more intuative. BiteRider did *alot* of work trying to address the various feedback that was received from v1.2.
Regards,
:NaN:
I have transcribed a simple COM example from Ernie's origional COM package to the OA32 syntax. If your looking for a very simple example of how to use COM with OA32 here is a good start:
ShortCut Example
Regards,
:NaN:
ShortCut Example
Regards,
:NaN:
Hi NaN and BiteRider
> I hope there is enough documentation to give you guys the gist of it.
I strongly doubt this. Large parts of the online help is a "reference" only. The "getting started" part is too short. A newbie will be totally lost, if you ask me. The project is good, but next steps must be to improve documentation, not new features.
Some things to improve IMHO:
- the comments in the demos are bad. In the .ASM file there are comments in "book" form, but in fact they are trivial. In the .INC files, however, which are much more important, there is almost nothing to find.
- add some simple examples for the command line. the whole project is a bit too "GUI oriented" for my taste. Dont use VKDebug in these examples, just print to the command line.
- add .MAK files so the user isn't forced to use RADAsm.
- don't use macros unless inevitable in the first and simplest examples. The macros are good, of course, but heavily usage of them tends to hide the important things. So the source looks like a bad C++ dialect, not like ASM.
Regards
Japheth
> I hope there is enough documentation to give you guys the gist of it.
I strongly doubt this. Large parts of the online help is a "reference" only. The "getting started" part is too short. A newbie will be totally lost, if you ask me. The project is good, but next steps must be to improve documentation, not new features.
Some things to improve IMHO:
- the comments in the demos are bad. In the .ASM file there are comments in "book" form, but in fact they are trivial. In the .INC files, however, which are much more important, there is almost nothing to find.
- add some simple examples for the command line. the whole project is a bit too "GUI oriented" for my taste. Dont use VKDebug in these examples, just print to the command line.
- add .MAK files so the user isn't forced to use RADAsm.
- don't use macros unless inevitable in the first and simplest examples. The macros are good, of course, but heavily usage of them tends to hide the important things. So the source looks like a bad C++ dialect, not like ASM.
Regards
Japheth
Hi Japheth!
?I strongly doubt this...
I take from your comments that in general terms, you are not very happy with the documentation? I put a lot of work in the chm file and I?m aware that the COM section is by far not complete. It would be helpful, if you can point out where you feel that a larger documentation is necessary to complete the topics.
?the comments in the demos are bad?
OK. The mean purpose of ObjAsm32 is to provide an OOP model. All objects and Demos came from our own requirements. It is truly possible that some parts of the code are not as well commented as it should be. I?ll try to correct this in the future, but I honestly think that they are not bad.
?add some simple examples for the command line. the whole project is a bit too "GUI oriented" for my taste. Don?t use VKDebug in these examples, just print to the command line...
One fact is, that if you can?t show something, people rapidly loose interest, so at the beginning of the project we decided to show the power of the model in some way. That?s the reason why it looks "GUI oriented". To discover the features of the OOP engine, you have to take a closer look at some objects like Collections, Streams, etc. About the Debug Output Window, I think it is the best choice. With only a few changes in the Debug.inc file, you can redirect the output to a console window. Perhaps a switch can be implemented to do this job. BTW, we have extended the capabilities of the standard VKDebug package to suit our necessities and also fixed some bugs (and introduced others).
?add .MAK files so the user isn't forced to use RADAsm.
I intentionally removed the .mak files from Version 1.2, since I included Demo12, which is capable of compiling all what you need to handle the model. Additionally, there are 2 check routines that I use very often to verify my methods.
?don't use macros unless inevitable in the first and simplest examples.
OK. I can go back to the roots and rewrite some examples showing the basics. I thought I have done it so, but obviously I?m wrong on this point.
?So the source looks like a bad C++ dialect, not like ASM.
It?s very difficult to maintain the balance between a high level of abstraction and the crude assembler. IMHO we have found a good way to have the best of both worlds. At some point of the model development we had to decide for a new syntax and structure. I?m completely convinced that we have done a good job!
Thanks for your comments! Without them, we can?t go on? :alright:
Regards,
Biterider
?I strongly doubt this...
I take from your comments that in general terms, you are not very happy with the documentation? I put a lot of work in the chm file and I?m aware that the COM section is by far not complete. It would be helpful, if you can point out where you feel that a larger documentation is necessary to complete the topics.
?the comments in the demos are bad?
OK. The mean purpose of ObjAsm32 is to provide an OOP model. All objects and Demos came from our own requirements. It is truly possible that some parts of the code are not as well commented as it should be. I?ll try to correct this in the future, but I honestly think that they are not bad.
?add some simple examples for the command line. the whole project is a bit too "GUI oriented" for my taste. Don?t use VKDebug in these examples, just print to the command line...
One fact is, that if you can?t show something, people rapidly loose interest, so at the beginning of the project we decided to show the power of the model in some way. That?s the reason why it looks "GUI oriented". To discover the features of the OOP engine, you have to take a closer look at some objects like Collections, Streams, etc. About the Debug Output Window, I think it is the best choice. With only a few changes in the Debug.inc file, you can redirect the output to a console window. Perhaps a switch can be implemented to do this job. BTW, we have extended the capabilities of the standard VKDebug package to suit our necessities and also fixed some bugs (and introduced others).
?add .MAK files so the user isn't forced to use RADAsm.
I intentionally removed the .mak files from Version 1.2, since I included Demo12, which is capable of compiling all what you need to handle the model. Additionally, there are 2 check routines that I use very often to verify my methods.
?don't use macros unless inevitable in the first and simplest examples.
OK. I can go back to the roots and rewrite some examples showing the basics. I thought I have done it so, but obviously I?m wrong on this point.
?So the source looks like a bad C++ dialect, not like ASM.
It?s very difficult to maintain the balance between a high level of abstraction and the crude assembler. IMHO we have found a good way to have the best of both worlds. At some point of the model development we had to decide for a new syntax and structure. I?m completely convinced that we have done a good job!
Thanks for your comments! Without them, we can?t go on? :alright:
Regards,
Biterider
Hi BiteRider,
you run into the same problem as many others have done: it is bad if the developer writes the documentation, simply because he/she cannot imagine any more the needs of a beginner/"outsider". It is pretty useless to argue with me about some of my comments. Of course they are a bit "provocative". But I'm sure you got the point: the quality of the docs and samples will determine if your oop model will succeed.
Regards
Japheth
I couldn't resist to copy some code of your first example:
Do you really think this is a good comment style? I don't.
you run into the same problem as many others have done: it is bad if the developer writes the documentation, simply because he/she cannot imagine any more the needs of a beginner/"outsider". It is pretty useless to argue with me about some of my comments. Of course they are a bit "provocative". But I'm sure you got the point: the quality of the docs and samples will determine if your oop model will succeed.
Regards
Japheth
I couldn't resist to copy some code of your first example:
.code ;Begin Code segment
start: ;Program entry point
mov hInstance, $invoke(GetModuleHandle, NULL) ;Retrieves module instance handle
ObjectsInit ;Runtime initialization of the OOP model
New TriangleShape ;Creates an new instance of TriangleShape
mov pShape_1, eax ;Stores instance pointer
; OCall pShape_1::TriangleShape.Private ;Invalid private method call (out of context)
OCall eax::TriangleShape.Init, 10, 15 ;Initializes TriangleShape
OCall pShape_1::Shape.GetArea ;Invokes GetArea method of TriangleShape
PrintDec eax ;Result = 75
Do you really think this is a good comment style? I don't.
Hello Japheth!
?It is pretty useless to argue with me about some of my comments. Of course they are a bit "provocative"?
It is by far not my intention to argue with anybody, but if you write in such a way, I?m forced to answer and show you why I have decided to do something.
I?m open anytime and anywhere to any constructive criticism and it is my wish that it remains on this level.
?it is bad if the developer writes the documentation?
I don?t think so. Today, the state of the art is UML, and it is the programmers? responsibility to write this documentation. In our case, since we are not flying so high and I suppose that none of the model users are really interested in such documentation, I decided to follow another way writing the chm file documentation. What we can discuss, is if I have correctly identified the user?s needs? This point is highly polemical, since not all users are at the same knowledge level.
The other point is, if I have forgotten to handle a topic or if the documentation is not enough. In this case, I?m glad to receive feedbacks and correct or append information to the model documentation.
?But I'm sure you got the point?
Sure, I got the point and I will work on it.
?I couldn't resist to copy some code of your first example?
IMO, it is better to write too much than too less. About the style, if you have a better way to document the source code, please don?t hesitate to simply write an example showing me how do you would do it, so I can consider to change my style?
Regards,
Biterider
?It is pretty useless to argue with me about some of my comments. Of course they are a bit "provocative"?
It is by far not my intention to argue with anybody, but if you write in such a way, I?m forced to answer and show you why I have decided to do something.
I?m open anytime and anywhere to any constructive criticism and it is my wish that it remains on this level.
?it is bad if the developer writes the documentation?
I don?t think so. Today, the state of the art is UML, and it is the programmers? responsibility to write this documentation. In our case, since we are not flying so high and I suppose that none of the model users are really interested in such documentation, I decided to follow another way writing the chm file documentation. What we can discuss, is if I have correctly identified the user?s needs? This point is highly polemical, since not all users are at the same knowledge level.
The other point is, if I have forgotten to handle a topic or if the documentation is not enough. In this case, I?m glad to receive feedbacks and correct or append information to the model documentation.
?But I'm sure you got the point?
Sure, I got the point and I will work on it.
?I couldn't resist to copy some code of your first example?
IMO, it is better to write too much than too less. About the style, if you have a better way to document the source code, please don?t hesitate to simply write an example showing me how do you would do it, so I can consider to change my style?
Regards,
Biterider
Hi japheth,
I agreed with BiteRider:
"Please, be polite and he will not be rude"
ipadilla
I agreed with BiteRider:
"Please, be polite and he will not be rude"
ipadilla
Hi BiteRider
> IMO, it is better to write too much than too less. About the style, if you > have a better way to document the source code, please don?t hesitate > to simply write an example showing me how do you would do it, so I
> can consider to change my style?
what I don't like regarding your comment style is that every line is commented, regardless if there is something usefull to say or not.
A good comment practice is:
1. write a header for each procedure/function describing in a *few* sentences what this function does and possibly the parameters/return values.
2 in the code itself only comment things that are important and not obvious to the reader
To ipadilla:
Hey, I know I am bad.
> IMO, it is better to write too much than too less. About the style, if you > have a better way to document the source code, please don?t hesitate > to simply write an example showing me how do you would do it, so I
> can consider to change my style?
what I don't like regarding your comment style is that every line is commented, regardless if there is something usefull to say or not.
A good comment practice is:
1. write a header for each procedure/function describing in a *few* sentences what this function does and possibly the parameters/return values.
2 in the code itself only comment things that are important and not obvious to the reader
To ipadilla:
Hey, I know I am bad.
Hi japheth,
You are not bad, you are a very good coder, I say that indeed, what happen is that you have to accept that is not easy the work made by BiteRider. I am secure that he know how to improve it in the future. You know better than me how difficult is what is programming BiteRider.
Regards
ipadilla
You are not bad, you are a very good coder, I say that indeed, what happen is that you have to accept that is not easy the work made by BiteRider. I am secure that he know how to improve it in the future. You know better than me how difficult is what is programming BiteRider.
Regards
ipadilla
Hi ipadilla,
> "Please, be polite and he will not be rude"
I love rudeness. This is a forum for men, not for wimps.
> "Please, be polite and he will not be rude"
I love rudeness. This is a forum for men, not for wimps.
Hi japheth,
I see...
Thank you
I see...
Thank you
Japheth, please tone it down a bit. Not everone shares your views on what this forum is for.. I being one of them.
If you dont want to use our model, then dont. End of discussion. It was designed to open to doors to for people less rigid and experienced with COM and objects alike.
Not everyone wants to do it the hard way. I believe this is why the COM section has so very little involvement. With some luck perhaps we just might make it easier for others to get started using COM objects. That is unless the idea gets shot down by the 'hard core experienced' members such as yourself. :roll:
Regards,
:NaN:
If you dont want to use our model, then dont. End of discussion. It was designed to open to doors to for people less rigid and experienced with COM and objects alike.
Not everyone wants to do it the hard way. I believe this is why the COM section has so very little involvement. With some luck perhaps we just might make it easier for others to get started using COM objects. That is unless the idea gets shot down by the 'hard core experienced' members such as yourself. :roll:
Regards,
:NaN:
Hi NaN
> Japheth, please tone it down a bit.
If you refer to my post to ipadilla - this was obviously a joke.
> If you dont want to use our model, then dont. End of discussion.
I see you are open for critics. As you said, "your feedback is welcome".
--- end of sarcasm part ---
Hi NaN, I already told BiteRider that I think his work is good, but documentation lacks in my eyes. As well, I made some suggestions how to improve these things IMO. Whats wrong with that. I agree, I'm not one of the folks giving others too much "moral support", the best thing I'm able to say about my and others peoples work is "not (really) bad" (I'm a "Dreckschwabe", an expression only BiteRider can understand).
If you are so eager for good comments, I will always disappoint you.
Regards
Japheth
> Japheth, please tone it down a bit.
If you refer to my post to ipadilla - this was obviously a joke.
> If you dont want to use our model, then dont. End of discussion.
I see you are open for critics. As you said, "your feedback is welcome".
--- end of sarcasm part ---
Hi NaN, I already told BiteRider that I think his work is good, but documentation lacks in my eyes. As well, I made some suggestions how to improve these things IMO. Whats wrong with that. I agree, I'm not one of the folks giving others too much "moral support", the best thing I'm able to say about my and others peoples work is "not (really) bad" (I'm a "Dreckschwabe", an expression only BiteRider can understand).
If you are so eager for good comments, I will always disappoint you.
Regards
Japheth
hello, i personaly do not like languajes object oriented, but i understand how they work.
The principal reason is that the programmer is some kind of blind about what he do, and i wouldn't like this infection to propage to the asm programers.
i just think that is you cant handle asm, then dont use it, change to a object oriented languaje.
______________Mauricio Prado
sorry my english
Los programadores Java apestan!!!!!
The principal reason is that the programmer is some kind of blind about what he do, and i wouldn't like this infection to propage to the asm programers.
i just think that is you cant handle asm, then dont use it, change to a object oriented languaje.
______________Mauricio Prado
sorry my english
Los programadores Java apestan!!!!!
i just think that is you cant handle asm, then dont use it, change to a object oriented languaje.
But if you can handle asm but since coding similar things again and again is boring and time-consuming, OOP asm comes in handy, as I always say :) . Almost no overhead in code speed, in most cases actually none, but at least 10 times faster coding speed - the huge advantage becomes obvious ;)
Hi
In this point I fully agree with Ultrano. The advantages of using an OOP model lies on the hand.
You have a much better organization of your app at practically no cost, you reduce the risk of generating errors, the execution is as fast as conventional asm coding and finally you are faster in producing your code.
All models you can find in this forum are open source projects, so you can easily find out the way things work. By no means you are blind when you use them. Obviously you will need some time to become familiar with all aspects of a particular model, but each minute you put in it's worth. :alright:
Regards,
Biterider
In this point I fully agree with Ultrano. The advantages of using an OOP model lies on the hand.
You have a much better organization of your app at practically no cost, you reduce the risk of generating errors, the execution is as fast as conventional asm coding and finally you are faster in producing your code.
All models you can find in this forum are open source projects, so you can easily find out the way things work. By no means you are blind when you use them. Obviously you will need some time to become familiar with all aspects of a particular model, but each minute you put in it's worth. :alright:
Regards,
Biterider
> but at least 10 times faster coding speed
:-D no offense Ultrano, but seems a bit exaggerated. Possibly your watch is out of function.
:-D no offense Ultrano, but seems a bit exaggerated. Possibly your watch is out of function.
It's no bullshit, japh - I really am now able to make most of my code 10 times faster than before.
foreach AllTabs, multi lea edx,.CTab.windows | mov tmp,edx | foreach tmp, invoke ShowWindow,.CWnd.hWnd,SW_HIDE
this, for instance, saves me around 70 boring lines of code, is much more readable to me, and takes care of multithreading sweetly ;). And I've got fewer things available to mess up :-D
And at least, instead of this:
mov ecx,obj1
invoke MyObject_Function1,param1,param2
I code:
pcall obj1.Function1,param1,param2
and I actually don't type "Function1" - I use the intellisense menu :) . So I can use longer, more descriptive function names. Also, when creating a class, instead of typing the skeleton procs myself (really boring and time-consuming at bigger classes), I force the OOP framework to type them for me to copy/paste - including parameter names too :-D
And, like Joel Spolsky once said - auto-memory-managed languages are faster, easier and safer to code on. OOP enables this at some degree.
Also, for me OOP inspires more creativity - and lack of it damages seriously my coding speed.
OK, at least all this is the case with me.
foreach AllTabs, multi lea edx,.CTab.windows | mov tmp,edx | foreach tmp, invoke ShowWindow,.CWnd.hWnd,SW_HIDE
this, for instance, saves me around 70 boring lines of code, is much more readable to me, and takes care of multithreading sweetly ;). And I've got fewer things available to mess up :-D
And at least, instead of this:
mov ecx,obj1
invoke MyObject_Function1,param1,param2
I code:
pcall obj1.Function1,param1,param2
and I actually don't type "Function1" - I use the intellisense menu :) . So I can use longer, more descriptive function names. Also, when creating a class, instead of typing the skeleton procs myself (really boring and time-consuming at bigger classes), I force the OOP framework to type them for me to copy/paste - including parameter names too :-D
And, like Joel Spolsky once said - auto-memory-managed languages are faster, easier and safer to code on. OOP enables this at some degree.
Also, for me OOP inspires more creativity - and lack of it damages seriously my coding speed.
OK, at least all this is the case with me.