Making .dll files for Excel 2010

[Jan T]

I am using Excel 2010 and Windows 7 and I would like to make use of
some .dll files to experiment and get some experience making my code
moore protected in future projects. I also realize that Microsoft
doesn't sell this any moore and I know there are some issues with
classic Visual Basic running on Windows 7, but that there are tricks
too make classic visual basic work with Windows 7.

Now, I have one possibility to buy a good old classic Visual Basic
Professional edition to a very good price, but a have one question. Is
it legal to buy a used one? I can also buy a new one, but for a higher
price.
The last option is probably Visual Studio 2010 but that seems very
expensive to buy for only a few .dll or assemly files, if that is what
they are called. Somebody that have some comments or suggestions?

Regards
Jan T.

 

[GS]

Jan T expressed precisely :

I am using Excel 2010 and Windows 7 and I would like to make use of
some .dll files to experiment and get some experience making my code
moore protected in future projects. I also realize that Microsoft
doesn't sell this any moore and I know there are some issues with
classic Visual Basic running on Windows 7, but that there are tricks
too make classic visual basic work with Windows 7.

Now, I have one possibility to buy a good old classic Visual Basic
Professional edition to a very good price, but a have one question. Is
it legal to buy a used one? I can also buy a new one, but for a higher
price.
The last option is probably Visual Studio 2010 but that seems very
expensive to buy for only a few .dll or assemly files, if that is what
they are called. Somebody that have some comments or suggestions?

Regards
Jan T.

I'd go with buying a used VB classic. That's what I did and there's no
problem installing it on Win7 if you follow the recommendations found
in the newsgroup mentioned below my signature.

Note, however, that you can't use VB6 for MSO 64bit projects.
Note also that most VB controls do not ship as of Win 6.x and so you
must must distribute/register any your projects use. Also, the VB
runtime is expected to be not supported after Win7.

If you expect long term use then I recommend you invest in a
programming language that will compile to x32/x64, focus going forward
on x64.

HTH

 

[Jan T]

Jan T expressed precisely :








I'd go with buying a used VB classic. That's what I did and there's no
problem installing it on Win7 if you follow the recommendations found
in the newsgroup mentioned below my signature.

Note, however, that you can't use VB6 for MSO 64bit projects.
Note also that most VB controls do not ship as of Win 6.x and so you
must must distribute/register any your projects use. Also, the VB
runtime is expected to be not supported after Win7.

If you expect long term use then I recommend you invest in a
programming language that will compile to x32/x64, focus going forward
on x64.

HTH

--
Garry

Free usenet access athttp://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc– Skjul sitert tekst –

– Vis sitert tekst –

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -


Thanks Gary for good answers!

You wrote;
**..the VB runtime is expected to be not supported after Win7.** Does
that mean it is not possible
to run a VB program, say in Win 8, that is an executable/.exe file
that was produced in Win 7 environments
using VB Classic Development tools?
(or do you mean I cannot install VB classic developing program, that I
am considering buying)?

Does that mean I probably cannot use .dll with say an Excel Addin
after Win 7?
Thank you very much for answering.


Regards
Jan T.

 

[GS]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -


Thanks Gary for good answers!

You wrote;
**..the VB runtime is expected to be not supported after Win7.** Does
that mean it is not possible
to run a VB program, say in Win 8, that is an executable/.exe file
that was produced in Win 7 environments
using VB Classic Development tools?
(or do you mean I cannot install VB classic developing program, that I
am considering buying)?

Does that mean I probably cannot use .dll with say an Excel Addin
after Win 7?
Thank you very much for answering.


Regards
Jan T.

Jan,
You can use DLLs created in VB6 with Excell addins OR as Excel
COMAddins regardless of what OS you create them on. There'll be
problems with installing classic VS on Win7 but these can be worked
around by the recommendations posted in the newsgroup referred to in my
signature below.

AFAIK, Win8 will not include the 'classic' vb runtime so unless your
projects are purely x32 to run in MSO x32 only, expect problems! The vb
runtime supports the intrinsic controls only so any other controls you
use (ie: common dialog, etc) you'll need to ship these and register
them before your project can use them.

If you go with a newer version of VS (ie: .NET) you will have far less
problems. VB.Net offers the best support for creating COMAddins for MSO
apps.

In all cases, you'll need a x64 capable language to service MSO x64. MS
offers C++ but I haven't any info regarding x64 compilers for C++.
Being that things are transitioning to x64 as the standard next gen
platform I'd be recommending going with something that serves your
needs in both x32/x64.

Of course, you'll be able to run your VB.EXEs in Win8 if you also
ship/register ALL the necessary runtime components. That doesn't mean
Win8 will support them; it just means they won't be included in that
OS.

My best advice is to subscribe to a few of the vb newsgroups or online
forums.

Best wishes...

 

[Auric__]

on 12/3/2011, Jan T supposed : [snip]

You wrote;
**..the VB runtime is expected to be not supported after Win7.** Does
that mean it is not possible
to run a VB program, say in Win 8, that is an executable/.exe file
that was produced in Win 7 environments
using VB Classic Development tools?
(or do you mean I cannot install VB classic developing program, that I
am considering buying)?

Does that mean I probably cannot use .dll with say an Excel Addin
after Win 7?
Thank you very much for answering.

