VS2008 MSVCRT Runtime

[MikeT]

After reading this excellent thread:
http://www.masm32.com/board/index.php?PHPSESSID=d803fe6a16cb79ffa1c0a01407e687c1&topic=9803.0

As a solution to the C++ runtime distribution problem I figure I can just link all that stuff statically at link time.
using the Runtime Library option to Multi-threaded (/MT)
Project Properties -> C / C++ -> Code Generation -> Runtime Library -> Multi-threaded(/MT)

WRONG.
My 38k app is now 570k and still won't run. I realize I am immediatly deep in the soft and smelly.

After creating my first CGI "Hello World" response app and debugged it locally with the very cool and free Abyss web server, I uploaded it to the server running Windows Server 2003 and thus IIS and ran into the initial problem
http://typethinker.blogspot.com/2007/12/visual-c-application-configuration.html

Next I figured I would just remove all the debugging from the app and recompile. It failed with the warning
"LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs"
http://www.dribin.org/dave/blog/archives/2005/07/28/unfortunate_expert/

This got me deep into the project properties and finally I found the the right place to remove the debugging from the compile step:
Project -> Propeties -> c/c++ -> Preprocessor -> Preprocessor Definitions (remove DEBUG;)

That reduced the size to 230k and it still would not run!
http://sunriseprogrammer.blogspot.com/2008/09/dreaded-lnk4098-defaultlib-libcmt.html

Then I discover that C++ libraries need to come in 6 flavors to deal with this issue!
http://www.digcode.com/default.aspx?page=0f182164-605a-4ce2-b399-4aec241be5f7&article=c2cfe894-5837-452c-bbed-e25613014339

Luckily my Dll is a simple C style and the lib file I created using this technique
http://www.masm32.com/board/index.php?topic=12481.0
created a simple .lib file that refers to the Dll (without debugging code). However, the problem still remains for the app.

After reading about debugging in general
http://www.debuginfo.com/articles/gendebuginfo.html
I seem to have removed it from the app, but I am not clear why it still wont run. I am assuming it is because Windows Server 2003 does not contain the MSCRVT80.dll?

I *DO NOT* want to install the redistributable! I might as well throw in the towel and write in .NOT.

So I read this thread again
http://www.masm32.com/board/index.php?PHPSESSID=d803fe6a16cb79ffa1c0a01407e687c1&topic=9803.0
and tried to figure out how to implement this in baby steps as this thread assumed a lot of experience with VS2008.

First am I correct in assuming that Windows Server 2003 has the original MSVCRT.DLL?
Since this contains things like sprintf() etc which I do not use why can't I just remove this dependency all together?
I use ostringstream and the string class. Are these in MSVCRT80.DLL?
If I just copy MSVCRTxx.dll to the app directory this does not fix the problem. Why not?
Should I go backwards and use VS2006 to avoid these issues?


Added:
Mitchi I opened your two projects:
CRTDLL naked
MSVCRT_COMMANDLINE

