Assebly Plugin for VB - does it work?

[The2Saint]

Hello

I discovered this site
www.persistentrealities.com/vbfibre/index.php?category=0&item=5&t=asm
with a MASM plugin for Visual Basic 6. The tool gives you the ability to use inline assembly (MASM) in VB projects. It seems to be free too. The problem is just that no mater how much I try I can't get it to work . It just regards my inline assebly code as comments and fails to compile it. Anyone have any idea what I'm doing wrong? Can anyone else here get it to work?

Regards
Kevin

[P1]

It seems to me that maybe you may want to check the .dll route for MASM code.

I also just shell out to a MASM .exe too.

Use 'Search' to find out more about it.

Otherwise, you need to give us more information.  Like are you having problem with the plug-in?  It also says the ml.exe must be in a certain location from the web link you gave.  Are you sure that you have it there?

This seems to me to be setup issue with VB, not a MASM problem yet, so I am moving this thread.

Regards,  P1   :8)

[The2Saint]

>It seems to me that maybe you may want to check the .dll route for MASM code.
>I also just shell out to a MASM .exe too.

I don't understand what you mean with the above sentences?

>Otherwise, you need to give us more information.  Like are you having problem with the plug-in?

The plugin loads fine, and everything seems fine, no error messages at all. When I do compile the project, it fails to hook the MASM-assemler, and all MASM code hence get treated like comments (since you have to start all MASM code with ' so the VB syntax checker will regard the MASM code as comments and don't bring up an error message).

>It also says the ml.exe must be in a certain location from the web link you gave.  Are you sure that you have it there?
You must specify for the plugin where ML.exe is located, otherwise it brings up an error. I did that, so I think that part should be ok.

>This seems to me to be setup issue with VB, not a MASM problem yet, so I am moving this thread.
Sure - the Orphanage seems like a good place for me, I'm feeling like an orphant  :'(

It seems to me that maybe you may want to check the .dll route for MASM code.

I also just shell out to a MASM .exe too.

Use 'Search' to find out more about it.

Otherwise, you need to give us more information.  Like are you having problem with the plug-in?  It also says the ml.exe must be in a certain location from the web link you gave.  Are you sure that you have it there?

This seems to me to be setup issue with VB, not a MASM problem yet, so I am moving this thread.

Regards,  P1   :8)

[AeroASM]

>It seems to me that maybe you may want to check the .dll route for MASM code.
>I also just shell out to a MASM .exe too.

I don't understand what you mean with the above sentences?

The first one means that you put the asm code into a dll and call the dll from VB using Declare.

THe second one means that you write the whole program in MASM.

[The2Saint]

I see. Havig inline MASM code that got compiled directly into the .exe would be way smoother IMO. Don't you think?
Especially since there is a MASM inline plugin that seems to work on everyone's computer except mine  :dazzled:

The first one means that you put the asm code into a dll and call the dll from VB using Declare.

THe second one means that you write the whole program in MASM.

[zooba]

I haven't seen this plugin before, but I would assume it's only going to work if you are compiling to native code. VB6 has a good native compiler and if you 'Assume No Aliasing' (in the Advanced Optimizations) it gets even better.

I would recommend the DLL way. It works out quite neatly. I'm in the process of writing a (large and getting larger) tutorial on this topic, since there are a few traps.

Perhaps you could give us an idea of what you are trying to achieve with your assembly code - perhaps there is a way of doing it in VB that is just as efficient?

[sluggy]

I see. Havig inline MASM code that got compiled directly into the .exe would be way smoother IMO. Don't you think?
Especially since there is a MASM inline plugin that seems to work on everyone's computer except mine 

That plugin has been around for a few years now, it works by compiling your VB code then hacking the exe to insert the MASM stuff. Personally i think it is a waste of time, it offers very little enhancement, you are far better off (and safer) compiling your asm into a dll and just calling it from VB.

[The2Saint]

I haven't seen this plugin before, but I would assume it's only going to work if you are compiling to native code. VB6 has a good native compiler and if you 'Assume No Aliasing' (in the Advanced Optimizations) it gets even better.

I would recommend the DLL way. It works out quite neatly. I'm in the process of writing a (large and getting larger) tutorial on this topic, since there are a few traps.

Perhaps you could give us an idea of what you are trying to achieve with your assembly code - perhaps there is a way of doing it in VB that is just as efficient?

I have never coded anything in any languadge besides VB. Hence I have no idea how good or bad the compiler really is. Some say it's a good compiler. Some say the exact opposite, that its slow. And YES, I have turned all the advanced optimizations on. What we can say for certain is that its a very OLD compiler. Have compiler technology not envolved anything in 7 years? I assume it have. Hence the VB compiler might have been a good one back in 98, but nowadays? I mean, Optimize for Pentium Pro? How many pentium pro CPU's are still around?

I just realize, when I said I've not tried any other compilers, I lied. That wasn't true. There is one compiler I've tried my VB code with. This was the VB.NET JIT compiler. The results? The VB.NET compiler achives only 25% of the speed of VB6's native-compiler! 1/4 of the speed! I'm asking myself why Microsoft refuse to listen to their customers, but that's not what we're here to discuss in this topic.

