Visual Studio 2013 64 bit?

[Mike Lobanovsky]

While trying to compile the Script BASIC GFX extension module I ran into this strange error preventing the module to compile. Any ideas?

1. Both MSVCRT and MSVCR120 are VC runtime libraries, the former being older and more basic, the latter adding more functionality and being more recent. There's a fair chance that those memory functions are defined in the both (too lazy to check in Dependency Walker myself though ).

Try to do what your linker suggests. Open PROJECT->BlaBla Settings->Connfiguration Properties->Linker->Command Line and add to Additional Options either /NODEFAULTLIB:MSVCRT or /NODEFAULTLIB:MSVCR120, click Apply and rebuild. I don't think it'll help you though.

2. The error you're reporting may also occur if some of the modules link against dynamic-link libraries while others link against static ones. This can be avoided in the following way. Go to PROJECT->BlaBla Settings->Configuration Properties->C/C++->Code Generation->Runtime Library and make sure:

2.1. your Debug and Release versions are set to /MTd and /MT, respectively, if you're linking everything statically; or

2.2. your Debug and Release versions are set to /MDd and /MD, respectively, if you want your project to link against dynamic link libraries.

It seems mixed linking is not permitted in your case due to naming conflicts.

I think this second hint will help.

[John]

Everything but the GFX extension module is compiled with VS2013 console VC++ 12 compiler. As long as the MinGW64-TDM gcc compiler plays well with VC, I'm happy. I'm not going to fight with Microsoft's compiler that can't figure out what system resource to use and asks me to experiment with compiler switchs to work it out.   

The GFX extension module is the most complex linking wise of all the extension modules. (scriba -> gfx.dll (sb ext. mod.) -> SDL_gfx.dll -> SDL.dll)

I would rather spend the effort trying to get scriba to look like a Windows application.    (no console support) I can create a sbiup.exe (Windows application) fine with MinGW64-TDM.

[Mike Lobanovsky]

I'm not going to fight with Microsoft's compiler that can't figure out what system resource to use and asks me to experiment with compiler switchs to work it out.

MS VC is considerably stricter to its source code input than GCC. Without major rework, the FBSL sources can't be compiled with VC in principle. OTOH VC binary output may be substantially smaller than that of GCC and it compiles faster.

[John]

The important thing was I was able to get a Windows 64 bit version of Script BASIC and its extension modules working. I don't have a problem releasing the GFX extension module and sbw64.exe (GUI only - no console support) as MinGW64-TDM compiled binaries. I knew going into this Microsoft was the underdog with 64 bit compatibility. I hope to post a zip of this soon.

[John]

Mike,

Looks like you're right about VC12 being a bit faster than MinGW64, Here is the Mandelbrot example we used before. I also attached the Linux Script BASIC version. (64 bit this time)

Code: [Select]

' ScriptBasic GFX - Mandelbrot

IMPORT gfx.inc

s = gfx::Window(640,480,"ScriptBasic GFX Mandelbrot")
ts = gfx::Time()
FOR y = 0 TO 479
  FOR x = 0 TO 639
    cx = (x - 320) / 120
    cy = (y - 240) / 120
    rit = gfx::Mandelbrot(cx, cy, 510)
    gfx::PixelRGBA s, x, y, rit * 32, rit * 16, rit * 8, 255
  NEXT
NEXT
te = gfx::Time()
gfx::stringColor s, 20, 15, "Time: " & FORMAT("%.4f",(te-ts)/1000) & " Seconds." & CHR(0), 0x000000ff
gfx::Update
WHILE gfx::KeyName(1) <> "+escape"
WEND
gfx::Close


[Mike Lobanovsky]

I guess the first one is VC12, the second one, GCC, while the third one is obviously Ubuntu?

If my guess is right then more than two times faster is not "a bit faster". That's a hell of a lot faster!

[John]

You are correct in your assumptions. VC12 is definitely more picky and unforgiving.