Hello,

I am porting fpgfx to Windows CE. During this work I noticed a lot of incompatibilities between win32 windows unit and wince windows unit. Trivial stuff, like a parameter is var on win32, but is a pointer on wince.

Is there any special reason why it´s like that? Should we try to get both units as compatible as possible? Can I send a patch for that?

thanks,

I'm not an expert on the windows unit but I encountered similar problems among platforms and I think we should defenetly go for compat. The best thing you can do (so nobody can say anything) is "complement" both ends. So eg:

you got this in 2 windows unit:

W1. function A(const data): Pointer;
W2. function A(data: Pointer): Pointer;

Best is to complement both W1 and W2 so they both have both overloaded versions. It's not nice, but this way you ensure 100% compat and everyone is happy. Ofcourse since WINCE isn't stable yet it might be cleaner to just copycat the windows ones into it.

Ales

This is not as perfect as it looks, since you get overloading errors if you have more than one such argument. Don't if not necessary.

2007/1/7, Aleš Katona :

All patch / comments /remarks are welcome :)

NO, fpc wince current thrunk is very good, and excellent quality (in the past there was some issues during internal linker implementation so it was not the case for all svn rel but since a few months it's very good)

wince api is not complete but i can say you that fpc-arm-wince is waiting for the 2.2 :)

cleaner to just copycat the windows ones into it.

Ales

this is what i did since more than one year,
actual wince api was first inherited from last year win32.

i copy/paste them, then removed unexisting wince funcs and then start adding new ones.

at the beginning i keepts possible common files for both win32/wince using ifdef. (you can look in 3month old svn inc files) but after one year i saw that nobody have interest on that. only recently ifdef and win32 declarations where removed. why ?

1°)calling conventions are differents, some type/record have same name but are differents
and even M$ have separated sysgen files, possibles futures issues with ce 4.2, 5, 6 versionning
that can introduce also ifdefs
2°)it was discussed last year here and florian+yuri thinked it was better to separate
i was first against this but finally be convinced

now, every time i can test some new api, i add them some are already missing but i've added all api available functions names at the beginning
of .in files, so any one who need something to be added can drop a line or send a patch
(here or directly to me) then i'll do my best to check an apply asap.

in one year i only received 1 patch+request from Rozbeeh and it was applied in less than 24h

regards
or

From: "Felipe Monteiro de Carvalho"

The parameters incompatibility between win32 and wince exists because Delphi compatible declarations are not complete. Look into rtl/wince/wininc/redef.inc file. Currently it has only few wince redeclarations. Please uncomment/fix needed redeclarations of API functions and create patch. wince/win32 ifdefs need to be removed at all from this file.

PS: Did anyone test trunk subversion fpc with windows ce? does it work?

As Oliver said current trunk is stable for wince target.

Yury Sidorov.

one big problem with this sort of thing is that you can pass anything to an untyped const parameter *INCLUDING* a pointer, so if you change something from taking an untyped pointer to taking an untyped const parameter you are going to cause strange bugs for users.

one big problem with this sort of thing is that you can pass anything to an untyped const parameter *INCLUDING* a pointer, so if you change something from taking an untyped pointer to taking an untyped const parameter you are going to cause strange bugs for users.

I'm not saying that you should add this, only add if it's in one version of the unit AND you feel compat. is important.

I'm not particularly happy with "pascalization" of direct interfaces myself.

Ales

I'm not particularly happy with "pascalization" of direct interfaces myself.

me neither, my understanding of this problem is that borland pascalised the windows unit in delphi and freepascal followed suite for win32.

but for whatever reason the same was not done for wince.

since wince support is so new i'd normally say just change wince to match win32 but that will break a lot of wince using code in strange ways (as you will effectively be passing windows a pointer to a pointer when the windows api expects a pointer to data).

maybe the answer is to build two windows units, one called windows and only availible on win32 which will be effectively a delphi compatibility unit and marked as such in the docs and one called say winapi that will be a direct translation without any of this pascalisation.

originally win32 api was converted with fpc tool automatically this is why it's closer to c than delphi equ declarations.

