MSVC 2005 Express Distribution Build?

Printable View

10-31-2006
Kurisu33

MSVC 2005 Express Distribution Build?

Hello, I tried to build a release build of my application. It does not use MFC or anything like that and it built great with the result being very small and fast.

3 files of size 15kb 15kb 104kb.

It ran great! Than I took it to another computer without MSVC++ 2005 Express Edition installed and when I tried to run it it gave the error "could not run bad configuration try reinstalling" or something like that. Someone advised me to go into project settings and change code generation setting from its default of Multi-threaded DLL /MD to Multi-threaded /MT than rebuild.. well it works now and seems to work on other systems however the code is much larger like a debug build with:

same 3 files except now at 76kb 75kb 154kb !

Ugg what is with MSVC++ 2005 Express? There default settings seem to be so gay... what am I missing? Can I somehow return to my original file sizes in the first build and not have to bundle my application with sets of random dlls as I've seen some others suggest doing. MSVC80.dll etc... I just want to share my basic application! is that so bad?

Thnx for any clarification of whats going on here... I'm not using MFC or anything.. just pure Win32 API...
10-31-2006
vart

Your basic application probably is calling some functions like strlen or fread...

You have 2 options - or link these functions in your application (Multi-threaded /MT flag)
or provide a dll that contains these functions.

Your choice.
10-31-2006
Kurisu33

Hmm.. how do I know what .dll I need to provide? I'm not aware that I am calling any unusual functions that would require an external library. All I'm using is basic Win32 API and one STL object which is a list.

So, what is my application calling that is not already provided with Windows? How do I know, which DLLs I need to include? I guess I just don't understand what my application is linking to during runtime or why?!?
10-31-2006
vart

Quote:

/MDMultithreaded DLLDefines _MT and _DLL so that both multithread- and DLL-specific versions of the run-time routines are selected from the standard .H files. This option also causes the compiler to place the library name MSVCRT.LIB into the .OBJ file.
Applications compiled with this option are statically linked to MSVCRT.LIB. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCRT.DLL, which must be available at run time to applications linked with MSVCRT.LIB.

msdn is a good place to start looking for such answers

if some Win API function is placed in the non-standrd dll it is in most cases noted in the description of the function
Like this:

Quote:

Requirements

Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Winsock2.h.
Library: Use Ws2_32.lib.
10-31-2006
Kurisu33

So what are you saying exactly? If I choose to build using the DLL setting to reduce code size at the very least I have to ship my application with MSVCRT.DLL? I've done a search on my computer for this file and it seems some applications have this file in their directory. Now I'm getting even more confused as the same file is in different sizes.

Alittle 261k here 335k there oop 315 over here 249? 289?

And it is even in my Windows/System32 folder... so err why would another system need me to ship this file to work? This part is really confusing me.

Or are you just saying that the Win32 API is requiring different dlls depending on various functions I'm using and these are the dlls that I need to find so forget MSVCRT.DLL?

I don't mind compiling my main program with Multi-threaded /MT as the extra size is manageable, however, my program has many custom DLLs that I will be writing and I need the Multi-threaded DLL /MD for minimal size. Is this something where I could build the main with /MT and the DLLs with /MD and all would work? There is very little to no Win32 API calls in my DLLs they are all in my main app. *sigh* Do I just have to keep building this crap and then copying it to a disk and moving to a new computer without MSVC 2005 Express to see if it works now? There must be an easier way to figure this all out.? Will WinXP and earlier versions like 95/98 require the same DLLs? Or will 95/98 require more?!?

Oh well off to MSDN to get even more confused I suppose.
10-31-2006
vart

Quote:

Now I'm getting even more confused as the same file is in different sizes.

Check the file version

Quote:

Is this something where I could build the main with /MT and the DLLs with /MD and all would work?

No it will not. better to compile everything with the same switch
cause if at least one dll will be compiled with /MD you'll need to provide the MSVCRT.DLL, in this case it has no meaning to compile something without this flag.

You'll need to provide exactly the same dll you link your application with. It should work on all versions of Windows (but I will not bet on this because it is responsibility of Microsoft to provide a backward compatibility)

about over dll-s I have no good solution to know which is provided with windows and which should be shipped with the application. Hope somebody here knows the universal algorithm to get this knowledge...
10-31-2006
Kurisu33

Quote:

You'll need to provide exactly the same dll you link your application with

Okie, errr how do I know which one my application is linking with?

C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\redist\win64\msvcrt.dll?
Version: 7.0.3790.1830
Uh its 932kb.. and 64-bit... which I could care less about.

C:\WINDOWS\WinSxS\x86_Microsoft.Windows.CPlusPlusR untime_6595b64144ccf1df_7.0.0.0_x-ww_2726e76a\msvcrt.dll?
7.0.2600.0
315kb

C:\WINDOWS\WinSxS\x86_Microsoft.Windows.CPlusPlusR untime_6595b64144ccf1df_7.0.2600.2180_x-ww_b2505ed9\msvcrt.dll?
7.0.2600.2180
335kb

C:\WINDOWS\ServicePackFiles\i386\MSVCRT.DLL?
7.0.2600.2180
335kb

C:\WINDOWS\system32\MSVCRT.dll?
7.0.2600.2180
335kb

I fear its the first one... is it? I still don't see why I can't just say hey stupid program go to users windows directory and use their DLL...

Ill continue to surf the web in search of answers, but you seem to be doing the best :D
10-31-2006
vart

you can... if you believe that the dll on the users computer provides all the functions needed by your applications. Otherwise user will see some nice windows message announcing that the spicific function cannot be found in the msvcrt.dll so the application should be closed.

