FLTK headers for FreeBasic OOP (no C wrapper)

Headers, Bindings, Libraries for use with FreeBASIC, Please include example of use to help ensure they are tested and usable.
Post Reply
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by VANYA »

angros47 wrote: Oct 07, 2022 13:50 Ok, found the issue: in the file "Fl_Clock.bi", the line

Code: Select all

	declare virtual destructor
should have been just:

Code: Select all

	declare destructor
Because the destructor was not virtual. I updated the file on github with the fix.
Now there are no problems. The program terminates without errors.
D.J.Peters
Posts: 8586
Joined: May 28, 2005 3:28
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by D.J.Peters »

@angros47 I got your tiny window / button test working on Windows 64-bit but if you do more real stuff you have many open forward references !

If you try to fix it include all files and work from one to the next !

try this:

Code: Select all

extern "c++"
#include once "Fl_Device.bi"
#include once "Fl_Window.bi"
#include once "Fl_Button.bi"
end extern
var win = Fl_Window(940,380,"Window")
var but = Fl_Button(10,30,150,30,"This is a button")
win.end_()
win.show
fl.run_
or this in other order:

Code: Select all

extern "c++"
#include once "Fl_Window.bi"
#include once "Fl_Button.bi"
#include once "Fl_Device.bi"
end extern
var win = Fl_Window(940,380,"Window")
var but = Fl_Button(10,30,150,30,"This is a button")
win.end_()
win.show
fl.run_
By the way this extra "extern / end extern" isn't needed:

Code: Select all

extern "c++"
#inlude "blabla.bi"
end extern
should be fixed also (it's easy)

how ever good job so far :-)

here are how I changed the file "FL.bi" for the Windows import lib's

Code: Select all

#ifdef FLTK_HAVE_CAIRO
 #include once "Fl_Cairo.bi"
#endif

#include once "Enumerations.bi"

#ifdef __FB_DOS__
 #inclib "NX11"
 #inclib "freetype"
 #inclib "nano-X"
 #inclib "mwin"
 #inclib "stdcxx"
 #inclib "fltk"
#else
 #ifdef __FB_WIN32__
  #ifndef __FB_64BIT__
   #error 666: Sorry only Windows 64bit are supported ATM.
  #else
   #libpath "lib/win64"
  #endif
 #else
  #ifdef __FB_LINUX__
   #inclib "stdc++"
   #inclib "X11"
   #inclib "Xrender"
   #inclib "Xext"   
  #else
   #error 666: Sorry build target must DOS, WIN64 or Linux !
  #endif
 #endif 
#endif
#inclib "fltk"
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by angros47 »

The "extern... end extern" is something I forgot to remove, from a previous test

About the loose references, you are right, although I think it's better to finish porting all the files before starting to fix that (also, do the C++ header files suffer from the same issue, or not? Have you checked? Because so far I basically copied the same structure of #includes)

About the changes you made for the windows version: why did you have to put the line:

Code: Select all

#libpath "lib/win64" 
in the code? Isn't it the default place where compiler is supposed to look for the libraries anyway?

