[fpc-pascal] DecimalSeparator automatic change ?
Hi, I have strange problem, I have application on Windows 2012 Server, where is set locale to Slovak (DecimalSeparator is comma) In my application in DataModuleCreate I explicitly set FormatSettings.DecimalSeparator='.' (dot) All works as expected (decimal numbers are formated with dot), but after some time (hours) when application runs, DecimalSeparator changes back to comma ? Is it possible ? AFAIK International settings are initialised once in sysutils initialization section, or are they reevaluated later ? Thanks -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DecimalSeparator automatic change ?
On Fri, 17 Jan 2014, LacaK wrote: Hi, I have strange problem, I have application on Windows 2012 Server, where is set locale to Slovak (DecimalSeparator is comma) In my application in DataModuleCreate I explicitly set FormatSettings.DecimalSeparator='.' (dot) All works as expected (decimal numbers are formated with dot), but after some time (hours) when application runs, DecimalSeparator changes back to comma ? Is it possible ? AFAIK International settings are initialised once in sysutils initialization section, or are they reevaluated later ? They are initialized once in FPC. But there is a windows message that notifies applications when the settings change: http://stackoverflow.com/questions/7385357/window-message-notification-language-and-locale Maybe lazarus picks it up. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can Delphi load a small function of a shared lib written in Free Pascal 2.6.2?
I suggest you use COM interfaces to use FPC objects from Delphi code. While FPC class instance memory layout differs from Delphi class instance memory layout, COM interface instances should have identical memory layouts; so they should be accessible from Delphi code 17.01.2014, 04:31, silvioprog silviop...@gmail.com: 2014/1/16 Michael Van Canneyt mich...@freepascal.org On Thu, 16 Jan 2014, Michael Van Canneyt wrote: On Thu, 16 Jan 2014, silvioprog wrote: Hello, On Windows, I'm trying to serialize an object to JSON in Delphi 7, using FPC functions linked in a shared lib. I'm sendind a small demo in attached. To test it is very easy: 1. compile the libfpserializer.lpr file; 2. copy the generated lib to the demo/lazarus_ok folder; 3. copy the generated lib to the demo/delphi_bug folder; Now, compile the Lazarus project in lazarus_ok folder, compile, run and see that it works fine. Now, compile the Delphi project in delphi_bug folder, compile, run and see a bizzare bug that kills the app. So, in Delphi 7, its possible to consume a DLL written in Free Pascal? You cannot mix Delphi objects with FPC objects. They have a different memory layout, the RTTI is different etc. So what you try to do is not possible. I have somewhere a version of TJSONStreamer which uses SuperObject to write the JSON. If you want I can try to dig it up somewhere. Michael. Very good friend. I want, and it will be very useful to me. Thank you! :) -- Silvio Clécio My public projects - github.com/silvioprog , ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
Hello.
Thanks to Mister Hinst, i was able to load and run, in Windows, with
dynlib.pas, SoundTouch.dll. Perfect and re-thanks.
Now, i begin a other hard battle : load and run in Linux, libSoundTouch.so.
With the extremely helpful message of Mister Ewald : Try to find the names of
the symbols defined in the shared object (nm comes to mind).
I run nm and find the name of the procedures ( PS : without nm-Ewald's tip, you
must be a high soothsayer to find it)
For example, a C called procedure : soundtouch_getVersionString() becomes :
_ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
And, believe it or not... it works...
I have only a problem with one procedure:
This c procedure is declared as this :
SOUNDTOUCHDLL_API void __cdecl soundtouch_setSampleRate(HANDLE h, unsigned int
srate);
And i translate it like that :
soundtouch_setSampleRate : procedure(h : THandle; srate : cardinal); cdecl;
and for dynamic-loading :
Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
Sadly i get that message when i try to load that procedure :
An unhandled exception occurred at $7F7D76D61AE8:
EAccessViolation: Access violation $7F7D76D61AE8
(program exited with code: 217)
Does somebody have some light for this ?
Many thanks.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 01/17/2014 03:16 PM, Fred van Stappen wrote: I run nm and find the name of the procedures ( PS : without nm-Ewald's tip, you must be a high soothsayer to find it) For example, a C called procedure : soundtouch_getVersionString() becomes : _ZN10soundtouch10SoundTouch16getVersionStringEv() !!! The _ZN10soundtouch10SoundTouch16getVersionStringEv name mangling suggests that this is a C++ lib, not a C lib. Generally speaking, you can't call C++ libs from fpc. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
I run nm and find the name of the procedures ( PS : without nm-Ewald's tip,
you must be a high soothsayer to find it)
For example, a C called procedure : soundtouch_getVersionString() becomes :
_ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
The _ZN10soundtouch10SoundTouch16getVersionStringEv name mangling
suggests that this is a C++ lib, not a C lib. Generally speaking, you
can't call C++ libs from fpc.
Ludo
Yep, Ludo, many thanks to take care but...
I have a test program who use some procedures to test , for example :
FVersionID := soundtouch_getVersionId();
FVersionString := StrPas(soundtouch_getVersionString());
writeln(FVersionID);
writeln(FVersionString);
Result :
10800
1.8.0
So, it seems to work...
Those procedures are declared as this :
Pointer(soundtouch_getVersionId):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch12getVersionIdEv'));
Pointer(soundtouch_getVersionString):=
GetProcAddress(LibHandle,Pchar('_ZN10soundtouch10SoundTouch16getVersionStringEv'));
I only have problem with :
_ZN10soundtouch10SoundTouch16getVersionStringEv()...
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
I only have problem with :
_ZN10soundtouch10SoundTouch16getVersionStringEv()...
Ooops, have to read :
I only have problem with :
Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
In our previous episode, Fred van Stappen said:
I have only a problem with one procedure:
This c procedure is declared as this :
SOUNDTOUCHDLL_API void __cdecl soundtouch_setSampleRate(HANDLE h, unsigned
int srate);
And i translate it like that :
soundtouch_setSampleRate : procedure(h : THandle; srate : cardinal); cdecl;
and for dynamic-loading :
Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
Sadly i get that message when i try to load that procedure :
Handle is not defined on Linux. Many libraries emulate some handle type, but
it depends on the vendor if they make handle 32-bit or 64-bit.
Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. Adjust
the type you use at the FPC side if necessary.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
In our previous episode, Fred van Stappen said:
I have only a problem with one procedure:
This c procedure is declared as this :
SOUNDTOUCHDLL_API void __cdecl soundtouch_setSampleRate(HANDLE h, unsigned
int srate);
And i translate it like that :
soundtouch_setSampleRate : procedure(h : THandle; srate : cardinal); cdecl;
and for dynamic-loading :
Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
Sadly i get that message when i try to load that procedure :
Handle is not defined on Linux. Many libraries emulate some handle type, but
it depends on the vendor if they make handle 32-bit or 64-bit.
Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. Adjust
the type you use at the FPC side if necessary.
Yep, Marco, many thanks...
Hum, :
Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC.
Adjust the type you use at the FPC side if necessary.
How to do that ? (sorry, i do not understand)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 01/17/2014 03:55 PM, Fred van Stappen wrote:
I run nm and find the name of the procedures ( PS : without
nm-Ewald's tip, you must be a high soothsayer to find it)
For example, a C called procedure : soundtouch_getVersionString()
becomes : _ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
The _ZN10soundtouch10SoundTouch16getVersionStringEv name mangling
suggests that this is a C++ lib, not a C lib. Generally speaking, you
can't call C++ libs from fpc.
Ludo
Yep, Ludo, many thanks to take care but...
I have a test program who use some procedures to test , for example :
FVersionID := soundtouch_getVersionId();
FVersionString := StrPas(soundtouch_getVersionString());
writeln(FVersionID);
writeln(FVersionString);
Result :
10800
1.8.0
So, it seems to work...
Those procedures are declared as this :
Pointer(soundtouch_getVersionId):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch12getVersionIdEv'));
Pointer(soundtouch_getVersionString):=
GetProcAddress(LibHandle,Pchar('_ZN10soundtouch10SoundTouch16getVersionStringEv'));
That are functions without any parameters that seemingly don't do a lot.
Do you have any function working that takes a handle as a parameter?
What is the value of the handle that was returned?
Ludo
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 01/17/2014 03:55 PM, Fred van Stappen wrote:
I run nm and find the name of the procedures ( PS : without
nm-Ewald's tip, you must be a high soothsayer to find it)
For example, a C called procedure : soundtouch_getVersionString()
becomes : _ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
The _ZN10soundtouch10SoundTouch16getVersionStringEv name mangling
suggests that this is a C++ lib, not a C lib. Generally speaking, you
can't call C++ libs from fpc.
Ludo
Yep, Ludo, many thanks to take care but...
I have a test program who use some procedures to test , for example :
FVersionID := soundtouch_getVersionId();
FVersionString := StrPas(soundtouch_getVersionString());
writeln(FVersionID);
writeln(FVersionString);
Result :
10800
1.8.0
So, it seems to work...
Those procedures are declared as this :
Pointer(soundtouch_getVersionId):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch12getVersionIdEv'));
Pointer(soundtouch_getVersionString):=
GetProcAddress(LibHandle,Pchar('_ZN10soundtouch10SoundTouch16getVersionStringEv'));
That are functions without any parameters that seemingly don't do a lot.
Do you have any function working that takes a handle as a parameter?
What is the value of the handle that was returned?
Yep Ludo, thanks to answer and...
Indeed, all the functions without any parameters are working.
And all the other must be initialized with Soundtouch_setSampleRate(FHandle,
samrate);
And, because it does not work, i cannot try the other procedures...
PS : FHandle := soundtouch_createInstance();
Seems to work (i do not get error message)
and this one works too :
soundtouch_setChannels(FHandle, 2);
but this no :
soundtouch_setSampleRate(FHandle, 44100);
And without to set sample-rate, all other procedures are not working...
Many thanks
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
In our previous episode, Fred van Stappen said: Handle is not defined on Linux. Many libraries emulate some handle type, but it depends on the vendor if they make handle 32-bit or 64-bit. Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. Adjust the type you use at the FPC side if necessary. Yep, Marco, many thanks... Hum, : Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. Adjust the type you use at the FPC side if necessary. How to do that ? (sorry, i do not understand) Writeln(sizeof(THandle)); // for console apps somememo.lines.add(sizeof(THandle)); // for gui apps. I don't know if the Handle type in the header is defined by the C++ compiler or by the package itself. Consult their respective documentation for more info. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
Writeln(sizeof(THandle)); // for console apps FHandle := soundtouch_createInstance(); writeln(FHandle); Writeln(sizeof(FHandle)); Gives that result : 10321232 4 I don't know if the Handle type in the header is defined by the C++ compiler or by the package itself. Consult their respective documentation for more info. ? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
I don't know if the Handle type in the header is defined by the C++ compiler or by the package itself. Consult their respective documentation for more info. Here declaration of create instance : // Create a new instance of SoundTouch processor. SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_createInstance(); ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 01/17/2014 05:09 PM, Fred van Stappen wrote: I don't know if the Handle type in the header is defined by the C++ compiler or by the package itself. Consult their respective documentation for more info. Here declaration of create instance : // Create a new instance of SoundTouch processor. SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_createInstance(); That routine is defined in SoundTouchDLL.cpp which is the windows dll wrapper. Do you have the linux equivalent? Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 17:25, Ludo Brands wrote:
On 01/17/2014 05:09 PM, Fred van Stappen wrote:
I don't know if the Handle type in the header is defined by the C++
compiler
or by the package itself. Consult their respective documentation for more
info.
Here declaration of create instance :
// Create a new instance of SoundTouch processor.
SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_createInstance();
That routine is defined in SoundTouchDLL.cpp which is the windows dll
wrapper.
Note one detail: it is declared there as __stdcall, not as __cdecl, so perhaps
this has something to do with it?
@Fred: Also note that the type HANDLE is defined there as a pointer, so [as a
sanity test of sorts] sizeof(Handle {in pascal}) should be equal to
sizeof(HANDLE /*in C/C++*/).
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] win64 / zipper fphttpclient
I have implemented web access and unzipping of archives in my program. Compiling perfectly targetting win32. But when I wanted to mail a win64 version ... using ppcrossx64 ... it did not find zipper fphttpclient units ... Could anyone tell me how to make those units (and related ones if any) available for ppcrossx64? Thanks Philippe S. Lévi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
That routine is defined in SoundTouchDLL.cpp which is the windows dll wrapper. Do you have the linux equivalent? Ludo PS : For new new arriving : SoundTouchDLL.cpp is part of SoundTouch, a audio processing library : http://www.surina.net/soundtouch/download.html @ Ludo : In /source/SoundTouch/ there is SoundTouch.cpp I have compiled the package in Linux like said in readme with : ./bootstrap script, then configure, make all, sudo make install. And i get a libSoundTouch.so in usr/local/lib. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
Yep, there is a brand new wrapper from trunk : Of course, all the tests i have done are with that new wrapper... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 20:40, Fred van Stappen wrote: Yep, there is a brand new wrapper from trunk : Ha, then you use/compiled a different version. Since a `extern C` preserves the symbol name (that is the trick I use to link in a lot of external C++ code: just put extern C in front of the symbol). or it could be that I am completely missing something here. [for example: is the symbol `DLL_EXPORTS` defined at compile time?] -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
Ha, then you use/compiled a different version. Since a `extern C` preserves the symbol name (that is the trick I use to link in a lot of external C++ code: just put extern C in front of the symbol). or it could be that I am completely missing something here. [for example: is the symbol `DLL_EXPORTS` defined at compile time?] Hum, just put extern C in front of the symbol (no capito ;-( ) PS : Here the prototype-code of the Linux Pascal Wrapper i use : https://sites.google.com/site/fiensprototyping/soundtouch_linux.zip PS2 : We gonna get it, im sure... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
That routine is defined in SoundTouchDLL.cpp which is the windows dll wrapper. Do you have the linux equivalent? Oops, im full of doubt now... Do you think the SoundTouchDLL.h wrapper is for Windows only ( and, yes, the old wrapper uses stdcall (who is windows only)). And for linux how does the programmers to link to the library without wrapper ? Im loosed... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 21:14, Fred van Stappen wrote: Ha, then you use/compiled a different version. Since a `extern C` preserves the symbol name (that is the trick I use to link in a lot of external C++ code: just put extern C in front of the symbol). or it could be that I am completely missing something here. [for example: is the symbol `DLL_EXPORTS` defined at compile time?] Hum, just put extern C in front of the symbol (no capito ;-( ) What I'm trying to say is that if there is `extern C` in front of a symbol, C++ won't mangle the name. In the cpp file you attached in one of your previous mails, [assuming a C++ compiler] this is the case as per the expansion of the macro `SOUNDTOUCHDLL_API`; on one condition: that `DLL_EXPORTS` is defined. [hint: read ahead to the second part first as it might just solve your problem] Since you see mangled names, there must be an error or version mismatch somewhere in your build of the library. So I thought that perhaps you are using a compiled version of the library that still uses stdcall instead of cdecl. To get closer to the bug, try the following: - Compile with debug symbols everwhere (there is no such thing as overkill ;-) ) - Run your program in gdb and get a backtrace (`bt` on the command line of gdb), if the crash occurs at the end of the function in the library, or just after the call, then it might be a calling convention issue. If I am informed correctly (see http://stackoverflow.com/questions/3404372/stdcall-and-cdecl) then the difference between stdcall and cdecl lies in who cleans up the stack. A mismatch results in the stack being cleaned up twice or not at all. Both rather inconvenient to normal program flow. If this is the case, try changing calling conventions. PS2 : We gonna get it, im sure... [The Second Part --] Well, it seems I have found something interresting here (as already suggested by Marco); you don't define THandle in your library wrapper. THandle is defined as a longint (http://www.freepascal.org/docs-html/rtl/system/thandle.html), but you need a pointer. Try putting `Type THandle = pointer;` somewhere before the first usage of this type in your library wrapper. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
