Visual Studio 8 issues

[Myria]

I noticed that this project is not making use of Visual Studio 8 correctly, and this could cause bugs and user inconvenience.

First of all, your program is not compiled using Service Pack 1 of Visual Studio 8. Service Pack 1 fixes a number of critical bugs in VS8 that result in generation of incorrect assembly code. In other words, bugs in the compiler could have introduced bugs into the emulator.

Second, there is no reason to require that your users specifically download the CRT from Microsoft. You can include this in your package as the raw DLLs, avoiding the CRT installer entirely. If you upgrade to VS8 SP1, this is more important, because otherwise users would have to download another CRT.

For the CRT, just drop two or three files into your .rar file. These files are authorized by Microsoft to be redistributed in applications by developers (see redist.txt). They are:

C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT\

Microsoft.VC80.CRT.manifest
msvcr80.dll

Those cover what you're using now. If you or your plugins plan to use the C++ STL, add msvcp80.dll. msvcm80.dll is for Managed C++; don't drop that in.

If you plan to build an x86-64 version (I think you should), use the amd64 directory.

Having the manifest in the directory will allow the program to load correctly without the files being installed in a global system directory.

Melissa

[drkIIRaziel]

Well, i dont have sp1 on this pc and im quite bored to install it ;p.VC2k5 generates quite fine code so far (actualy speed is a litl lower with sp1 -- yes i benchmarked it).I think its better to install the runtimes as shared assemblies as many applications will use em anyway.The setup included the runtimes (for beta 1, also i think beta 1 was compiled with vc2k5sp1, not sure atm .. hmm) but i never got around creating a setup for newer releases ;p.

Having an x64 build needs an x64 compiler for the dynarec, x64 driver for the dynarec ( a few parts of the dynarec core are in assembly, not much tho), x64 emitter backend (thats mostly done), a redesign of the block manager and relevant data structures so that they still work fast (despite the 2x larger pointers) and a few other minnor things.Also theres i the problem if no inline asm on the x64 compiler ;|.The rest of the code compiles as x64 allready (i used to have x64 builds around .. but without the dynarec its of limited use).Thats why dlls have name_platform.dll filenames .

While it whould be nice to have x64 builds its not worth the trouble.Almost any cpu that has x64 extentions can run nullDC fullspeed allready, if some dont its better to spend time optimizing the x86 backend than writing an x64 one