Also, why have you stated that Win32 is not supported? Have you tried it? (I haven't, but since DOS is 32 bit, and it works under dos, I don't see why it shouldn't work under Win32 as well. The only issue I can see is to find the right C++ runtime)
D.J.Peters
Posts: 8586
Joined: May 28, 2005 3:28
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by D.J.Peters »

Win32 win.show() crashed with memory access at address 0x00000000 !
Both win -gen gas and -gen gcc no stacktrace with GDB the binary release are not compiled with "-g" :-(

I have hand counted struct/class member offsets in the fltk-c fltk-c++ wrapper !
and type "dent" differs on Linux and Windows Tree_Item_ and many more I can't remember after all the years.

Joshy
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by angros47 »

This is very weird, since it works on Linux 32 and 64 with no changes (as far as I recall). I would understand if it didn't work on Windows 32 nor on Windows 64, but it's very strange that it works on Windows 64 if the windows version is different.

Also, show is not a virtual method, it's a regular method, so FreeBasic should just translate it into the equivalent mangled C++ symbol and call it (so, it should be a hit or miss: either it produces an error during compilation, or works with no issues)

What happens with something like:

Code: Select all

dim win as Fl_Window ptr= new Fl_Window(940,380,"Window")
win->show()
A code like this, in theory, should do this:
FB allocates room for a new Fl_Window object, and then calls the constructor, that is a C++ function, and fills the allocated space with the appropriate data. If there is an error in the FreeBasic header, the various member names of the type would not match with the correct data. If the allocated space is too small (because the header has too few members), the constructor might write in unallocated space, causing a crash. If the allocated space is excessive no error will be produced.

The second line would call a C++ function, that will access the data created by the C++ constructor, and never touched by FreeBasic. So, it sounds very strange, to me, that you get such an error


I wonder: do you link the libraries statically or dynamically? If it's linked dynamically, does it compile if you remove "#inclib "stdc++" " from the file Fl.bi? Because I suspect it might be an issue with a wrong version of the C++ runtime
D.J.Peters
Posts: 8586
Joined: May 28, 2005 3:28
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by D.J.Peters »

if you have a windows box here are the Windows 32/64-bit fltk 3.5 runtimes.
download FLTK-headers-and-runtime-windows.zip

compile in the bin folders:
bin32/win32test01.bas
bin64/win64test01.bas

Joshy
Last edited by D.J.Peters on Oct 11, 2022 21:16, edited 1 time in total.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by angros47 »

This is what I got:

Code: Select all

Unhandled exception: page fault on read access to 0x00000010 in 32-bit code (0x00000010).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:006b GS:0063
 EIP:00000010 ESP:0061fd9c EBP:0061fe98 EFLAGS:00010202(  R- --  I   - - - )
 EAX:0061fe10 EBX:01c504fc ECX:0061fe60 EDX:00000031
 ESI:00000006 EDI:004fea54
Stack dump:
0x0061fd9c:  004015d1 0061fdf0 0000000d 0061fdf8
0x0061fdac:  6a2abf1b 6a30bfe0 0061fdd0 0061fdf8
0x0061fdbc:  6a2ac05f 6a30be90 00000000 0061fdf0
0x0061fdcc:  6a2ac05f 6a30be90 00414f50 0061fe08
0x0061fddc:  6a2a8761 00414f50 00414f50 0061fe10
0x0061fdec:  0061fe10 0061fe10 00402410 0061fe48
Backtrace:
=>0 0x00000010 (0x0061fe98)
0x00000010: -- no code accessible --
Modules:
Module	Address			Debug info	Name (31 modules)
PE	  400000-  40e000	Export          hello
PE	  620000-  bb9000	Deferred        gdi32
PE	  bc0000- 1249000	Deferred        user32
PE	 1250000- 149c000	Deferred        comdlg32
PE	 14a0000- 1906000	Deferred        ole32
PE	61740000-61832000	Deferred        advapi32
PE	62fc0000-631d3000	Deferred        rpcrt4
PE	63480000-6349b000	Deferred        version
PE	63bc0000-63c04000	Deferred        shcore
PE	64040000-64063000	Deferred        spoolss
PE	64a40000-64b29000	Deferred        shlwapi
PE	64b40000-64b58000	Deferred        libwinpthread-1
PE	67f40000-680b8000	Deferred        wineps
PE	68500000-68640000	Deferred        combase
PE	68700000-68788000	Deferred        uxtheme
PE	68d00000-68d7c000	Deferred        localspl
PE	6a280000-6a4cd000	Deferred        msvcrt
PE	6bc00000-6bc99000	Deferred        sechost
PE	6bcc0000-6be60000	Deferred        setupapi
PE	6cc40000-6d0e5000	Deferred        comctl32
PE	6eb40000-6eb6a000	Deferred        libgcc_s_dw2-1
PE	6f040000-6f17d000	Deferred        libfltk
PE	6fe40000-70064000	Deferred        libstdc++-6
PE	70b40000-70df9000	Deferred        ucrtbase
PE	71200000-71251000	Deferred        imm32
PE	7b000000-7b348000	Deferred        kernelbase
PE	7b600000-7b929000	Deferred        kernel32
PE	7bc00000-7bea9000	Deferred        ntdll
PE	7ec00000-7ec04000	Deferred        winex11
PE	7ef60000-7ef6b000	Deferred        winspool
PE	7efb0000-7f882000	Deferred        shell32
Threads:
process  tid      prio (all id:s are in hex)
00000020 wineconsole.exe
	00000024    0
00000038 services.exe
	0000003c    0
	00000040    0
	0000004c    0
	00000074    0
	0000008c    0
	00000098    0
	000000b4    0
	000000f8    0
00000044 winedevice.exe
	00000048    0
	00000054    0
	00000058    0
	0000005c    0
00000064 plugplay.exe
	00000068    0
	00000078    0
	0000007c    0
	00000080    0
	000000a0    0
0000006c explorer.exe
	00000070    0
	000000e0    0
	000000e4    0
	000000e8    0
00000084 winedevice.exe
	00000088    0
	00000090    0
	00000094    0
	0000009c    0
	000000a8    0
000000ac svchost.exe
	000000b0    0
	000000b8    0
	000000bc    0
000000c0 conhost.exe
	000000c4    0
000000c8 conhost.exe
	000000cc    0
000000d0 cmd.exe
	000000d4    0
000000f0 rpcss.exe
	000000f4    0
	00000100    0
	00000104    0
	00000108    0
	0000010c    0
	00000110    0
00000188 (D) C:\cc\fbwin4\fltk\hello.exe
	0000018c    0 <==
	00000198    0
System information:
    Wine build: wine-6.0.3 (Ubuntu 6.0.3~repack-1)
    Platform: i386
    Version: Windows XP
    Host system: Linux
    Host version: 5.15.0-48-generic
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by angros47 »

D.J.Peters wrote: Oct 10, 2022 23:09 if you have a windows box here are the Windows 32/64-bit fltk 3.5 runtimes.
download FLTK-headers-and-runtime-windows.zip
Made some test in Wine 32 bit, and I realized that, for example, the command fl_ask works correctly.
So, it seems the DLL is fine: my suspect, at this point, is that the DLL has been compiled using the Microsoft ABI variant, that uses the fastcall convention for C++, instead of the cdecl calling convenction. In case, the name mangling is the same, and it's compatible, so the code compiles, but when the C++ method is called, everything crashes.

If that is the true explanation, there is not much I can do in my code: as far as I can read on the forum, FreeBasic doesn't support fastcall calling convention, so the only option is to recompile the FLTK library with some option to disable the fastcall calling convention,
D.J.Peters
Posts: 8586
Joined: May 28, 2005 3:28
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by D.J.Peters »

angros47 wrote: Oct 12, 2022 16:36so the only option is to recompile the FLTK library with some option to disable the fastcall calling convention
good find but this isn't my job I spent too much lifetime in the well working fltk-c wrapper :-)

Joshy
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by coderJeff »

angros47 wrote: Oct 12, 2022 16:36 If that is the true explanation, there is not much I can do in my code: as far as I can read on the forum, FreeBasic doesn't support fastcall calling convention, so the only option is to recompile the FLTK library with some option to disable the fastcall calling convention,
You seem to be attracted to features that fb doesn't have. :)

I added a couple bits for __fastcall back when I was working on __thiscall. fastcall is not too hard to add though it will have same limitations as thiscall:
- fully usable with -gen gcc (like 99% sure on that)
- completely ignored (I think) on all targets but 32-bit win.
- never tested with -gen llvm.
- partial support win32, 32-bit, -gen gas

So, on win32, 32-bit, -gen gas
- declarations/calls in fb should work (i.e. can link and use gcc compiled libraries having thiscall/fastcall)
- defining subs/functions in fb having thiscall/fastcall will compile and should have correct name mangling, but will likely crash (i.e. thiscall and fastcall is not handled by 32 bit gas emitter and is hard to do)
D.J.Peters
Posts: 8586
Joined: May 28, 2005 3:28
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by D.J.Peters »

angros47 wrote: Oct 12, 2022 16:36... my suspect, at this point, is that the DLL has been compiled using the Microsoft ABI variant, that uses the fastcall convention for C++, instead of the cdecl calling convenction ...
Why do you think so ?
this schould be MinGW GNU ABI
32-bit: https://packages.msys2.org/package/ming ... po=mingw32
64-bit: https://packages.msys2.org/package/ming ... po=mingw64

By the way to decompress "tar.zst" files on Windows I use PeaZip !
https://peazip.github.io/index.html

Joshy
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by angros47 »

D.J.Peters wrote: Oct 15, 2022 16:23 Why do you think so ?
this schould be MinGW GNU ABI
I think so because the FreeBasic code just allocates some memory (I also tried to add a dummy member in Fl_Window, a "foo(1000) as byte", to make sure that more memory than needed was allocated: nothing changed), then calls the constructor from the library to fill it with correct data, and then calls the library main cycle. So most of the work is performed by the library code, there aren't many failure points in the FreeBasic code. FreeBasic code works on Linux (32 and 64 bits), works in DOS, and works in Windows 64: so, we must assume that in windows 32 there is something different, and as far as I know the only different thing is the usage of the fastcall convention.

I also considered that it could have been something related to an incompatibility in vtables (I had that issue some years ago), but the only virtual method is "show", and the issue happens even if that line is commented.

I considered a mistake in variable types (for example, integer and long are equivalent in 32 bit mode, but not in 64, and it could mask some mistakes), but the example works in DOS, that is 32 bit, so I have to exclude it as a cause of the issue.

I am not sure it is related with the fastcall convention, but so far I can't think of anything else.

It's at least 12 years, anyway, that I struggle with integrating FreeBasic and C++ on windows 32 bit: viewtopic.php?t=15233 . On Linux, I manage to do it easily, on Windows, it's a pain (no, it is not the same library, I am not so insane to keep trying the same thing for so long: at the time, it was an attempt to make a static version of what became OpenB3D)
coderJeff wrote: Oct 15, 2022 16:22 You seem to be attracted to features that fb doesn't have. :)
And I really appreciated the support I got, in that. I haven't seen anything similar for any other software

By the way, I tried to compile with -gen gcc , and I tried to declare the fl_window constructor as __thiscall. Nothing changed, for the win32 version

Do you have any idea of what could be the issue? Because I am out of ideas, right now
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by coderJeff »

angros47 wrote: Oct 15, 2022 20:35 By the way, I tried to compile with -gen gcc , and I tried to declare the fl_window constructor as __thiscall. Nothing changed, for the win32 version

Do you have any idea of what could be the issue? Because I am out of ideas, right now
Not sure what you mean by nothing changed. '__thiscall' in fb 1.09 and up will add '__thiscall' to the declarations in the emitted C source .

Code: Select all

extern "c++"
	type UDT
		i as long
		declare constructor __thiscall()
		declare destructor __thiscall ()
	end type
end extern

dim x as UDT

'' -gen gcc
'' void __thiscall _ZN3UDTC1Ev( struct $3UDT* );
'' void __thiscall _ZN3UDTD1Ev( struct $3UDT* );
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by angros47 »

By "nothing changed" I mean that I tried to compile this:

Code: Select all

extern "c++"
#include once "Fl_Window.bi"
#include once "Fl_Button.bi"
#include once "fl_ask.bi"
end extern


dim w as Fl_Window = Fl_Window(440,380,"Window")
	'dim b as Fl_button  ptr= new Fl_button(10,30,150,30,"This is a button")
w.end_()


'w.show


fl.run_
Under Wine, with the compiler for Win32. It compiled, but the resulting executable crashed. In the file Fl_Window.bi I added __thiscall to the constructor declaration, I compiled again, it compiled and the executable crashed again. I tried to compile with -gen gcc, it crashed anyway.

Whatever is the issue, it seems limited to Win32
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FLTK headers for FreeBasic OOP (no C wrapper)

Post by coderJeff »

angros47 wrote: Oct 15, 2022 23:15 In the file Fl_Window.bi I added __thiscall to the constructor declaration, I compiled again, it compiled and the executable crashed again. I tried to compile with -gen gcc, it crashed anyway.
Every member procedure (subs, functions, operators) needs 'thiscall' calling convention, not just constructors. But not procedures taking variadic arguments.

Code: Select all

#if defined(__FB_WIN32__) and not defined(__FB_64BIT__)
	#define thiscall __thiscall
#else
	#define thiscall
#endif

extern "c++"
	type UDT
		value as long
		declare constructor thiscall ()
		declare destructor  thiscall ()
		declare sub       p thiscall ()
		declare function  f thiscall () as long
		'' etc 
	end type
end extern
Post Reply