From: "Vincent Snijders"

From: "Vincent Snijders"

Hi,

I don't think that my message of this afternoon has reached the mailinglist so I just send it again.

I have been able to make a running lazarus executable for windows 98.

The main obstacle to overcome was, that de gtk dlls for win32 don't export less procedure and functions than the unix libs. I temporarily commented out calls these missing functions:
gdk_pixmap_unref
gdk_draw_pixmap
gdk_bitmap_unref

Also I changed

  {$IFDEF MWE_FPC}
     {$IFDEF LINUX}
        LCLLinux,
     {$ELSE}
        Windows,
     {$ENDIF}
  {$ELSE}
     Windows,
  {$ENDIF}

to

  {$IFDEF MWE_FPC}
     LCLLinux,
  {$ELSE}
     Windows,
  {$ENDIF}

in the uses clause of mwcustomedit and made the appropiate changes in the rest of the unit.
I think this change is a good one because LCLLinux can also be used on win32 to access the winapi (and one define less).

My questions are:
Is lazarus suposed on win32 as well, and if so have are we going to solve the problems caused by missing exports?
Is LCLLinux going to be an OS-independent inteface to winapi and if so, shouldn't it get a better name?

Vincent Snijders

From: Peter Vreman

Maybe these will be resolved with the next release of gtk-win32. THere was a lot of reorderning in GDK as said on the gtk-win32 pages.

From: "Vincent Snijders"

Is this the one you were refering to? I could make this into a nice graphics if people would think it would be helpful.

Here is a layout of the libs. when using GTK+

------------------------------------------------------- | Application | ------------------------------------------------------- |
|
------------------------------------------------------- | Lazarus/LCL | ------------------------------------------------------- | | |
| | |
| | --------- | |----------------------------|------| GTK | | | | --------- | | | |
| | | |
| | -------------------- | | |-----------------| GDK | | | | -------------------- | | | |
| | | |
----------------------- -------------------- | GLIB | | X Window | ----------------------- --------------------

When using Gnome it gets even more complex because another layer which is Gnome sites inbetween Lazarus and the GTK+ library.

+ From: dvortex
+
+ On Wed, 26 Jan 2000, Shane Miller wrote:

+ > LCLLinux: I'm not sure about using LCLLinux under Win32. Sure, it
+ > seems like it could be done, but it's intent (and the
+ > reason we named it what we did) was that it would be used only
+ > under Linux. Maybe we'll have to revisit that and take a look
+ > at what the intent/possibilities are and rename it.

+ I don't want to step in at the wrong time, but it looks pretty obvious
+ to me that the name should be more something like LCLGTK
+ (gtk-linux and gtk-win32) than LCLLinux.
+
+ My understanding of the problem was that there would be a
+ LCLwin32 based purely on WinAPI (no GTK whatsoever).

The LCLLinux doesn't containt any gtk specific stuff. It contains routines which should be in the windows unit but can't be since they would break the platform independency of ppc (did I say this correctly ?)
Maybe a better name would be LCLWindows.

+ am I confused ?
+ (it is early ;p )

Maybe

Marc

Lazarus is supposed to run under win32. I'm not sure why the win32 dll's don't export those functions. Perhaps the dll's that you have aren't the latest. I don't know about that. Currently I and most of the other developers are concentrating on LINUX so I rarely if ever test it under win32.

LCLLinux: I'm not sure about using LCLLinux under Win32. Sure, it seems like it could be done, but it's intent (and the reason we named it what we did) was that it would be used only under Linux. Maybe we'll have to revisit that and take a look at what the intent/possibilities are and rename it.

Thanks for the input.
Shane

>> 01/25/00 06:21PM >>>

Hi,

I don't think that my message of this afternoon has reached the mailinglist so I just send it again.

I have been able to make a running lazarus executable for windows 98.

The main obstacle to overcome was, that de gtk dlls for win32 don't export less procedure and functions than the unix libs. I temporarily commented out calls these missing functions:
gdk_pixmap_unref
gdk_draw_pixmap
gdk_bitmap_unref

