Scorpio bitbases

[Matthias Gemuh]

Why are there no distinctions new/old 32bit/64bit in the naming of the egbbdlls ?
Then one could throw all into one folder and engines would always pick the right egbbdll by name.
The other advantage would be that the GUI could send that one folder path to engines at runtime, as was discussed in WB forum.

Daniel seems ready to change current approach.

(a) Who would appreciate being able to dump all dlls into one folder and have engines grab what they need by name ?

(b) Who prefers instead to rename various dlls to one standard name before use ?

I personally prefer (a). Can someone make a poll ?

Matthias.

[Denis P. Mendoza]

Why are there no distinctions new/old 32bit/64bit in the naming of the egbbdlls ?
Then one could throw all into one folder and engines would always pick the right egbbdll by name.
The other advantage would be that the GUI could send that one folder path to engines at runtime, as was discussed in WB forum.

Daniel seems ready to change current approach.

(a) Who would appreciate being able to dump all dlls into one folder and have engines grab what they need by name ?

(b) Who prefers instead to rename various dlls to one standard name before use ?

I personally prefer (a). Can someone make a poll ?

Matthias.

I think a combination of a and b is best.

1. Rename the dlls (ex. egbbdll32.dll for 32-bit and egbbdll64.dll for 64-bit or whatever your engine calls) or just standardize the name from now on and onwards. Standardizing will make it simpler.
2. Dump it in the same folder with the bitbases and engines will grab what they call for.
3. You can have as many dll/s as you want (though not recommended) depending on the name of the egbb probing dll in the engine code.

In Toga and Scorpio, we just rename the 'EGBB_NAME' for 32 and 64-bit during compiling, based on the rules mentioned.

Code: Select all

#ifdef _MSC_VER
   #define EGBB_NAME "egbbdll64.dll"
#else
   #define EGBB_NAME "egbbso.so"
   #define HMODULE void*
   #define LoadLibrary(x) dlopen(x,RTLD_LAZY)
   #define GetProcAddress dlsym
#endif

I hope there are other alternatives too.

[Matthias Gemuh]

Why are there no distinctions new/old 32bit/64bit in the naming of the egbbdlls ?
Then one could throw all into one folder and engines would always pick the right egbbdll by name.
The other advantage would be that the GUI could send that one folder path to engines at runtime, as was discussed in WB forum.

Daniel seems ready to change current approach.

(a) Who would appreciate being able to dump all dlls into one folder and have engines grab what they need by name ?

(b) Who prefers instead to rename various dlls to one standard name before use ?

I personally prefer (a). Can someone make a poll ?

Matthias.

I think a combination of a and b is best.

1. Rename the dlls (ex. egbbdll32.dll for 32-bit and egbbdll64.dll for 64-bit or whatever your engine calls) or just standardize the name from now on and onwards. Standardizing will make it simpler.
2. Dump it in the same folder with the bitbases and engines will grab what they call for.
3. You can have as many dll/s as you want (though not recommended) depending on the name of the egbb probing dll in the engine code.

all you describe is what I mean by (a).

(b) uses only "egbbdll.dll" for all types of egbbdll versions.

Matthias.

[Denis P. Mendoza]

Why are there no distinctions new/old 32bit/64bit in the naming of the egbbdlls ?
Then one could throw all into one folder and engines would always pick the right egbbdll by name.
The other advantage would be that the GUI could send that one folder path to engines at runtime, as was discussed in WB forum.

Daniel seems ready to change current approach.

(a) Who would appreciate being able to dump all dlls into one folder and have engines grab what they need by name ?

(b) Who prefers instead to rename various dlls to one standard name before use ?

I personally prefer (a). Can someone make a poll ?

Matthias.

I think a combination of a and b is best.

1. Rename the dlls (ex. egbbdll32.dll for 32-bit and egbbdll64.dll for 64-bit or whatever your engine calls) or just standardize the name from now on and onwards. Standardizing will make it simpler.
2. Dump it in the same folder with the bitbases and engines will grab what they call for.
3. You can have as many dll/s as you want (though not recommended) depending on the name of the egbb probing dll in the engine code.

all you describe is what I mean by (a).

(b) uses only "egbbdll.dll" for all types of egbbdll versions.

Matthias.

Thanks. I stand corrected!