you can use dumpbin with the /imports parameter to determine what functions from what dlls are imported by the exe or dll

search for the msvcrt.lib - this file is used by linker and try to understand what dll it is correlated
10-31-2006
Kurisu33

:D Sure am glad your online.. here I am browsing Microsoft's forums specifically dealing with MSVC++ 2005 Express and getting nowhere (currently on page 15 of 66) Lol i'm giving up on that madness and just listening to you from now on :P Gonna give your new idea some toying with and see what I can come up with..

Atleast I don't feel so bad, some others must be having the same problems:

http://forums.microsoft.com/MSDN/Sho...35822&SiteID=1
http://forums.microsoft.com/MSDN/Sho...15159&SiteID=1
http://forums.microsoft.com/MSDN/Sho...94887&SiteID=1
10-31-2006
Kurisu33

How much does a gun cost today?

Hmm.. I'm totally lost now.. so uh how do I tell my computer to link to the files on the user's system in the Windows directory?

Quote:

you can... if you believe that the dll on the users computer provides all the functions needed by your applications. Otherwise user will see some nice windows message announcing that the spicific function cannot be found in the msvcrt.dll so the application should be closed.

I'm getting so confused perhaps I should just try that and hope for the best?

------------------------------------------------------------------------------------------------------
Below is what happened when I tried to check dependencies, never done before so I'm kinda lost.

Eh, dumpbin no run...

Quote:

The application has failed to start because mspdb80.dll was not found. Re-installing the application may fix this problem.

Sad irony I suppose... I found the dll and put in the directory and it ran, but now Express wont' compile so I just removed the dll and instead decided to try and use Dependency Walker that came with Platform SDK and seems to be quite similar except with a GUI and extensive help files.

Anyways what am I looking for exactly? This is the results of my main application:

Quote:

C:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a 1e18e3b_8.0.50727.42_x-ww_0de06acd\MSVCP80.DLL
Version: 8.0.50727.42

??$?H_WU?$char_traits@_W@std@@V?$allocator@_W@1@@s td@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V ?$allocator@_W@2@@0@ABV10@PB_W@Z
??$?H_WU?$char_traits@_W@std@@V?$allocator@_W@1@@s td@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V ?$allocator@_W@2@@0@PB_WABV10@@Z
std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >(wchar_t const *)
std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >::~basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >(void)

When I expand the above I get:

Quote:

C:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a 1e18e3b_8.0.50727.42_x-ww_0de06acd\MSVCR80.DLL
Version: 8.0.50727.42

Like a hundred function references non of which I am specifically calling.

Then outside of that tree I have:

Quote:

C:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a 1e18e3b_8.0.50727.42_x-ww_0de06acd\MSVCR80.DLL
Version: 8.0.50727.42

With about 26 function references non which I am specifically calling and only one looks familiar
__dllonexit

Inside that is:

Quote:

C:\windows\system32\MSVCRT.DLL
Version: 7.0.2600.2180

_getdrives

_set_error_mode
void (*set_terminate(void (*)(void)))(void)
_get_terminate

Of course there are other dependencies like COMCTL32.dll; KERNEL32.dll; etc but I understand what those are for.

Quote:

search for the msvcrt.lib - this file is used by linker and try to understand what dll it is correlated

The .lib is just binary mumbo-jumbo no? How would I know what DLL its humpin?
10-31-2006
Ken Fitlike

Microsoft Visual C++ 2005 Redistributable Package (x86).
11-01-2006
Cat

Quote:

Originally Posted by Kurisu33

I still don't see why I can't just say hey stupid program go to users windows directory and use their DLL...

It would. If they HAD that DLL. Which is only installed into the Windows\system directory if MS Visual Studio or some other application put it there.

Just because it's in the system directory doesn't mean it comes with the OS. Many programs will install their own DLLs there.

Essentially, your program first looks in its own directory for the DLL. Then it looks in the system directory.

If you don't want to worry about it, just statically link the libraries and forget about it. It's not like we're living in the days where hard drives were 4 megabytes and cost $20,000. A few kilobytes are nothing to sweat.
11-01-2006
Kurisu33

Quote:

If you don't want to worry about it, just statically link the libraries and forget about it. It's not like we're living in the days where hard drives were 4 megabytes and cost $20,000. A few kilobytes are nothing to sweat.

True, but in my case I'm developing an app. based on a plugin architecture and may include hundreds of DLLs... Dynamically linking makes every custom DLL ~10kb while statically linking causes each DLL to be ~70kb.. 10kb x 100 DLLs is a lot smaller than 70kb x 100 DLLS.. and since I'm distributing over the web I want it to be very tiny for download times and competitiveness sake with similar apps. Plus, it sounds like statically linking to libraries is not exactly preferred as mentioned on the following site provided by Ken: http://msdn2.microsoft.com/en-us/library/ms235316.aspx

Quote:

It is not recommended to redistribute C/C++ applications that statically link to Visual C++ libraries. Furthermore, static linking does not allow for servicing the application and its dependent libraries by either the application's author or Microsoft. For example, consider an application that is statically linked to a particular library, running on a client computer with a new version of this library. The application still uses code from the previous version of this library, and does not benefit from library improvements, such as security enhancements.

Quote:

Originally Posted by Ken Fitlike

Microsoft Visual C++ 2005 Redistributable Package (x86).

Very good link, been reading through it and it is definitely answering a ton of questions and is basically a walk-through on application deployment and methods.. it even covers the dll dependicies using "dependent walker".... very helpful..