RE : [fpc-pascal] Windows test program
Thanks for the help.
I tried the winhello.pp. It works OK.
I can still not get my program to show from the command line (do not use gdb),
but now I
have something to work on (it shows OK from explorer).
Regards Carsten
OK. Found the problem. The program runs ok from the explorer but not from
inside lazarus. That's where the difference in process STARTUPINFO structure
comes from. Actually it is gdb that passes on the SW_HIDE in STARTUPINFO.
Running the program from the command line is fine but doesn't show anything
when lauched from gdb.
Ludo
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
de Ludo Brands
Envoyé : jeudi 23 juin 2011 19:35
À : cars...@beas.dk; 'FPC-Pascal users discussions'
Objet : RE : [fpc-pascal] Windows test program
The problem is in the line
ShowWindow(Window, CmdShow);
CmdShow is SW_HIDE (0) with fpc and SW_RESTORE (9) in Delphi.
CmdShow is a variable that is initialised in system.pp from
the process STARTUPINFO structure. Don't know why fpc starts
the process with SW_HIDE.
Change the line to
ShowWindow(Window, SW_RESTORE);
and the window will display;
Ludo
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
de Carsten Bager
Envoyé : jeudi 23 juin 2011 17:36
À : FPC-Pascal users discussions
Objet : [fpc-pascal] Windows test program
Hi
I have this test program. It compiles and runs (shows) under
Delphi (5.0). I can compile (and run it) it under FPC (2.4.4)
but it does not show anything. I can see it in
the Windows Job list - Processes but not under Programmes.
Anybody have a hint.
Regards
Carsten
C:\FPC\2.4.4\bin\i386-win32\fpc -WG generic.dpr
Free Pascal Compiler version 2.4.4 [2011/04/23] for i386
Copyright (c) 1993-2010 by Florian Klaempfl Target OS: Win32
for i386 Compiling generic.dpr Compiling resource generic.or
Linking generic.exe 106 lines compiled, 0.9 sec , 26992 bytes
code, 1688 bytes data
{}
{}
{ Demo program }
{ Copyright (c) 1991, 2007 by CodeGear }
{}
{}
{ Generic Windows application written in Turbo Pascal }
program Generic;
{$R GENERIC.RES}
uses Messages,Windows;
const
SAppName = 'Generic';
SAboutBox = 'AboutBox';
SWindowName = 'Turbo Pascal Generic';
IDOK = 1;
ID_OK = IDOK;
IDCANCEL = 2;
ID_CANCEL = IDCANCEL;
const
idm_About = 100;
function About(Dialog: HWnd; Message:LongWord; WParam,LParam:
Longint):LongInt;
stdcall;
begin
About := ord(True);
case Message of
wm_InitDialog:
Exit;
wm_Command:
if (WParam = id_Ok) or (WParam = id_Cancel) then
begin
EndDialog(Dialog, 1);
Exit;
end;
end;
About := ord(False);
end;
function WindowProc(Window: HWnd; Message:longword;
WParam,LParam: Longint):
Longint; stdcall;
begin
WindowProc := 0;
case Message of
wm_Command:
if WParam = idm_About then
begin
DialogBox(HInstance, SAboutBox, Window, @About);
Exit;
end;
wm_Destroy:
begin
PostQuitMessage(0);
Exit;
end;
end;
WindowProc := DefWindowProc(Window, Message, WParam, LParam); end;
var
WindowClass: TWndClass = (
style: 0;
lpfnWndProc: @WindowProc;
cbClsExtra: 0;
cbWndExtra: 0;
hInstance: 0;
hIcon: 0;
hCursor: 0;
hbrBackground: COLOR_WINDOW;
lpszMenuName: SAppName;
lpszClassName: SAppName);
procedure WinMain;
var
Window: HWnd;
Message: TMsg;
begin
{ Register the window class }
WindowClass.hInstance := HInstance;
WindowClass.hIcon := LoadIcon(0, idi_Application);
WindowClass.hCursor := LoadCursor(0, idc_Arrow);
if Windows.RegisterClass(WindowClass) = 0 then
Halt(1);
{ Create and show the window }
Window := CreateWindow(SAppName, SWindowName,
ws_OverlappedWindow,cw_UseDefault,cw_UseDefault, 320, 240,
0, 0, HInstance, nil);
ShowWindow(Window, CmdShow);
UpdateWindow(Window);
{ and crank up a message loop }
while GetMessage(Message, 0, 0, 0) do
begin
TranslateMessage(Message);
DispatchMessage(Message);
end;
Halt(Message.wParam);
end;
begin
WinMain;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
RE : RE : [fpc-pascal] Windows test program
MSDN states that the first ShowWindow is ignored if a STARTUPINFO is
provided.
winhello.pp has
ShowWindow(hWindow, CmdShow);
ShowWindow(hWindow, SW_SHOW);
This is the difference with your test program.
Ludo
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
de Carsten Bager
Envoyé : vendredi 24 juin 2011 08:53
À : FPC-Pascal users discussions
Objet : RE : [fpc-pascal] Windows test program
Thanks for the help.
I tried the winhello.pp. It works OK.
I can still not get my program to show from the command line
(do not use gdb), but now I
have something to work on (it shows OK from explorer).
Regards Carsten
OK. Found the problem. The program runs ok from the
explorer but not
from inside lazarus. That's where the difference in process
STARTUPINFO structure comes from. Actually it is gdb that passes on
the SW_HIDE in STARTUPINFO. Running the program from the
command line
is fine but doesn't show anything when lauched from gdb.
Ludo
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
de Ludo Brands
Envoyé : jeudi 23 juin 2011 19:35
À : cars...@beas.dk; 'FPC-Pascal users discussions'
Objet : RE : [fpc-pascal] Windows test program
The problem is in the line
ShowWindow(Window, CmdShow);
CmdShow is SW_HIDE (0) with fpc and SW_RESTORE (9) in Delphi.
CmdShow is a variable that is initialised in system.pp from
the process STARTUPINFO structure. Don't know why fpc starts
the process with SW_HIDE.
Change the line to
ShowWindow(Window, SW_RESTORE);
and the window will display;
Ludo
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
de Carsten Bager
Envoyé : jeudi 23 juin 2011 17:36
À : FPC-Pascal users discussions
Objet : [fpc-pascal] Windows test program
Hi
I have this test program. It compiles and runs (shows) under
Delphi (5.0). I can compile (and run it) it under FPC
(2.4.4) but
it does not show anything. I can see it in the Windows
Job list -
Processes but not under Programmes. Anybody have a hint.
Regards
Carsten
C:\FPC\2.4.4\bin\i386-win32\fpc -WG generic.dpr
Free Pascal Compiler version 2.4.4 [2011/04/23] for
i386 Copyright
(c) 1993-2010 by Florian Klaempfl Target OS: Win32 for i386
Compiling generic.dpr Compiling resource generic.or Linking
generic.exe 106 lines compiled, 0.9 sec , 26992 bytes
code, 1688
bytes data
{}
{}
{ Demo program }
{ Copyright (c) 1991, 2007 by CodeGear }
{}
{}
{ Generic Windows application written in Turbo Pascal }
program Generic;
{$R GENERIC.RES}
uses Messages,Windows;
const
SAppName = 'Generic';
SAboutBox = 'AboutBox';
SWindowName = 'Turbo Pascal Generic';
IDOK = 1;
ID_OK = IDOK;
IDCANCEL = 2;
ID_CANCEL = IDCANCEL;
const
idm_About = 100;
function About(Dialog: HWnd; Message:LongWord; WParam,LParam:
Longint):LongInt; stdcall;
begin
About := ord(True);
case Message of
wm_InitDialog:
Exit;
wm_Command:
if (WParam = id_Ok) or (WParam = id_Cancel) then
begin
EndDialog(Dialog, 1);
Exit;
end;
end;
About := ord(False);
end;
function WindowProc(Window: HWnd; Message:longword;
WParam,LParam: Longint):
Longint; stdcall;
begin
WindowProc := 0;
case Message of
wm_Command:
if WParam = idm_About then
begin
DialogBox(HInstance, SAboutBox, Window, @About);
Exit;
end;
wm_Destroy:
begin
PostQuitMessage(0);
Exit;
end;
end;
WindowProc := DefWindowProc(Window, Message, WParam,
LParam); end;
var
WindowClass: TWndClass = (
style: 0;
lpfnWndProc: @WindowProc;
cbClsExtra: 0;
cbWndExtra: 0;
hInstance: 0;
hIcon: 0;
hCursor: 0;
hbrBackground: COLOR_WINDOW;
lpszMenuName: SAppName;
lpszClassName: SAppName);
procedure WinMain;
var
Window: HWnd;
Message: TMsg;
begin
{ Register the window class }
WindowClass.hInstance := HInstance;
WindowClass.hIcon := LoadIcon(0, idi_Application);
WindowClass.hCursor := LoadCursor(0, idc_Arrow);
Re: [fpc-pascal] Linking to library on Mac
On 24 Jun 2011, at 00:06, Darius Blaszyk wrote:
I'm porting an app from delphi to lazarus and now I reached a
problem when trying to link to the library. The library comes with
the .dynlib .a and all header files. I placed them somewhere under
my homedir and added the following to my code:
{$linklib mylibrary}
I also pass the following switches to FPC (other tab on the project
options in Lazarus):
-k-L/Users/dariusblaszyk/mylibraryfolder/
Use -Fl instead of hardcoded linker parameters (it won't solve your
problem though)
However I keep on getting undefined symbols.
If the errors are at compile time, then you will have to show how you
are importing the routines in the Pascal code.
If the errors are at run time, then you may want to read the following
documents for information about that:
* http://qin.laya.com/tech_coding_help/dylib_linking.html
* http://doc.qt.nokia.com/qq/qq09-mac-deployment.html
How do I install the library properly on Mac and how do I make FPC/
Lazarus correctly aware of this lib. The lib comes with a version
number, do I need to make symlinks to keep everything orderly?
Please be concrete when asking for help (this also applies to the rest
of your mail): say what the actual file names are, what the exact
directives are that you use in the source code, and what the exact
compiler command line is you use to compile everything. Talking in
generalities (especially about a platform you are not familiar with)
and expecting people to figure out from that what the problem is does
not work.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Kudos to the FPC team
Hi, I know I'm sometimes hard on some developers. I guess sometimes one has to sit back and see the big picture too. While reading the following text from the OpenWatcom newsgroups, it made me realize what a great compiler and programming language we are using. A big thanks to the FPC team for making a GREAT compiler... and without compile times as listed below: --[ from a recent post in the OpenWatcom newsgroups ]- To give you a time schedule, my old Pentium 500MHZ took 12 hours for a complete build, now with quadcore 2,5 Ghz it is less than 1 hour. This is without docbuild. -- :-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Windows test program
That did the trick.
Carsten
MSDN states that the first ShowWindow is ignored if a STARTUPINFO is
provided.
winhello.pp has
ShowWindow(hWindow, CmdShow);
ShowWindow(hWindow, SW_SHOW);
This is the difference with your test program.
Ludo
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
de Carsten Bager
Envoyé : vendredi 24 juin 2011 08:53
À : FPC-Pascal users discussions
Objet : RE : [fpc-pascal] Windows test program
Thanks for the help.
I tried the winhello.pp. It works OK.
I can still not get my program to show from the command line
(do not use gdb), but now I
have something to work on (it shows OK from explorer).
Regards Carsten
OK. Found the problem. The program runs ok from the
explorer but not
from inside lazarus. That's where the difference in process
STARTUPINFO structure comes from. Actually it is gdb that passes on
the SW_HIDE in STARTUPINFO. Running the program from the
command line
is fine but doesn't show anything when lauched from gdb.
Ludo
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
de Ludo Brands
Envoyé : jeudi 23 juin 2011 19:35
À : cars...@beas.dk; 'FPC-Pascal users discussions'
Objet : RE : [fpc-pascal] Windows test program
The problem is in the line
ShowWindow(Window, CmdShow);
CmdShow is SW_HIDE (0) with fpc and SW_RESTORE (9) in Delphi.
CmdShow is a variable that is initialised in system.pp from
the process STARTUPINFO structure. Don't know why fpc starts
the process with SW_HIDE.
Change the line to
ShowWindow(Window, SW_RESTORE);
and the window will display;
Ludo
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
de Carsten Bager
Envoyé : jeudi 23 juin 2011 17:36
À : FPC-Pascal users discussions
Objet : [fpc-pascal] Windows test program
Hi
I have this test program. It compiles and runs (shows) under
Delphi (5.0). I can compile (and run it) it under FPC
(2.4.4) but
it does not show anything. I can see it in the Windows
Job list -
Processes but not under Programmes. Anybody have a hint.
Regards
Carsten
C:\FPC\2.4.4\bin\i386-win32\fpc -WG generic.dpr
Free Pascal Compiler version 2.4.4 [2011/04/23] for
i386 Copyright
(c) 1993-2010 by Florian Klaempfl Target OS: Win32 for i386
Compiling generic.dpr Compiling resource generic.or Linking
generic.exe 106 lines compiled, 0.9 sec , 26992 bytes
code, 1688
bytes data
{}
{}
{ Demo program }
{ Copyright (c) 1991, 2007 by CodeGear }
{}
{}
{ Generic Windows application written in Turbo Pascal }
program Generic;
{$R GENERIC.RES}
uses Messages,Windows;
const
SAppName = 'Generic';
SAboutBox = 'AboutBox';
SWindowName = 'Turbo Pascal Generic';
IDOK = 1;
ID_OK = IDOK;
IDCANCEL = 2;
ID_CANCEL = IDCANCEL;
const
idm_About = 100;
function About(Dialog: HWnd; Message:LongWord; WParam,LParam:
Longint):LongInt; stdcall;
begin
About := ord(True);
case Message of
wm_InitDialog:
Exit;
wm_Command:
if (WParam = id_Ok) or (WParam = id_Cancel) then
begin
EndDialog(Dialog, 1);
Exit;
end;
end;
About := ord(False);
end;
function WindowProc(Window: HWnd; Message:longword;
WParam,LParam: Longint):
Longint; stdcall;
begin
WindowProc := 0;
case Message of
wm_Command:
if WParam = idm_About then
begin
DialogBox(HInstance, SAboutBox, Window, @About);
Exit;
end;
wm_Destroy:
begin
PostQuitMessage(0);
Exit;
end;
end;
WindowProc := DefWindowProc(Window, Message, WParam,
LParam); end;
var
WindowClass: TWndClass = (
style: 0;
lpfnWndProc: @WindowProc;
cbClsExtra: 0;
cbWndExtra: 0;
hInstance: 0;
hIcon: 0;
hCursor: 0;
hbrBackground: COLOR_WINDOW;
lpszMenuName: SAppName;
lpszClassName: SAppName);
procedure WinMain;
var
Window: HWnd;
Message: TMsg;
begin
{ Register the window class }
[fpc-pascal] 6 byte real
Dear all, I discovered Free Pascal yesterday and I am working at recompilying my old Turbo Pascal (5.0) files. The first problem (but probably not the last) I encountered is the reading of my old data files (files of record of real) because of the 6 byte coding for real type in Turbo Pascal versus the 8 byte coding in free Pascal. Is there a simple way to fix that? Regards Alain___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 6 byte real
On 24 Jun 2011, at 13:08, Alain Van Muylem wrote: I discovered Free Pascal yesterday and I am working at recompilying my old Turbo Pascal (5.0) files. The first problem (but probably not the last) I encountered is the reading of my old data files (files of record of real) because of the 6 byte coding for real type in Turbo Pascal versus the 8 byte coding in free Pascal. Is there a simple way to fix that? Use the real48 type: http://www.freepascal.org/docs-html/rtl/system/real48.html The system unit includes overloaded assignment operators so you can directly assign fields of this type to double/extended afterwards. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Kudos to the FPC team
On Thu, Jun 23, 2011 at 10:09, Graeme Geldenhuys graemeg.li...@gmail.comwrote: Hi, I know I'm sometimes hard on some developers. I guess sometimes one has to sit back and see the big picture too. While reading the following text from the OpenWatcom newsgroups, it made me realize what a great compiler and programming language we are using. A big thanks to the FPC team for making a GREAT compiler... and without compile times as listed below: If that the reason you like FPC, then something is wrong :P Try to compile any C++ program using g++, and you'll figure it out yourself. I love FPC (and also join the Kudos) because they create a great advanced open source compiler without any commercial help (unlike gcc for example) and still have a product that can really compete with everything else, and most of the time even win :) --[ from a recent post in the OpenWatcom newsgroups ]- To give you a time schedule, my old Pentium 500MHZ took 12 hours for a complete build, now with quadcore 2,5 Ghz it is less than 1 hour. This is without docbuild. -- :-) Regards, - Graeme - Ido -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Kudos to the FPC team
On Fri, Jun 24, 2011 at 2:42 PM, ik ido...@gmail.com wrote: If that the reason you like FPC, then something is wrong :P Clearly you didn't pay enough attention while reading his post and missinterpreted it. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] porting to 64bit
Hi,
What's wrong on this condition to get the code running on 32 and 64bit:
// Get pointer to varlength data.
function GetVarLengthData(AVarLength:PAnsiChar):PAnsiChar;
begin
Result:=PAnsiChar(AVarLength){$IFDEF FPC}+SizeOf(PtrInt){$ELSE}+4{$ENDIF};
end;
Thanks in advance.
F.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] porting to 64bit
On Fri, 24 Jun 2011 16:56:09 +0200
fred f ffre...@gmail.com wrote:
Hi,
What's wrong on this condition to get the code running on 32 and 64bit:
// Get pointer to varlength data.
function GetVarLengthData(AVarLength:PAnsiChar):PAnsiChar;
begin
Result:=PAnsiChar(AVarLength){$IFDEF
FPC}+SizeOf(PtrInt){$ELSE}+4{$ENDIF};
I wonder why you cast a PAnsiChar to a PAnsiChar?
Without any further code your AVarLength can be anything.
Probably it is something like a Size plus Data.
Check your GetVarLengthSize function or whatever it is called in your
code for the size of the Size.
end;
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Kudos to the FPC team
If that the reason you like FPC, then something is wrong :P Having a FAST compile time is one of the reason I like FPC (or any Pascal compiler in general, most of them also compiles fast). Try to compile any C++ program using g++, and you'll figure it out yourself. Yup, 40 minutes bootstrap just for compiler and standard libraries. FPC (wpo-ed + packages) + Lazarus takes only 15 minutes. I've figured it out that FPC is MUCH FASTER to build ;) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Kudos-to-the-FPC-team-tp4520425p4521665.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Platform independent alternatives
Rewrite the threading code with FPC one (i.e. BeginThread - EndThread, or the more beautiful TThread). WaitForSingleObject... I've never used this, perhaps SyncObjs and its critical section handler? CloseHandle: depending on how you open it, close with its correct pair. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Platform-independent-alternatives-tp4518482p4521676.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Efficiency of generated code [x86_64]
Hi, I'm puzzled by some of the code generated for x64. Came across this earlier post; http://www.hu.freepascal.org/lists/fpc-pascal/2005-March/008175.html Compiling the simple example with the loop in a function I get much leaner meaner than the [i386] assembler in the original post, but I had to use O3 and that separate function to get full use of xmm registers instead of the stack. Program ; Function loop (A,B : double) : double; Var X : LongInt; Begin For X := 0 to 1000 do Begin A := A + X; A := A * B; End; loop := A; End; Var A,B : double; Begin A := 0; B := 0.9; loop (A,B); WRITELN (loop (A,B):0:9); end. Looking at the assembler loop code # Var A located in register xmm0 # Var B located in register xmm1 # Var $result located in register xmm0 # Var X located in register eax// AND xmm2 ! # [7] For X := 0 to 1000 do movl$0,%eax decl%eax .balign 4,0x90 .Lj7: incl%eax # [9] A := A + X; cvtsi2sdl%eax,%xmm2 addsd%xmm0,%xmm2 movsd%xmm2,%xmm0 # [10] A := A * B; movsd%xmm0,%xmm2 mulsd%xmm1,%xmm2 movsd%xmm2,%xmm0 cmpl$1000,%eax jl.Lj7 # [14] end; movsd%xmm0,%xmm0 addq$24,%rsp ret I am wondering what is the point of all the xmm2 stuff, apart from the initial transfer of X from %eax? I can't see the point of it. Not set any debugging options. What is wrong with the following? # [9] A := A + X; cvtsi2sdl %eax,%xmm2 addsd %xmm2,%xmm0 # [10] A := A * B; mulsd %xmm1,%xmm0 cmpl$1000,%eax jl.Lj7 # [14] end; Also puzzled by the final movsd %xmm0,%xmm0 What does this do? I would really like to be able to generate optimal (ie minimal) xmm code from Pascal without dropping into assembler. Are there any other compiler switches that would help? Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Platform independent alternatives
Some years ago, I started the port of my project (PascalSCADA) from Windows to others platforms. I found some issues doing this. I used all resources that the FPC RTL can offer. To thread, I used TThread class. The issues that I found porting this, is that Suspend/Resume don't works on others platforms than Windows. So I rewrite my code to don't use this. Windows messages was replaced by a class that I created to exchange messages between threads, not process. TCriticalSection worked as expected on all platforms, except because it isn't a recursive mutex on unix, like it's on Windows. Again, a little code change to avoid problems. TEvent works as expected on all platforms since FPC 2.4.x. How it was fixed only on FPC 2.4 version AND I want support FPC 2.2.x series, I created my own class of Event, based on changes of TEvent class of FPC. Now my project works fine at least on Windows, Linux and FreeBSD, using the thread support of FreePascal. I avoided to use advanced resources of threading of each OS to keep my project more platform independently as possible. Functions as WaitForSingleObject I'm avoiding to use. The best regards, Fabio 2011/6/24 leledumbo leledumbo_c...@yahoo.co.id: Rewrite the threading code with FPC one (i.e. BeginThread - EndThread, or the more beautiful TThread). WaitForSingleObject... I've never used this, perhaps SyncObjs and its critical section handler? CloseHandle: depending on how you open it, close with its correct pair. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Platform-independent-alternatives-tp4518482p4521676.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Platform independent alternatives
Am Freitag, 24. Juni 2011 19:55 schrieb fluisgira...@gmail.com: Some years ago, I started the port of my project (PascalSCADA) from Windows to others platforms. I found some issues doing this. I used all resources that the FPC RTL can offer. To thread, I used TThread class. The issues that I found porting this, is that Suspend/Resume don't works on others platforms than Windows. So I rewrite my code to don't use this. Windows messages was replaced by a class that I created to exchange messages between threads, not process. TCriticalSection worked as expected on all platforms, except because it isn't a recursive mutex on unix, like it's on Windows. Again, a little code change to avoid problems. TEvent works as expected on all platforms since FPC 2.4.x. How it was fixed only on FPC 2.4 version AND I want support FPC 2.2.x series, I created my own class of Event, based on changes of TEvent class of FPC. Now my project works fine at least on Windows, Linux and FreeBSD, using the thread support of FreePascal. I avoided to use advanced resources of threading of each OS to keep my project more platform independently as possible. Functions as WaitForSingleObject I'm avoiding to use. This sounds very familiar. .. the only thing I really miss is the WaitForMULTIPLEObjects .. b. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] resourcestring and const arrays
In Delphi I can use resource strings with const arrays and everything works correctly. For example, if I have a resource DLL with translated strings and this will work: resourcestring SSunday = Sunday; const SWeek: array[0..0] of string = (SSunday); begin WriteLn(SWeek[0]); end; I've tried doing the same with FPC's GetText unit and SetResourceStrings. SSunday gets translated correctly, but SWeek doesn't. Is that something that should work if I'm early enough in the initialization order, an unimplemented feature, or something that's unlikely to changed? Thanks, Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
In our previous episode, Craig Peterson said: In Delphi I can use resource strings with const arrays and everything works correctly. For example, if I have a resource DLL with translated strings and this will work: resourcestring SSunday = Sunday; const SWeek: array[0..0] of string = (SSunday); begin WriteLn(SWeek[0]); end; I've tried doing the same with FPC's GetText unit and SetResourceStrings. SSunday gets translated correctly, but SWeek doesn't. Is that something that should work if I'm early enough in the initialization order, an unimplemented feature, or something that's unlikely to changed? No, this is a problem of gettext. If you use dxgettext on Delphi instead of Windows built in resourcesystem there is the same problem. For this to work you really need resource types that work based on replacing memory areas, or use _() ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
Hi, I had similar problem, I think that this is because consts are filled when compiling and there is no way to change them at runtime. Try this trick with pointers: resourcestring SSunday = Sunday; const SWeek: array[0..0] of PString = (@SSunday); begin WriteLn(SWeek[0]^); end; Regards 2011/6/24 Marco van de Voort mar...@stack.nl In our previous episode, Craig Peterson said: In Delphi I can use resource strings with const arrays and everything works correctly. For example, if I have a resource DLL with translated strings and this will work: resourcestring SSunday = Sunday; const SWeek: array[0..0] of string = (SSunday); begin WriteLn(SWeek[0]); end; I've tried doing the same with FPC's GetText unit and SetResourceStrings. SSunday gets translated correctly, but SWeek doesn't. Is that something that should work if I'm early enough in the initialization order, an unimplemented feature, or something that's unlikely to changed? No, this is a problem of gettext. If you use dxgettext on Delphi instead of Windows built in resourcesystem there is the same problem. For this to work you really need resource types that work based on replacing memory areas, or use _() ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
On 6/24/2011 4:14 PM, Marco van de Voort wrote: No, this is a problem of gettext. It's a problem with FPC's resourcestring implementation, rather than something specific to gettext. I could use SetResourceStrings directly (objpas.pp) and it will have the same issue. For this to work you really need resource types that work based on replacing memory areas, or use _() What do you mean by replacing memory areas? Runtime patching? Does something exist that supports that? On Windows we're using resource DLLs directly, without going through gettext, so I really don't want to switch to _(). I don't mind low-level hacking though. ;) It looks like Delphi writes a table of these kinds of resource string uses and fixes them up during program initialization. If FreePascal had a similar table it could do the same thing as part of SetResourceStrings. Assuming Krzysztof is correct that the compiler flattens the references, I'm guessing replacing the FPC_RESOURCESTRINGTABLES section won't help either. If it would, I'd be happy to look into that approach too. If fixing this is correctly is a reasonable possibility, I'm happy to look into it myself, but I would like to hear how attainable it's likely to be first, since I've never worked on a compiler before. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
On 6/24/2011 4:52 PM, Krzysztof wrote: I had similar problem, I think that this is because consts are filled when compiling and there is no way to change them at runtime. Try this trick with pointers: Thanks Krzysztof. That looks like the least invasive approach, so if I can't get them working correctly that's what I'll do. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
