Using Runtime Libraries

[Ratch]

To the Ineffable All,

     There are many articles on the internet about all the whiz bang things one can do as far as using common controls to display information in columns, color, icons, or whatever.  A lot of there applicatons reference VB, MFC, NET or whatever libraries to do these things.  An example is the System.Windows.Forms.dll which is a .NET file of some kind.  I have some questions about this.  First, does the standard Windows XP installation include those runtime routines, or do users have to buy VB, MFC or .NET to get them.  Second, is it possible to call those routines via MASM and link them into a program.  Third, will I take a performance hit with respect to execution or bloat by using those libraries.  Anything anybody can tell me about this will be appreciated, including a link to any MASM examples that do this.  Ratch

[u]

1) No, users won't have to buy VB and stuff. For VB6, the standard dll was msvbvm60.dll, and it's freely redistributable.

2) Interfacing to VB, MFC and probably .NET isn't impossible. But to make the interface easy, in most cases you'll have to make wrappers to the objects you want to use.

3) The bloat can become a reason to make the opposite thing: code mainly in the VB/C++/C#/VB.net language, and do some stuff with asm. Performance depends on the VB/MFC/.NET objects you're using.

[Ratch]

Ultrano,

1) No, users won't have to buy VB and stuff. For VB6, the standard dll was msvbvm60.dll, and it's freely redistributable.

     And what about MFC and .NET?

2) Interfacing to VB, MFC and probably .NET isn't impossible. But to make the interface easy, in most cases you'll have to make wrappers to the objects you want to use.

     Making a wrapper is C++ speak.  I don't want to get involved with C++.  I just want to call the library routine from MASM if that is feasible.

3) The bloat can become a reason to make the opposite thing: code mainly in the VB/C++/C#/VB.net language, and do some stuff with asm. Performance depends on the VB/MFC/.NET objects you're using

     Again,you are telling me that I should code in VB/C++/C#/VB.net .  I don't want to to that.  Can't C++  be translated into MASM easily like C can?  Ratch

[u]

MFC is usually "mfc42.dll". I don't know anything about .NET

The problem with using the MFC/C++ class-objects is only their name-obfuscations, but it arises only if statically-linking these objects' code. If you load objects from a DLL, then you can easily use ATC and probably OA32 to call object-methods :) . It's really easy, once you know how the specific vTable looks. Though, I've seen horrible C++ objects, that broke sanity rules by mixing the 3 incompatible designs: COM, Cpp-standard and C-call standards into one class.... took me half a day to figure-out.

VB objects ... there are a lot of tutorials/examples  on the other board.

Hmm, so as long as you have the objects in a dll, you won't have much trouble. (yet you can't inherit from these objects :) ) .

Someone with .NET experience will have to say his thoughts/experience on fusing masm and C#/vb.net .

[Tedd]

First, does the standard Windows XP installation include those runtime routines, or do users have to buy VB, MFC or .NET to get them.

The VB dlls are already on my system - and I haven't specifically installed them otherwise - so it looks like they're included.
MFC dlls are also there.
.NET is installed by default as far as I know, but it's definitely available through windows update, so no problems there.

Second, is it possible to call those routines via MASM and link them into a program.

MFC is meant to be called from C++ so using it should be pretty straightforward.
VB stuff can be used - I think the interface is COM based.
.NET ..hmmm. I wouldn't be surprised if it was based around COM too, but if it's not then it should just be a matter of figuring out the calling convention. It's based on working with an intermediate language though, so it probably won't be pretty.
(Nothing's impossible :bdg)

Third, will I take a performance hit with respect to execution or bloat by using those libraries.

Bloat generally comes from linking runtimes statically into your application - this doesn't really apply when using external libraries.
Performance-wise, that depends on the implementations themselves. Of course, if you code the same functionality in assembly then you're going to get better performance, but the 'performance hit' on your application is the same as calling any dll functions (how well those functions actually execute is down to the dll, though.)

Are you just wondering, or is there something specific you want to use?

[Ratch]

Tedd and Untrano,

     Thanks to both of you for your insights.  That should get me started.  I don't know anything about COM and .NET, but from what I hear about it, I don't want to either.  I don't have any specific project in mind yet, but I thought since there is so much written in VB and C++, I should look into it.  Ratch