Jan,
You can use DLLs created in VB6 with Excell addins OR as Excel
COMAddins regardless of what OS you create them on. There'll be
problems with installing classic VS on Win7 but these can be worked
around by the recommendations posted in the newsgroup referred to in my
signature below.

AFAIK, Win8 will not include the 'classic' vb runtime so unless your
projects are purely x32 to run in MSO x32 only, expect problems! The vb
runtime supports the intrinsic controls only so any other controls you
use (ie: common dialog, etc) you'll need to ship these and register
them before your project can use them.

If you go with a newer version of VS (ie: .NET) you will have far less
problems. VB.Net offers the best support for creating COMAddins for MSO
apps.

In all cases, you'll need a x64 capable language to service MSO x64. MS
offers C++ but I haven't any info regarding x64 compilers for C++.
Being that things are transitioning to x64 as the standard next gen
platform I'd be recommending going with something that serves your
needs in both x32/x64.

Of course, you'll be able to run your VB.EXEs in Win8 if you also
ship/register ALL the necessary runtime components. That doesn't mean
Win8 will support them; it just means they won't be included in that
OS.

My best advice is to subscribe to a few of the vb newsgroups or online
forums.

In addition to everything Gary said, I'd like to point out that there are
other BASICs available for Windows (free or otherwise) which are perfectly
capable of creating DLLs, not to mention other languages entirely (if you
know any). FreeBASIC can, PowerBASIC can, most Windows C/C++ compilers can,
etc.

There's an x64 version of GCC available through MinGW-w64:
http://mingw-w64.sourceforge.net/

 

[GS]

Auric__ explained :

There's an x64 version of GCC available through MinGW-w64:
http://mingw-w64.sourceforge.net/

Now this looks interesting! Thanks for sharing...

While I agree about the other languages you mention, they still only
provide x32 compilers AFAIK. None except C/C++ can create COMAddins for
MSO AFAICS.

 

[Jan T]

on 12/3/2011, Jan T supposed : [snip]

You wrote;
**..the VB  runtime is expected to be not supported after Win7.** Does
that mean it is not possible
to run a VB program, say in Win 8, that is an executable/.exe file
that was produced in Win 7 environments
using VB Classic Development tools?
(or do you mean I cannot install VB classic developing program, that I
am considering buying)?
Does that mean I probably cannot use .dll with say an Excel Addin
after Win 7?
Thank you very much for answering.

Jan,
You can use DLLs created in VB6 with Excell addins OR as Excel
COMAddins regardless of what OS you create them on. There'll be
problems with installing classic VS on Win7 but these can be worked
around by the recommendations posted in the newsgroup referred to in my
signature below.

AFAIK, Win8 will not include the 'classic' vb runtime so unless your
projects are purely x32 to run in MSO x32 only, expect problems! The vb
runtime supports the intrinsic controls only so any other controls you
use (ie: common dialog, etc) you'll need to ship these and register
them before your project can use them.

If you go with a newer version of VS (ie: .NET) you will have far less
problems. VB.Net offers the best support for creating COMAddins for MSO
apps.

In all cases, you'll need a x64 capable language to service MSO x64. MS
offers C++ but I haven't any info regarding x64 compilers for C++.
Being that things are transitioning to x64 as the standard next gen
platform I'd be recommending going with something that serves your
needs in both x32/x64.

Of course, you'll be able to run your VB.EXEs in Win8 if you also
ship/register ALL the necessary runtime components. That doesn't mean
Win8 will support them; it just means they won't be included in that
OS.

My best advice is to subscribe to a few of the vb newsgroups or online
forums.

In addition to everything Gary said, I'd like to point out that there are
other BASICs available for Windows (free or otherwise) which are perfectly
capable of creating DLLs, not to mention other languages entirely (if you
know any). FreeBASIC can, PowerBASIC can, most Windows C/C++ compilers can,
etc.

There's an x64 version of GCC available through MinGW-w64:
 http://mingw-w64.sourceforge.net/

Very interesting. I have to take a closer look at those as well.
Thank you! Appreciated it.

Regards
Jan T

 

[Auric__]

Auric__ explained :

Now this looks interesting! Thanks for sharing...

While I agree about the other languages you mention, they still only
provide x32 compilers AFAIK. None except C/C++ can create COMAddins for
MSO AFAICS.

I expect that FreeBASIC will have x64 support within a few years.
PowerBASIC... well, you never know about x64 support, but I'm *fairly* sure
that it can do COM addins. (MSO, no clue.)

I only have one 64-bit machine so it's fairly low-importance to me right now
(and therefore I haven't researched it as thoroughly as I might otherwise).

 

[GS]

Auric__ laid this down on his screen :

I expect that FreeBASIC will have x64 support within a few years.
PowerBASIC... well, you never know about x64 support, but I'm *fairly* sure
that it can do COM addins. (MSO, no clue.)

I only have one 64-bit machine so it's fairly low-importance to me right now
(and therefore I haven't researched it as thoroughly as I might otherwise).

I have PB and I can assure you it has no features for making COMAddins.
Sure, it can make COM DLLs but that's far from a COMAddin. A COMAddin
is a DLL designed specifically for MSO apps such that the target MSO
app knows the COMAddin exists and so installs it once it's registered.
I suspect a COM DLL can be installed in other apps by pointing to the
com.dll file via an addins manager or the like, but these DLLs must be
designed with the host app's required criteria to be recognized.
Otherwise, PB has no mechanism for creating COMAddins.