Now there are no problems. The program terminates without errors.angros47 wrote: ↑Oct 07, 2022 13:50 Ok, found the issue: in the file "Fl_Clock.bi", the line
should have been just:Code: Select all
declare virtual destructor
Because the destructor was not virtual. I updated the file on github with the fix.Code: Select all
declare destructor
FLTK headers for FreeBasic OOP (no C wrapper)
Re: FLTK headers for FreeBasic OOP (no C wrapper)
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK headers for FreeBasic OOP (no C wrapper)
@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:or this in other order:By the way this extra "extern / end extern" isn't needed: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
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_
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_
Code: Select all
extern "c++"
#inlude "blabla.bi"
end extern
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"
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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: 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)
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"
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)
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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
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
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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:
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
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()
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
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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
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.
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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
Re: FLTK headers for FreeBasic OOP (no C wrapper)
Made some test in Wine 32 bit, and I realized that, for example, the command fl_ask works correctly.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
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,
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK headers for FreeBasic OOP (no C wrapper)
You seem to be attracted to features that fb doesn't have.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,
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)
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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)
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
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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* );
Re: FLTK headers for FreeBasic OOP (no C wrapper)
By "nothing changed" I mean that I tried to compile this:
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
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_
Whatever is the issue, it seems limited to Win32
Re: FLTK headers for FreeBasic OOP (no C wrapper)
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