The first failed to compile with link error:
MSVCRTD.lib(crtexe.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup
C:\C++Projects\mitchiVS2008Projects\CRTDLL naked\Debug\crtdll hehe.exe : fatal error LNK1120: 1 unresolved externals

The second compiled but does not run on Windows Server 2003 :(

[hutch--]

Mike,

I can sympathise with all of these things but what does this have to so with an assembler programmer's forum ? Surely the development environment you have chosen to work in should be supported by the vendor that you have bought it from.

There are a few members around here who know their way around PowerBASIC but then the vendor has maintaied a well supported forum to support his product If you choose to use a Microsoft development environment I would imagine you would purchase a support package from them if you need that level of support.

[GregL]

MikeT,

I would think linking statically would produce a stand-alone executable or dll. Try removing /DEFAULTLIB:libcmt.lib from the linker options. You said you are not using the C Run-Time Library functions, so you would be linking to libcpmt.lib for the Standard C++ Library functions. libcmt.lib could also be required.

If you are linking dynamically, from what I have found, you can:

• Do it the way Microsoft wants you to do it (link to msvcr80.dll and/or msvcp80.dll), it's really too much trouble trying to get around it.
• Use Visual C++ 6.0.

[MikeT]

>what does this have to so with an assembler programmer's forum ?
er, well I figured this was a continuation of the original thread
http://www.masm32.com/board/index.php?PHPSESSID=d803fe6a16cb79ffa1c0a01407e687c1&topic=9803.0

I was under the impression this site welcomed threads about anything low level and, with that previous thread, this subject seemed like it was of interest. However the previous thread did not provide the solution as advertised, so this was a follow up. Perhaps I should have used that thread instead?

I had no idea the forum crimes tribunal would be so strict. It would not be the first time I have been banned for asking the wrong  questions. I apologize if this is not welcome I thought it might be of interest, that's all.

>should be supported by the vendor that you have bought it from.
You are referring to Microsoft?

>PowerBASIC but then the vendor has maintaied a well supported forum to support his product
I no longer use powerbasic. The owner has banned me and many other good developers for offenses unspecified.
http://groups.google.com/group/alt.lang.powerbasic/browse_thread/thread/e1a056169a01cb21#


Greg,
Yes this all for Static linking.
I cant find that option under the linker section of the project properties. Could it be called something else?
I will try to get a hold of VS C++ 6.0

[GregL]

MikeT,

To answer some of your questions.

First am I correct in assuming that Windows Server 2003 has the original MSVCRT.DLL?

Yes, all versions of Windows since Windows 95 OSR2 include it.

Since this contains things like sprintf() etc which I do not use why can't I just remove this dependency all together?

Because you need to link in "start-up" code.  Also, the Standard C++ Library may have some dependencies on the C Run-Time Library (I'm not sure, I hardly ever use C++, just C).

I use ostringstream and the string class. Are these in MSVCRT80.DLL?

No, they are in the Standard C++ Library.

If I just copy MSVCRTxx.dll to the app directory this does not fix the problem. Why not?

Starting in Visual C++ 2005 the CRT DLLs are "Side-by-Side Assemblies". See Visual Studio 2005 DLL Hell.


I don't understand why you are getting that linker error. I think you should be able to get your DLL to compile with VS 2005.

Just a warning about VC++ 6.0, it doesn't run on Windows Vista or Windows 7, although it will run on Virtual PC 2007 on Vista or in "Windows XP Mode" (which is Virtual PC 2007 with a license for an XP host) on Windows 7.

Do you have any experience with MASM? You could use it to write your DLL, and people here would be glad to help you with doing that. Once you get the hang of it, it's not any more difficult than writing a DLL with C/C++.

Regarding the forum, it would have been better to post this in the "Assembler With Microsoft Visual C" sub-forum.

[hutch--]

Mike,

The bottom line is this IS an ASSEMBLER forum, not a picking ground for people who use other languages that are having problems with it. If you have issues with the PowerBASIC vendor you should take them up with the PowerBASIC vendor, this is not the place to do that.

The internet is awash with C++ support and Microsoft cater for people who use their product with various cost support systems. Do as Greg suggested and post this stuff in the subforum he suggested, these main forums are for assembler programmers.

[MikeT]

>Regarding the forum, it would have been better to post this in the "Assembler With Microsoft Visual C" sub-forum.
Oh I must apologize again. I just assumed it would fit in the same forum as the original thread.

>I don't understand why you are getting that linker error. I think you should be able to get your DLL to compile with VS 2005.
OK Ill ask in the language specific forums. This thread was about the conept more than the specifics

>Just a warning about VC++ 6.0, it doesn't run on Windows Vista or Windows 7,
Aaaah thats the catch. ok

>Do you have any experience with MASM?
Unfortunatly not. I bought a book on it in 1980 and never read it.

>You could use it to write your DLL, and people here would be glad to help you with doing that.
Oh I know. This is a great forum with great people. I always think twice about posting here. I certainly don't want to ask questions that have simple answers I could have got on any other forum.

I oftern run into MS people when I present at codecamps etc, but they are mostly evangelists who offer to hook me up with the blood and guts guys there. It is very difficult to get hold of anyone that actually knows anything at this level.

>Once you get the hang of it, it's not any more difficult than writing a DLL with C/C++.
Well therein lies the dilemma. As I move(run) away from powerbasic, I must make a decision and pick *a* new language. C/C++ is not my first choice if it were not for the wide use in industry.

The new IDE wraps C#, VB and C++. They are all converging on the same OOP approach for architecting software, and if you want to work on a team project, you gotta use one of these widely deployed languages, Since VB cannot even do multi threads its out. C# or .NOT and its managed code is conceptually offensive to me after spending 10 years writing to the flat API, so that leaves C/C++. Because C doesn't implement OOP, there is really only one choice if I want to work in the "real" world these days.

I would love to learn ASM, and I will in a few years. Its just a question of time. Right now I have pressing work that requires high level language, so I must find a way to use VS2008 that does not require existing customers to have to download and install some mystery runtime library. People are very wary of bloated apps that take over your machine these days. They hate it. Apart from that, it generates a support load with questions and concerns.


Hutch,
You brought up powerbasic not me. I am asking about MSCRVT runtimes. If you want to move the thread to a different forum thats fine.

[GregL]

MikeT,

I can see your dilemma.

Just a couple of notes after reading your posts again.

The debug version of the C Run-Time Library (MSVCRTD.DLL) does not come with Windows, only the release version does. The debug version of the library only comes with Visual Studio and legally is not redistributable.

Also, the single-threaded libraries are no longer included with Visual Studio 2005 and later.

See C Run-Time Libraries.

[MikeT]

Thank you so much for your time. I should probably do a little more compiler specific research this week and try some more permutations to see if I have mossed anything.

I am attempting to compile a multi threaded win 32 binary without any debugging code. My understanding is that this means I will not need the "d" version and thus sidestep the issue. The remaining issue is how to deploy the MSCRVT.DD without "installing" it to get around all the side by side nonsense.

[hutch--]

hmmmmm,

> Oh I must apologize again. I just assumed it would fit in the same forum as the original thread.

The original thread did not fit either, we exercise a little tolerance here and there but this forum will not end up as a dumping ground for second hand C++.

> You brought up powerbasic not me. I am asking about MSCRVT runtimes. If you want to move the thread to a different forum thats fine.

Note that this is a forum for its members, not an internet democracy. Ask assembler question in here and you will do fine, dump your "other language" problems in here and we will afford you the opportunity of finding support elsewhere.

[mitchi]

MikeT,

Getting good with linkers is a good thing because it allows you later on to skillfully mix ASM and C/C++ code (that's the whole point nowadays).
But right now, if you are still at the developping stage, just compile with the /MT switch and use these debug symbols too, use everything you can get.

Once everything works, you can start playing with linkers to link to MSVCRT.DLL and reduce the size of the executable.

[MikeT]

>this forum will not end up as a dumping ground for second hand C++.
I understand your fear, and I would not wish to do that.

> not an internet democracy.
I am doing my very best to show you the proper respect. I understand you are the Admin and I am trying to keep from making newbie blunders.

>dump your "other language" problems in here
I understand your concern. You know the issues some of us have had with powerbasic better than anyone. but I am done with that language and am moving on. I will not be discussing any of that here. I am focusing on moving forward. My next step is C++ for the reasons given above, and after that ASM.

mitchi:
>mix ASM and C/C++ code (that's the whole point nowadays).
Could you expand upon that a little please. Why is that relevant? What kinds of development is done this way? Is the ASM linked in as a .lib?

[GregL]

MikeT,

I am attempting to compile a multi threaded win 32 binary without any debugging code. My understanding is that this means I will not need the "d" version and thus sidestep the issue.

You are correct.  You can do debug builds while you are still developing and do a release build when it's ready to release.

The remaining issue is how to deploy the MSCRVT.DD without "installing" it to get around all the side by side nonsense.

You don't need to install it, MSVCRT.DLL is included with Windows.

To get around the 'side-by-side nonsense', link in the C Run-Time Library and/or the Standard C++ Library statically.  Or, if you want to link it in dynamically use VC++ 6.0.  Visual Studio versions later than 6.0 will force you to use the MSVCR70.DLL, MSVCR80.DLL or MSVCR90.DLL instead of MSVCRT.DLL (you can get around this but it's not easy, it's not worth it in my opinion).


You can write a DLL with MASM32 and call it from a C program very easily and from a C++ program with just a little more effort.