as yury indicated , compatibility adaptation should be done in redef

2007/1/7, peter green :

Op Sun, 7 Jan 2007, schreef peter green:

maybe the answer is to build two windows units, one called windows and only availible on win32 which will be effectively a delphi compatibility unit ...

No, the problem is not serious enough to warrant the extra development effort. While I'm a strong proponent of backwards compatibility, code breakage is a risk that comes with using unstable compiler versions. WinCE is a brand new FPC platform, and must be considered a moving target.

Daniël

I'm using Lazarus to do an application for WinCE that takes data from a local mysql database.

Doing the GUI staff was not hard, and i still didn't see any differences between wince and win32, except for some bug or "special functions" like the drag&drop on TLists objects that i wanted to use (i resolved differently).

Now Almindor is trying to port his lnet libs into wince (cause there seem to be no mysql support for wince), i think that THIS would be the primary target for WinCE cause compiling without network support is compiling a useless software... and no button-component-image can make it less useless.

If you have any ideas they would be very appreciated.

p.s. for wince testing i'm always here, but i'm not enough expert for developing patchs.

Ok, maybe I´m missing something here. Take a look at this code:

procedure TGDICanvas.DoFillTriangle(const P1, P2, P3: TPoint);
var
  pts : array[1..3] of windows.TPoint;
  pt: TPoint;
begin
  pt := Transform(P1);
  pts[1].X := pt.X;   pts[1].Y := pt.Y;
  pt := Transform(P2);
  pts[2].X := pt.X;   pts[2].Y := pt.Y;
  pt := Transform(P3);
  pts[3].X := pt.X;   pts[3].Y := pt.Y;
  NeedBrush;
  Windows.Polygon(Handle, pts[1], 3);
end;

Under Win32 it compiles OK, but cross-compiling for wince I get this:

C:\Programas\fpGUI\trunk\gfx\gdi\GFX_GDI.pas(629,33) Error:
Incompatible type for arg no. 2: Got "POINT", expected "LPPOINT"

On the line that calls Windows.Polygon

But I went to rtl/wince/wininc/redef.inc I the only occurence of Polygon I find is this one:

function Polygon(DC: HDC; var Points; Count: Integer): BOOL; external
'gdi32' name 'Polygon';

Isn´t that wrong?? I thougth wince didn´t have a gdi32 library, but it was called something else. Plus, the declaration has a var parameter, so I shouldn´t need the @

Next, I get even more confused because of this code:

procedure TGDIApplication.Run;
var
  Msg: TMsg;
begin
  DoBreakRun := False;
  while Windows.GetMessage(@Msg, 0, 0, 0) and
   (not (QuitWhenLastWindowCloses and (Forms.Count = 0))) and
   (DoBreakRun = False) do
  begin
    Windows.TranslateMessage(@msg);
    Windows.DispatchMessage(@msg);
  end;
  DoBreakRun := False;
end;

It compiles and works on both win32 and wince, but Windows.GetMessage is declared like this:

function GetMessage(var lpMsg: TMsg; hWnd: HWND; wMsgFilterMin,
wMsgFilterMax: UINT): BOOL;external 'user32' name 'GetMessageA';

Do I have a wrong idea of the sintax of var parameters??? I never knew it would accept both with @ and without and produce the same code...

by the way, I am using mode delphi

Hi,

redef.inc of wince was copied from win32 and almost all redefinition are hidden by {$ifdef win32} So compiler only see the following declaration of Polygon in coredll.inc:

function Polygon(_para1:HDC; _para2:LPPOINT; _para3:longint):WINBOOL; external KernelDLL name 'Polygon';

The compiler also see the following declaration of GetMessage in coredll.inc:

function GetMessage(lpMsg:LPMSG; hWnd:HWND; wMsgFilterMin:UINT; wMsgFilterMax:UINT):WINBOOL; external KernelDLL name 'GetMessageW';

I made redef.inc wince only in rev. 5845 and made available Polygon and GetMessage functions. Now you can see what definitions are active and what are commented out.
So other redefinitions need to be made in the same way.

Yury Sidorov.