OSDK source code : compilation problems ? or not ?

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

User avatar
waskol
Flight Lieutenant
Posts: 414
Joined: Wed Jun 13, 2007 8:20 pm
Location: FRANCE, Paris

OSDK source code : compilation problems ? or not ?

Post by waskol »

Well, well : DBug you had really good idea to release your OSDK !!!

Digging in it, I wanted to understand the Bas2Tap line 0 bug...

So I took my RAD studio, that includes also C an C++ development in order to recompile and trace...

Well I have also VC++ installed but I wanted to give a try with it ! :wink:
Why, just because I recompiled some the DOS Tools of fabrice I can find into "VISTA compatible" command line tools (I do not change the code of Fabrice : it usually compiles straight) and because Borlands compiler is supposed (I said "it is supposed", I wish I were right :wink: ) to be very good for size and speed optimization.

Just compare the result of wav2tap.exe compilation (same code compiled) :
(Author' compiler) --> (size) --> Vista/Seven compatibility
Fabrice'compiler --> 110 Ko --> so, so
Waskol' compiler --> 8Ko --> fully compatible
what a difference !


Well coming back to Bas2Tap.cpp/info.h compilation, I saw it requires common.h/common.cpp

Thus I created my new cpp project with those files in order to compile, and I got a bunch of errors :
Bas2Tap.cpp(70,12): Avertissement warning 8012: W8012 Comparaison de valeurs signées et non signées
common.cpp(68,39): Erreur error 2034: E2034 Impossible de convertir 'const char *' en 'char *'
common.cpp(68,39): Erreur error 2340: E2340 Mauvaise correspondance de type dans le paramètre 1 ('char *' désiré, 'const char *' obtenu)
common.cpp(75,50): Erreur error 2227: E2227 Paramètre supplémentaire dans l'appel à _open(const char *,int)
common.cpp(107,85): Erreur error 2227: E2227 Paramètre supplémentaire dans l'appel à _open(const char *,int)
1 Avertissement(s)
4 Erreur(s)
Temps écoulé 00:00:00.26
I've just start to dig in it, but for instance, the first error I got is this one :
common.cpp(68,39): Erreur error 2034: E2034 Impossible de convertir 'const char *' en 'char *'
concerns this portion of code :
bool LoadFile(const char* pcFileName,void* &pcBuffer,size_t &cBufferSize)
{
// get the size of the file
struct _finddata_t file_info;

if (_findfirst(pcFileName, &file_info)== -1)
{
return false;
}
...
yep the variable in the prototype of your function is a const :?

Do you think it is important to fix this kind of thing is your code, since anyway, it seems to compile and work with your Visual C++, or do you wish me to report them to you each time I find a bug and a fix ?

cheers
:P

________________________________________
Edit :
about the error generated on _Open, it comes from the fact that Borland and Microsoft do not have the same prototype for the _open function.
And it is Borland that do not the rules of ISO C++.
But on another hand, this function is deprecated for win32 and it is said that _sopen should be used instead (and for wich Borland c++ is OK too) , that would give, in common.cpp, this :

Code: Select all

int nHandle=_sopen(pcFileName,O_BINARY|O_RDONLY,SH_DENYWR,0);
instead of that :
int nHandle=_open(pcFileName,O_BINARY|O_RDONLY,0);[/code]

and this :

Code: Select all

int nHandle=_sopen(pcFileName,O_BINARY|O_WRONLY|_O_TRUNC|_O_CREAT,SH_DENYWR,_S_IREAD|_S_IWRITE);
instead of that

Code: Select all

int nHandle=_sopen(pcFileName,O_BINARY|O_WRONLY|_O_TRUNC|_O_CREAT,_S_IREAD|_S_IWRITE);
or may be it could be better to use the ANSI C/C++ fopen function instead, since it is more portable ?
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

The idea of having the common.cpp/h was to put there the code which is not portable, to wrap it, and make sure that none of the other applications uses directly non portable code.

About the size, it is not really a problem of compiler, it is a problem of default include libraries. Since nobody was really bothered by the size, i've not been playing the game of finding out which default libraries should be used. So yes by default a "hello world" with visual studio is in the tens of kilobyte size, but by tweaking some project parameters you can get it to the kilobyte size range or less.

Now, concerning the _findfirst, the problem is on Borland side. The filename parameter of the _findfirst API is not supposed to be modified, so it makes sense for it to be const. Except PictConv, everything compiles fine with Code::Blocks using mingw (GNU compiler), so it's not a "microsoft only" code.

Concerning the deprecation, etc... it is not because Microsoft has retarded ideas about what should and should not be deprecated that we should change our code. I personally don't give a shit to the secure CRT, imo you either use the C/Posix functions as they were intended to be used, or you use something else :)

Which version of the Borland compiler are you using ? There are free versions of Borland and Watcom that are maintained, and I believe these ones are standard compliant. I guess we could add some #ifdef OLDBORLAND in the code, but I would rather prefer for people to use modern compilers. Maintaing a code base so it works on more than one system is already hard enough.

About _open, well, I'd rather switch to pure C and drop posix then. I kind of hate the "fxxx" family, but I prefer a "fopen(bla,"r")" than a "_sopen". At least if we go pure C library, we most probably will work on any things running around.
User avatar
waskol
Flight Lieutenant
Posts: 414
Joined: Wed Jun 13, 2007 8:20 pm
Location: FRANCE, Paris

Post by waskol »

Anyway, do not worry, the compiler I've got can be set (I saw that yesterday) to be "compatible" with this or that standard.

I am using RAD Studio 2007 (given to me by Codegear for services offered to the Delphi community on developpez.com :D ).

as it was a very nice gift, I use it...
and it compiles Fabrice's source code so nicely ! :wink:

if your code stays like this, it won't bother me at all :)
What all matters is that it works once compiled in a flavour or another, don't you think so ?
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

waskol wrote:What all matters is that it works once compiled in a flavour or another, don't you think so ?
Well, considering that ideally the objective is to have native versions of the OSDK for all the systems people are using here, the notion of "works once compiled" can come with a lot of surprises :)

But yeah, I was more concerned by making the OSDK work at all, the fact it is portable or optimised was far behind.
Post Reply