Home > Archive > VC STL > January 2006 > Building for pre-XP using MS VS 7.0
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Building for pre-XP using MS VS 7.0
|
|
| ultranet 2006-01-17, 7:09 pm |
| I have some folks who don't have msvcp70.dll and msvcr70.dll are using my
stuff., and my dll fails to load for them. My stuff can't easily be linked
statically to c run-time, because of a dependency on another .lib that
imports the c run-time, therefore it's build using /MD.
I may be able to re-build the external .lib w/ static flags, but i doubt it
will really link to c run-time statically.
Therefore, i'm wondering how i could tell MS VC 7.0 IDE to build for pre-XP.
I'm not at home right now and can't try it out yet, so i'd appreciate your
feedback on whether something like one of the following would work:
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif
#ifndef WINVER
#define WINVER 0x0500
#endif
| |
| Heinz Ozwirk 2006-01-17, 7:09 pm |
| "ultranet" <ultranet@discussions.microsoft.com> schrieb im Newsbeitrag
news:8EC8E68A-5660-4A47-95D5-D20C6D758D56@microsoft.com...
>I have some folks who don't have msvcp70.dll and msvcr70.dll are using my
> stuff., and my dll fails to load for them. My stuff can't easily be linked
> statically to c run-time, because of a dependency on another .lib that
> imports the c run-time, therefore it's build using /MD.
> I may be able to re-build the external .lib w/ static flags, but i doubt
> it
> will really link to c run-time statically.
>
> Therefore, i'm wondering how i could tell MS VC 7.0 IDE to build for
> pre-XP.
> I'm not at home right now and can't try it out yet, so i'd appreciate your
> feedback on whether something like one of the following would work:
> #ifndef _WIN32_WINNT
> #define _WIN32_WINNT 0x0400
> #endif
>
> #ifndef WINVER
> #define WINVER 0x0500
> #endif
Before anything else, I would try to ship the missing DLLs with my app. IIRC
these DLLs can simply copied into the same directory as the app itself, or
you can look on you VC CD for the proper MSIs.
HTH
Heinz
| |
| ultranet 2006-01-17, 7:09 pm |
|
"Heinz Ozwirk" wrote:
> Before anything else, I would try to ship the missing DLLs with my app. IIRC
> these DLLs can simply copied into the same directory as the app itself, or
> you can look on you VC CD for the proper MSIs.
>
That would be my 2nd or 3rd choice (there's also the option of building the
dll w/ VC 6.0 instead). But my first choice would be to try making VC 7.0
link to msvcrt.lib in a way that only uses backwards-compatible symbols (no
7.0+ symbols). I'll try it today or tomorrow.
| |
| Carl Nettelblad 2006-01-17, 7:09 pm |
|
"ultranet" <ultranet@discussions.microsoft.com> wrote in message
news:F3072C3D-A1F2-4C44-8D0E-7B2612FB4634@microsoft.com...
>
>
> "Heinz Ozwirk" wrote:
>
> That would be my 2nd or 3rd choice (there's also the option of building
> the
> dll w/ VC 6.0 instead). But my first choice would be to try making VC 7.0
> link to msvcrt.lib in a way that only uses backwards-compatible symbols
> (no
> 7.0+ symbols). I'll try it today or tomorrow.
I'm sorry, but this is not possible. You could, possibly, replace the whole
CRT with the VC 6.0 versions. It would link to the old DLL, accordingly.
This would still not solve your problem, as you mention the dependency lib.
Of course, depending on what DLL imports are actually used, you could
manually rename the DLL dependency in your finished PE file. In some limited
cases, that might work, but I wouldn't trust that kind of solution in
production use. The only reasonable method is to redistribute the DLL.
/Carl
| |
| ultranet 2006-01-17, 7:09 pm |
|
"Carl Nettelblad" wrote:
> I'm sorry, but this is not possible. You could, possibly, replace the whole
> CRT with the VC 6.0 versions. It would link to the old DLL, accordingly.
> This would still not solve your problem, as you mention the dependency lib.
1. Well, actually the dependency lib was built using 6.0. The only thing
about it is that it prevents me, as of now, from linking to c runtime
statically.
> Of course, depending on what DLL imports are actually used, you could
> manually rename the DLL dependency in your finished PE file. In some limited
> cases, that might work, but I wouldn't trust that kind of solution in
> production use. The only reasonable method is to redistribute the DLL.
2. Yeah, i'd rather not go there.
So from what you are saying, i read that i should be able to rename 7.0
MSVCRT.LIB to MSVCRT.bak, copy 6.0 MSVCRT.LIB in its place, build the
project, and hopefully the resulting dll will be pre-XP-compliant in my case.
I really think this should be more developer-friendly, but if this works,
i'll be set for this time.
Thanks.
| |
| Stephen Howe 2006-01-17, 9:58 pm |
| >I have some folks who don't have msvcp70.dll and msvcr70.dll are using my
> stuff., and my dll fails to load for them.
What do you mean by "fails"? Spell it out.
Is there an error message at startup of your application?
Do you mean that it complains that these DLLs are missing on your clients
version of Windows?
You are allowed to ship the RunTime DLLs with your app, in fact if your DLL
requires the RTL DLLs to work, you _SHOULD_ be shipping them with your app.
They are a necessary component for your application to work and in that
sense, they _ARE_ part of your application. You have Microsoft's blessing to
do exactly this. What you are not allowed to do is ship the debug version of
these DLLs with your application. The RT DLLs are effectively the code /data
equivalent of the static LIBs which LINK would insert into your application.
So it is just a difference of location as to whether the RunTime code/data
forms part of your application or is in DLL form and separate from your
application.
If you mean something else by "fails", say so (like a missing API).
> My stuff can't easily be linked
> statically to c run-time, because of a dependency on another .lib that
> imports the c run-time, therefore it's build using /MD.
Right. In that case, ship the RunTime DLLs with your application. It makes
perfect sense.
Stephen Howe
| |
| Ulrich Eckhardt 2006-01-18, 4:00 am |
| ultranet wrote:
> "Carl Nettelblad" wrote:
> 2. Yeah, i'd rather not go there.
Why? That's the way it works and how it's supposed to work.
> So from what you are saying, i read that i should be able to rename 7.0
> MSVCRT.LIB to MSVCRT.bak, copy 6.0 MSVCRT.LIB in its place, build the
> project, and hopefully the resulting dll will be pre-XP-compliant in my
> case.
Don't do that. Also, your fixation on XP/pre-XP is simply a misconception.
The problem is that C++ libraries and compilers are incompatible to each
other. Smart people therefore built their libraries for different compilers
and with different names, so they can be installed alongside each other and
the user can take whichever lib fits their compiler.
BTW: I think this is the wrong newsgroup for this kind of question.
Uli
| |
| Stephen Howe 2006-01-18, 8:00 am |
| > Therefore, i'm wondering how i could tell MS VC 7.0 IDE to build for
pre-XP.
This is basic nonsense. There is no such thing as building for pre-XP. For
that to be so, Microsoft would to distribute different versions of the LIBs.
In any case, it is not needed. The resultant executables
should work across Windows NT 4.0, 2000, XP, 95,98, ME. The linker is faced
with exactly the same choices in terms of what executable you get when it
comes to linking with the standard Microsoft C & C++ libraries on offer. If
you search across the C source, it is remarkable how little version of
Windows makes any difference to what the C & C++ libraries should do.
You can mark an EXE with various attributes on linking but that is about it
(-subsystem) and that tells Windows how to run the final EXE.
Stephen Howe
| |
| ultranet 2006-01-18, 7:08 pm |
|
"Stephen Howe" wrote:
>
> What do you mean by "fails"? Spell it out.
> Is there an error message at startup of your application?
>
> Do you mean that it complains that these DLLs are missing on your clients
> version of Windows?
There are no errors, by dependencywalker gives errors saying those 2 dlls
are missing.
| |
| ultranet 2006-01-18, 7:08 pm |
|
"Ulrich Eckhardt" wrote:
> ultranet wrote:
>
> Why? That's the way it works and how it's supposed to work.
Because it's more hackish than necessary. Also, I've never done it, and
don't know which tools to use, and whether there are free tools at all. I
assume those will be non-MS tools, so there is also a question of trust to
the app provider, w/ all the spyware around these days.
| |
| ultranet 2006-01-18, 7:08 pm |
|
"Stephen Howe" wrote:
> pre-XP.
>
> This is basic nonsense. There is no such thing as building for pre-XP. For
> that to be so, Microsoft would to distribute different versions of the LIBs.
> In any case, it is not needed. The resultant executables
> should work across Windows NT 4.0, 2000, XP, 95,98, ME.
Yes, i'll try various things and i might end up shipping the 2 dlls as well.
There is a difference in comparison to static linking though:
it only adds about 85KB to my installer package. Shipping the other 2 dlls
adds about 800KB. For a small app like mine that's a big increase in
downloadable, but i understand that in the big picture, it doesn't matter
that much.
| |
| Arnaud Debaene 2006-01-18, 7:08 pm |
| ultranet wrote:
> "Ulrich Eckhardt" wrote:
>
> Because it's more hackish than necessary.
It is not hackish, but the recommended MS way : all your other solutions
are hackish!
> Also, I've never done it,
> and don't know which tools to use, and whether there are free tools
> at all.
The most simple solution is xcopy (or copy) all the necessary files in the
app folder. Not a big deal! How are you redistributing your app now?
> I assume those will be non-MS tools, so there is also a
> question of trust to the app provider, w/ all the spyware around
> these days.
Well, in more complicated scenariis, you may need a full blown installer
(MSI probably), but if you only rely on the DLL crt, xcopy is fine.
Anyway, distribution is part of the developement cycle, and you should take
it into account. If you need a full blown MSI pacakge :
- it is possible to build one with Visual Studio ("Setup project").
- for complicated cases (eg, install a driver), you may indeed need a
third-party tool such as InstallShield or others. Concerning the trust
question, have you ever yourself renounced to install a soft because you
didn't know how the MSI was built ??? (btw, an MSI is signed, so chances of
hacking are reduced).
Arnaud
MVP - VC
| |
| ultranet 2006-01-20, 7:12 pm |
|
"Arnaud Debaene" wrote:
>
> It is not hackish, but the recommended MS way : all your other solutions
> are hackish!
>
> The most simple solution is xcopy (or copy) all the necessary files in the
> app folder. Not a big deal! How are you redistributing your app now?
>
>
> Well, in more complicated scenariis, you may need a full blown installer
> (MSI probably), but if you only rely on the DLL crt, xcopy is fine.
>
I thought you were talking about hacking the actual dll built against 7.0
run-time, to remove any 7.0 dependencies. If you meant shipping msvcp70.dll
and msvcr70.dll along w/ the app, then yes i don't consider that hackish.
P.S. It's just that it would increase my download size from 15KB to 815KB
(as opposed to 115KB, if i could link the run-time statically; which i may
look into doing again, but not sure if it'll work out).
| |
| Stephen Howe 2006-01-20, 7:12 pm |
| > P.S. It's just that it would increase my download size from 15KB to 815KB
> (as opposed to 115KB, if i could link the run-time statically; which i may
> look into doing again, but not sure if it'll work out).
I understand that. But you problem if I understand correctly is this 3rd
party library you link with.
This solution means a big increase in size but it is the 3rd party library
that forces this solution.
Stephen Howe
|
|
|
|
|