Putting Msvbvm60.dll onto a CD
Ken
that if the Msvbvm60.dll is placed ( along with any other required files )
on the CD then it doesn't have to be on the Users Computer. If this is
correct do I place these files on the root of the CD and not in any folders?
Thanks
Ken
D...@home.com
different News Groups I don't think I'll bother... :(
Have a good day...
Don
Ken
stick to that one. Very hard to have a question and wait two or three days
for someone good enough to help and no one answers, only to find if you post
the same question to another newsgroup it gets answered. I have asked a
simple question before by posting to a single newsgroup, waiting 2 days,
posting it to the next, and so on until a week has gone by without a single
answer. I suppose some people don't have the time to do this for every
question??
<D...@home.com> wrote in message
news:hupntugd8ejsvohi1...@4ax.com...
Frank Adam
>I was going to give some thoughts to your problem but after finding out that you posted to 5
>different News Groups I don't think I'll bother... :(
>
Don, "cross posting" is quite ok as long as it envolves relevant
groups..
It's "multi posting" that pisses most people off.
>>I have a VB Menu and want it to be an autorun menu on a CD. I have heard
>>that if the Msvbvm60.dll is placed ( along with any other required files )
>>on the CD then it doesn't have to be on the Users Computer. If this is
>>correct do I place these files on the root of the CD and not in any folders?
>>
No idea. Do a search on Google groups though, this has come up here in
CLBVM a couple of times before and IIRC, it was resolved.
--
Regards, Frank
Maureen
Are you talking to me?
D...@home.com
asking me if I want to send my post to XX News Groups. I can understand the OP's reason for doing
this and I hope he understands my choice of not wanting too....
Ok, food for thought:
It is too my understanding MSVBVM60.DLL has to be registered as do some of the others.
They can be placed anywhere as long as there is a valid path to them.
If you dicker with someones registry like this what problems can arise?
I've never done it so I can't tell you what happens when someone installs a VB Program after the
registry modifications but I would have to assume that the installer would do the right thing
because it wouldn't be able to find the DLL(s) in question.
Just my .0002 cents worth...
Have a good day...
Don
J French
Make sure you do not use any other OCXes
It should work, although the MSVBVM60.DLL has some registration
requirements - peculiar things sometimes happen with things self
registering.
Best test it on a clean computer
If that does not work VB5 definitely works standalone
- MSVBVM50.DLL does not need registering
One of the reasons why I use VB5
On Thu, 21 Nov 2002 05:47:43 +1000, "Ken"
<kjru...@SPAMoptusnet.com.au> wrote:
Darin Lampson
not need runtime files or choose another langue to build the menu. There
are some issues including the runtime dll on the CD. To take all of
possible problems I would choose to use C++. If it is a simple menu program
you could easily write it in C++ using MFC.
"Ken" <kjru...@SPAMoptusnet.com.au> wrote in message
news:3ddbe6bd$0$12759$afc3...@news.optusnet.com.au...
Bob Butler
news:eSRsMZXkCHA.2432@tkmsftngp10
> What I have come across is that best bet is to either use VB 3 which
> does not need runtime files
VB3 does need runtime files; it needs fewer/smaller ones and doesn't need
COM registrations but it does require runtimes.
> or choose another langue to build the
> menu. There are some issues including the runtime dll on the CD. To
> take all of possible problems I would choose to use C++. If it is a
> simple menu program you could easily write it in C++ using MFC.
No argument there.
Frank Adam
Yes there is... MFC ? ewwwww !
What's next, writing programs that use 1meg runtimes ?
.
.
Oh.. never mind, it's early morning.. ;-)
--
Regards, Frank
Cecil Galbraith
either dynamic linking (your 1 meg runtime) or static linking (no runtime
required at all, and a reasonably small executable). Unfortunately, Visual
Basic applications *always* require a runtime... I've been using MFC and V++
to make a living since 1994... It ain't bad...
Also, I'd be surprised if the scheme in question would work without the VB
runtime being registered...
Just my thoughts...
Cecil
"Frank Adam" <fa...@optushome.com.au> wrote in message
news:3ddd4bb6...@news-vip.optusnet.com.au...
Jack Russell
SteelCodr
MFC does require 'runtimes' in the form of the OS DLLs (which can be
avoided by static linking, but gives you Monster EXEs - but this is really a
moot point when memory and HDD space is cheap)
VB Users have had it pretty hard since their runtimes are not included with
the OS (Although, that is changing with the CLR), so get lots of flak for
'causing' DLL Hell....
VB Can make reasonably small EXEs too!
But yes, the VB Runtimes would need to be installed and registered....sigh!
Stephen J Whiteley
"Cecil Galbraith" <cgalb...@codesoup.com> wrote in message
news:eqicnbxKI4T...@comcast.com...
Tom Shelton
using
> either dynamic linking (your 1 meg runtime) or static linking (no runtime
> required at all, and a reasonably small executable). Unfortunately, Visual
> Basic applications *always* require a runtime... I've been using MFC and
V++
> to make a living since 1994... It ain't bad...
Static linked or not MFC apps require a runtime. It's just a matter of if
it is an external component, or wraped up in the exectable.
> Also, I'd be surprised if the scheme in question would work without the VB
> runtime being registered...
It actually does because the VB5/6 runtimes are self registering ActiveX
components. That said, I don't think it is a good idea.
Tom Shelton
Cecil Galbraith
Not true, Tom...
When you static link a C/C++/MFC program, the linker resolves externals (in
the static libraries) by copying only those portions of the library into the
executable that are required, *not* the entire library.
This has been true of any linker that I've seen since about 1981 (including
a couple that I wrote myself)...
Any Windows program, whether VB or C++/MFC, will accomplish what it needs to
accomplish by ultimately calling API functions inside the various DLL's that
make up the Windows OS, so in that regard, a VB program is no different than
a C++/MFC program.
A VB executable is indeed very small. That is because all the "external
references" are resolved at runtime rather than at compile time...
Ultimately, there isn't a huge difference between the memory image of a VB
vs a C++ program. The VB programs tend to be a *bit* heavier, but not
greatly so...
Some time ago, I wrote a digital clock using both VB and MFC. They appeared
identical on the desktop. Specs follow:
VB Executabe Size 34.5k
MFC Executable Size 490K
VB Memory Image Size 2186K
MFC Memory Image Size 1868K
You can *copy* an MFC program to another computer and, assuming that it
isn't using any third party controls, it will run. So, the copy size is
490K.
You must *install* a VB program on another computer, and assuming no third
party control, the copy size will be the VB program plus the MSVBVM60.DLL
file which totals 1390K
So, the MFC has about the same memory image size as the VB, runs a tad bit
faster, and is much smaller to copy to another machine and doesn't require
"installation", only copying...
*You* choose...
I usually write in C++/MFC if it's a contract and VB if what I'm writing
will be maintained by someone else...
"Tom Shelton" <to...@dakcs.com> wrote in message
news:zUsD9.336$zt4....@news.uswest.net...
Tom Shelton
> >>Static linked or not MFC apps require a runtime. <<
>
> Not true, Tom...
>
> When you static link a C/C++/MFC program, the linker resolves externals
(in
> the static libraries) by copying only those portions of the library into
the
> executable that are required, *not* the entire library.
True, but that is more a matter of library design not linker design. Have
you used g++ lately? I am not making a negative comment about MFC in
general. The runtime functions may be linked into the exe, or reside in the
mfc dll. Admitedly, I am not an expert on MFC, so I have no idea if the
library is designed in such a way as to make it so that it can be split up
by the linker. I did notice during my brief forray into MFC during the VS5
days, that there was a significant increase in the size of the exe when you
elected to static link the MFC runtime. Even so, unless each function is
compiled into a separate .o before beign joined into the library - there is
going to be dead wood in your application. It is more a matter of degree.
With a VB program, you are always saddled with the entire runtime - with
MFC, you may or may not be.
I'm not arguing over the suitability of MFC for this kind of program - it is
better suited then VB5/6 for sure. And even if the entire runtime was
statically linked into your application, it isn't going to amount to much
when put on a CD. Personally, though if I was going to write something like
this, I would look into PowerBASIC - especially now that they have a forms
designer available. With PB, you could make this very simply, especially if
the OP has no experience with C++, and I can pretty much guarantee it would
be smaller and faster then anything you could create using MFC.
Tom Shelton
Frank Adam
<cgalb...@codesoup.com> wrote:
>Not to get sucked into the abyss, but MFC applications can be written using
>either dynamic linking (your 1 meg runtime) or static linking (no runtime
>required at all, and a reasonably small executable). Unfortunately, Visual
>Basic applications *always* require a runtime... I've been using MFC and V++
>to make a living since 1994... It ain't bad...
>Also, I'd be surprised if the scheme in question would work without the VB
>runtime being registered...
>
I don't use MFC. I like a bit of pain.
You're right, in many cases i've found C++ can actually produce some
pretty small exes and on occasions even smaller than straight C.
However you're talking to a C bigot with about 10 years more up his
sleeve so, and you know how pathetic we are. ;-p
>Just my thoughts...
>
And mine.
ps: Guys, let's not start a compiler war huh ? :)
--
Regards, Frank
Terry Austin
> ps: Guys, let's not start a compiler war huh ? :)
My compiler can compile your compiler?
Though I suppose the real test is if a complier
can compile itself.
Terry Austin
Frank Adam
<tau...@hyperbooks.com> wrote:
>Frank Adam wrote:
>
>> ps: Guys, let's not start a compiler war huh ? :)
>
>My compiler can compile your compiler?
>
Well, C++ was written in C and ASM, so i guess the coalition wins. ;-)
--
Regards, Frank
Cecil Galbraith
at Microsoft. A point of pride with them, it seems, is that Visual C++ 6 was
written with Visual C++ 6...
Sounds strange, doesn't it?
"Terry Austin" <tau...@hyperbooks.com> wrote in message
news:armid...@enews1.newsguy.com...
Frank Adam
<cgalb...@codesoup.com> wrote:
>I recall an article from some time ago - an interview with the Visual C crew
>at Microsoft. A point of pride with them, it seems, is that Visual C++ 6 was
>written with Visual C++ 6...
>
>Sounds strange, doesn't it?
>
Hm. chicken, egg scenario. I'll go with logic and say they were
having a trip, but more likely simply misunderstood when they said
that VC6 was recompiled with VC6 for it's final release, not "written
with".
Which would make perfect sense, since it was the latest and best
optimizing compiler at it's release.
Or else i'll go and hammer up a hammer with the same hammer. ;))
--
Regards, Frank
J French
<tau...@hyperbooks.com> wrote:
That is one of the final tests for a Unix port
Larry Linson
itself, so why does it make a compiler better if it can compile itself?
It makes it suitable, I suppose, for creating compilers, but I don't create
compilers -- I'd much rather have a nice application generator like VB
(which isn't a compiler, anyway).
--
Larry Linson http://www.ntpcug.org -- North Texas PC User Group
http://members.tripod.com/ntaccess -- Access SIG
http://members.tripod.com/accdevel -- Access Samples and Examples
http://appdevissues.tripod.com/downloads.htm -- Presentations
"J French" <Bounce_...@iss.u-net.com_.bin> wrote in message
news:3ddf25b...@news.u-net.com...
J French
- there is no great merit or demerit in a language being written in
itself.
I suppose it could be handy being able to modify ones own language,
but it would also be pretty dangerous.
It is just that recompiling the 'C' compiler using itself is the acid
test for a Unix port.
DaveB
Jack Russell <ja...@tpg.com.au> wrote in message
news:3DDD3E5B...@tpg.com.au...
Cecil Galbraith
"Larry Linson" <larry....@ntpcug.org> wrote in message
news:eVFD9.2275$D73...@nwrddc03.gnilink.net...
Jack Russell
counterpart PDQComm now replaced by SaxComm). There was also a problem with the
program trying to "perform an illegal operation". I did not pursue the latter
but converted to VB6 instead.
I am almost certain that I had vb3 problems as well but cannot remember what
now.
Pity really because vb3 produced very small distribution files.
Jack Russell
J French
support.
However you are probably wise moving to 'proper' 32 bit
It will become increasingly difficult for MS to support 16 bit code,
and their support is bound to get progressively more flaky as time
passes.
IMO VB4 was a crud product - I wish I had skipped that too.
- it was the introduction of the UserControl in VB5 that made VB a
language where one did not continually have to re-invent the wheel.
On Sun, 24 Nov 2002 07:19:49 +1100, Jack Russell <ja...@tpg.com.au>
wrote:
Terry Austin
> I skipped VB3 - but my impression was that it too required run time
> support.
It did. The advantage is that Vbrun300.dll has been included in
most versions of Win9x. No idea if it still is on XP.
Terry Austin
Terry Austin
> Well, let me see, my car can't assemble itself, nor my house can't
> build itself, so why does it make a compiler better if it can compile
> itself?
It just seems to be a common test of quality for some programmers.
Most notably, programmers who use languages that have compliers
written in that language.
I recall running across a web page once, devoted to "toy programming
languages," that had many amusing examples (like the one that took
four hours to process "Hello, world.") Their definition of "toy programming
language" was on in which the compiler was not written in the language
it compiles.
Terry Austin
Larry Linson
advanced compiler is the answer to all problems... they have been around
since Computer Science departments began teaching courses in compiler
writing.
When I was in the corporate world, we got more than a few applicants who
expected compiler writing to be going on at all or most installations of
every worldwide corporation and, of course, that's what they wanted to do.
It's hard to describe their genuine surprise when told that at most, a few
hundred, and likely fewer than one hundred, people worked on writing
compilers at even the largest computer company (in those days, IBM when it
had 250,000 - 300,000 employees).
--
Larry Linson http://www.ntpcug.org -- North Texas PC User Group
http://members.tripod.com/ntaccess -- Access SIG
http://members.tripod.com/accdevel -- Access Samples and Examples
http://appdevissues.tripod.com/downloads.htm -- Presentations
"Terry Austin" <tau...@hyperbooks.com> wrote in message
news:artkr...@enews3.newsguy.com...
Terry Austin
> I suppose there are still those who think that _their_ startling, new,
> advanced compiler is the answer to all problems... they have been
> around since Computer Science departments began teaching courses in
> compiler writing.
>
> When I was in the corporate world, we got more than a few applicants
> who expected compiler writing to be going on at all or most
> installations of every worldwide corporation and, of course, that's
> what they wanted to do. It's hard to describe their genuine surprise
> when told that at most, a few hundred, and likely fewer than one
> hundred, people worked on writing compilers at even the largest
> computer company (in those days, IBM when it had 250,000 - 300,000
> employees).
I don't think it's so much people who _intend_ to compile their
own compiler, so much as people who want a compiler powerful
enough to compile itself. Whether or not that idea is meaningful
in the real world is irrelevant, as programmers do not, for the
most part, live in the real world.
Jack Russell
fitted on one floppy (or made a reasonable file to email)
Jack Russell
D...@home.com
Have a good day...
Don
Terry Austin
> The other advantage of VB3 is that even with the run time stuff it all
> fitted on one floppy (or made a reasonable file to email)
No arguments with that. And the runtime itself didn't need to
be registered - just copy it in to the install directory and
everything ran fine.
J French
<tau...@hyperbooks.com> wrote:
<snip>
>
>I don't think it's so much people who _intend_ to compile their
>own compiler, so much as people who want a compiler powerful
>enough to compile itself. Whether or not that idea is meaningful
>in the real world is irrelevant, as programmers do not, for the
>most part, live in the real world.
Oddly enough most programmers land up writing interpreters simply
because parameterization is one of the first 'steps to enlightenment'.
Writing a compiler in VB should be very possible, in the past I have
produced utilities to generate ASM files
I like your point about the 'real world'
- IME there are many real worlds - and few people dwell in more than
one ...
J French
<tau...@hyperbooks.com> wrote:
>Jack Russell wrote:
>> The other advantage of VB3 is that even with the run time stuff it all
>> fitted on one floppy (or made a reasonable file to email)
>
>No arguments with that. And the runtime itself didn't need to
>be registered - just copy it in to the install directory and
>everything ran fine.
Same with VB5
I am uncertain about VB6
- but I have a suspicion that the DLL could be self registering
I just can't unregister my MSVBVM60.DLL
- although I can re-RegSvr32 it
so it is hard to be sure
Terry Austin
> On Mon, 25 Nov 2002 15:03:40 -0800, "Terry Austin"
> <tau...@hyperbooks.com> wrote:
>
>> Jack Russell wrote:
>>> The other advantage of VB3 is that even with the run time stuff it
>>> all fitted on one floppy (or made a reasonable file to email)
>>
>> No arguments with that. And the runtime itself didn't need to
>> be registered - just copy it in to the install directory and
>> everything ran fine.
>
> Same with VB5
>
> I am uncertain about VB6
> - but I have a suspicion that the DLL could be self registering
I think it is. I swear I've seen VB programs that Autorun on CDs,
and it's have to be to work reliably. I'm not sure how Windows would
react to having it in the program directory, though.
>
> I just can't unregister my MSVBVM60.DLL
> - although I can re-RegSvr32 it
>
> so it is hard to be sure
Better than that sure to be hard.
Terry Austin
Terry Austin
> On Mon, 25 Nov 2002 10:06:42 -0800, "Terry Austin"
> <tau...@hyperbooks.com> wrote:
> <snip>
>>
>> I don't think it's so much people who _intend_ to compile their
>> own compiler, so much as people who want a compiler powerful
>> enough to compile itself. Whether or not that idea is meaningful
>> in the real world is irrelevant, as programmers do not, for the
>> most part, live in the real world.
>
> Oddly enough most programmers land up writing interpreters simply
> because parameterization is one of the first 'steps to enlightenment'.
Sounds like too much work. But then, I'm not a programmer. I'm
a network admin who plays at programming, and few of the things
I've written have been used more than once or twice.
>
> Writing a compiler in VB should be very possible, in the past I have
> produced utilities to generate ASM files
Possible, certainly. The question is, is it worth the effort?
>
>
> I like your point about the 'real world'
>
> - IME there are many real worlds - and few people dwell in more than
> one ...
Certainly a valid viewpoint.
Terry Austin
Tom Shelton
"J French" <Bounce_...@iss.u-net.com_.bin> wrote in message
Ummm, both VB5 and 6 run times are self-registering active x components.
There is very little difference between the two runtimes. Check out MS dll
support database (these are the earliest versions of both listed):
FILE INFORMATION:
Name:msvbvm50.dll
Description:Visual Basic Virtual Machine
Version:5.0.36.9
DLLSelfRegister:Yes
FILE INFORMATION:
Name:msvbvm60.dll
Description:Visual Basic Virtual Machine
Version:6.0.81.76
DLLSelfRegister:Yes
If you want to pull them up your self...
http://support.microsoft.com/default.aspx?scid=/servicedesks/fileversion/dllinfo.asp
HTH,
Tom Shelton
J French
wrote:
<snip>
>Ummm, both VB5 and 6 run times are self-registering active x components.
>There is very little difference between the two runtimes. Check out MS dll
>support database (these are the earliest versions of both listed):
>
Thanks Tom, I was totally unaware of that
I've just used regsvr32 to unregister and register MSVBVM50.DLL
Fortunately it does seem to be self registering
Curiously I cannot find 'MSVBVM50' in the registry ...