Hence, there's no doubt that the VB6-native compiler is getting out of shape due ageing, and that Microsoft's new VB-versions are slower. Everyone knows that VB is under constant critisim for not providing the low level abilities C-apparently have and hence being slow. Since I like VB6, I though I should silence the critics one in for all and just say that "you can add inline assebly in VB". What better way would there be to gain the speed?

I've also been thinking of setting up a web page with detailed instructions how to install the MASM plugin and how to write assembly. In short, I would marketing the assembly ability in VB as an alternative for people considering swithing to C++. That would be great for them too, since MASM is faster than C++ and everyone would be happy IF I JUST COULD GET THE DAMNED THING TO WORK. :dazzled:

It also says that I shout "read the MASM documentation carefully so everything is set-up correctly". I tried to, but what could possibly fail?
I'm using MASM 8.2, Windows XP, Visual Basic 6 with SP6. Are there any incompatibility?

I've also heard that calling a .dll takes some time in itself (0,000009 secs or something like that). Wouldn't it be nice to get rid of that time?

[zooba]

As much as I agree with your sentiments RE: silencing the critics, it's just not going to happen. I have found it is impossible to debate the topic with them as they always fall back to the same (irrelevant) arguments: "It's not proper OO", "It doesn't do pointers", "A sub is just a glorified block... with a stack frame" (yes, that's true - boy did I shut him down badly :wink ). As obvious as it may seem to us that VB6 is a legitimate programming language (even  :eek a good one!  :P) there are always those who believe exactly the same thing about Java/Python/C++/BrainF*ck and won't budge for anything (okay, the last one has a pretty small following...  :bg)

RE: M$ - VB.NET was solely to try and entice VB6 programmers into C#. It's only working because of managers who say "this is new, we're going to use this" and suddenly all the jobs require .NET skills.

RE: DLLs. Yes, there is some overhead but good coding can easily avoid it. The most obvious one: if you are performing calculations on an array, put the loop in the DLL rather than VB. That way you only call the DLL once.

BTW. compilers don't 'get out of shape' (though it's a nice analogy  :lol). Processors have changed and newer instructions are becoming available and some other instructions are becoming 'out of shape' and the 'best' combination of instructions are changing. You'll find that (with the latest/final service pack for VS6) C2.EXE (the C/C++ compiler) is only 1 major version behind C2.DLL (shipped with VS2003) - hardly obsolete.

BASIC has too much history behind it as being a 'hack' language, 'cobbled together' from many different syntax forms, interpreted and 'too understandable by non-programmers' for some narrow-minded people to recognise VB6 as a mature language (with a few exceptions). I wish you well on your quest to silence the critics - hopefully you fare better than I did   :wink

[The2Saint]

I'd say screw John Sugas MASM plugin. Because VB doesn't need inline assembly? No, because I found a better one! 
ThunderVB :cheekygreen:
http://sourceforge.net/projects/thundervb/
(Download here: http://prdownloads.sourceforge.net/thundervb/ThunderVB_1.0.0.rar?download)

This plugin seems to be extremely good software, although I've just found it and haven't tried it fully.
Although the additional C support felt amost a litte humiliating at first, I could easily think of situations where it could become handy (when porting Mac apps written in C for example).

> (even  :eek a good one!  :P)
You mean the best one, I immidiately though when I read it, but then I remembered that this wasn't a Visual Basic forum  :bdg. Seriously however, when it comes to laguadge/syntax (disregaring compiler performance etc.), I don't see why anyone would prefer anything but BASIC, since there's no needless excessive use of ; nor ( ) or { } or ==. If someone could give a motivation why ; is better than a new line, I'd like to hear it.

When it comes to C2.exe, my dream is that someone would hack an updated version of it.

As much as I agree with your sentiments RE: silencing the critics, it's just not going to happen. I have found it is impossible to debate the topic with them as they always fall back to the same (irrelevant) arguments: "It's not proper OO", "It doesn't do pointers", "A sub is just a glorified block... with a stack frame" (yes, that's true - boy did I shut him down badly :wink ). As obvious as it may seem to us that VB6 is a legitimate programming language (even  :eek a good one!  :P) there are always those who believe exactly the same thing about Java/Python/C++/BrainF*ck and won't budge for anything (okay, the last one has a pretty small following...  :bg)

RE: M$ - VB.NET was solely to try and entice VB6 programmers into C#. It's only working because of managers who say "this is new, we're going to use this" and suddenly all the jobs require .NET skills.

RE: DLLs. Yes, there is some overhead but good coding can easily avoid it. The most obvious one: if you are performing calculations on an array, put the loop in the DLL rather than VB. That way you only call the DLL once.

BTW. compilers don't 'get out of shape' (though it's a nice analogy  :lol). Processors have changed and newer instructions are becoming available and some other instructions are becoming 'out of shape' and the 'best' combination of instructions are changing. You'll find that (with the latest/final service pack for VS6) C2.EXE (the C/C++ compiler) is only 1 major version behind C2.DLL (shipped with VS2003) - hardly obsolete.

BASIC has too much history behind it as being a 'hack' language, 'cobbled together' from many different syntax forms, interpreted and 'too understandable by non-programmers' for some narrow-minded people to recognise VB6 as a mature language (with a few exceptions). I wish you well on your quest to silence the critics - hopefully you fare better than I did   :wink