Also I changed

  {$IFDEF MWE_FPC}
     {$IFDEF LINUX}
        LCLLinux,
     {$ELSE}
        Windows,
     {$ENDIF}
  {$ELSE}
     Windows,
  {$ENDIF}

to

  {$IFDEF MWE_FPC}
     LCLLinux,
  {$ELSE}
     Windows,
  {$ENDIF}

in the uses clause of mwcustomedit and made the appropiate changes in the rest of the unit.
I think this change is a good one because LCLLinux can also be used on win32 to access the winapi (and one define less).

My questions are:
Is lazarus suposed on win32 as well, and if so have are we going to solve the problems caused by missing exports?
Is LCLLinux going to be an OS-independent inteface to winapi and if so, shouldn't it get a better name?

Vincent Snijders

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

From: Peter Vreman

Do the window API functions than correctly work with win32-gtk?

+ From: "Vincent Snijders"
+
+ ----- Original Message -----
+ From: Shane Miller

+ > I don't know about that. Currently I and most of the other
+ > developers are concentrating on LINUX so I rarely if ever
+ > test it under win32.
+ >
+ I understand that Linux is the main (development) platform, but IMHO
+ every once in a while the code should be tested for complatibility on
+ win32. I am willing to do that, if you want to.

I used to check under win32 as well but since OS2 cmd scripts are also interpeted under NT, it resulted in some handwork by myself, so I skipped checking for a while.

If you will do it, great.

+ > LCLLinux: I'm not sure about using LCLLinux under Win32. Sure, it
+ > seems like it could be done, but it's intent (and the reason we named
+ > it what we did) was that it would be used only under Linux. Maybe
+ > we'll have to revisit that and take a look at what the
+ > intent/possibilities are and rename it.

+ If it is not to be used on win32, more care has to be taken
+ in defining the interface of LCLLinux. Then it should match the
+ windows.pp interface exactly.
+
+ Example:
+ LCLLinux (actually WinApih.inc)
+ function ExtTextOut(DC: HDC; X, Y: Integer; Options: Longint; Rect:
+ PRect; Str: PChar; Count: Longint; Dx: PInteger): Boolean; override;

+ Windows.pp (actually ascdef.inc and unidef.inc)

As far as I know the calls should be compatible. The override should be between a IFDEF statement. This is because the WinApih.inc is defines all plain winapi functions as well as the member functions of the interfacebase class (depending of a DEFINE)

If we use LCLLinux on all platforms (what IMO is posible) all winapi funcs wrap to win32 api funcs.

+ Also new functions and constants (i.e. those not existing in the
+ windows.pp) can't put be put LCLLinux.
+ Example:
+ The constants CLR_INVALID and FW_BLACK are declared in LCLLinux but not
+ in Windows.pp (or its includes).

Thats another point. It confuses me. There is a VCLGlobals unit as wel. Now we use a mix of LCLLinux and VCLGlobals to define constants. I don't know wich one to use, if both we become eventually the same and so on. If LCLLinux will be used on all platforms, whats then the difference between LCLLinux and VCLGlobals.

Marc

From: dvortex

I don't want to step in at the wrong time, but it looks pretty obvious to me that the name should be more something like LCLGTK (gtk-linux and gtk-win32) than LCLLinux.

My understanding of the problem was that there would be a LCLwin32 based purely on WinAPI (no GTK whatsoever).

am I confused ?
(it is early ;p )

Yes! This is the one.

So the LCL is talking to the GDK, but not to the X-window system. That means, that with GTK on win32 I wouldn't need to call win32 GDI-functions from the LCL, doesn't it?

If you are going to make the graphics, I would suggest you'd make it for several widget set / OS combinations, e.g. GTK/Linux, QT/Linux, GTK/windows, win32/windows.
That way, I could see, where things change due to changes in OS or widget set.