MSVCP80 implementation

Hi all,
  I'm attempting to get software to run which requires some functions in
MSVCP80 to be implemented.  Using the original DLLs is not an option for
us.  In particular, a couple of the allocator functions are being called
(msvcp80.dll.??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ
to give one such example).  I am sure there are more after this is fixed
too.
  Browsing the WINE source, I found references to some similarly mangled
functions in MSVCRT (the stream classes), but they did not seem to be
actually implemented:  in msvcrt/tests/cpp.c there was a demangling
test, but I didn't find much else that was directly related.
  So, my question is how WINE handles calls to any STL or C++ library
functions which may be included in these DLLs, and what approach I
should use to implement or forward calls to these kinds of functions. 
Any help would be much appreciated.

Thanks in advance,
Louis Gorenfeld
Muse Research

[Vitaliy Margolen]

[e-mail] wrote:
> Hi all,
>   I'm attempting to get software to run which requires some functions in
> MSVCP80 to be implemented.

You need to install msvc2005 redistributable runtime. The simplest way is
using winetricks: http://wiki.winehq.org/winetricks

Implementing all that is a huge waste of time.

Vitaliy.

[James McKenzie]

Vitaliy Margolen wrote:
> [e-mail] wrote:
> > Hi all,
> >   I'm attempting to get software to run which requires some functions in
> > MSVCP80 to be implemented.
>
> You need to install msvc2005 redistributable runtime. The simplest way is
> using winetricks: http://wiki.winehq.org/winetricks
>
> Implementing all that is a huge waste of time.

Legally speaking, we should start implementing all of the functions in 
the Win32/Win64 API.

Louis:

If you feel that you have the technical capabilities and can understand 
the method of implementing code in a clean room environment, please go 
ahead and start working on this.  Remember, test cases first that prove 
what the Win32/64 API does with this dll as implemented through Windows 
and then code the dll's functions.  Remember:  You cannot do this if you 
EVER looked at Windows code for this dll or attempt to reverse engineer 
it.  There are many legal reasons for this, the biggest is that 
Microsoft can attempt to shutdown this project.

For now, Vitally's suggestion is what we are using to implement this 
dll's functionality.

James McKenzie

[Dmitry Timoshkov]

"James McKenzie"  wrote:
> > > I'm attempting to get software to run which requires some functions in
> > > MSVCP80 to be implemented.
> >
> > You need to install msvc2005 redistributable runtime. The simplest way is
> > using winetricks: http://wiki.winehq.org/winetricks
> >
> > Implementing all that is a huge waste of time.
>
> Legally speaking, we should start implementing all of the functions in 
> the Win32/Win64 API.

MSVCP80 is not a part of win32 API, that's a redistributable run-time
library supposed to be provided by an application.

[Steven Edwards]

On Mon, Dec 22, 2008 at 10:31 PM, Dmitry Timoshkov
 wrote:
> MSVCP80 is not a part of win32 API, that's a redistributable run-time
> library supposed to be provided by an application.

Does the EULA allow for it to be packaged for use on non-windows
systems? If not then thats not an option for Winelib developers.

[Paul Chitescu]

On Tuesday 23 December 2008 16:22:52 Steven Edwards wrote:
> On Mon, Dec 22, 2008 at 10:31 PM, Dmitry Timoshkov
>
>  wrote:
> > MSVCP80 is not a part of win32 API, that's a redistributable run-time
> > library supposed to be provided by an application.
>
> Does the EULA allow for it to be packaged for use on non-windows
> systems? If not then thats not an option for Winelib developers.

Winelib developers have the option not to use Visual C++ runtimes at all.

If they need to access DLLs or executables installed by some other application 
then the other program should install MSV*80.DLL itself or the runtimes can 
be installed if missing just like you would do on Windows. The *other* 
application needs them and is legal to redistribute them being targeted at 
the Windows environment.

Paul Chitescu