Win64: fbGFX "-s gui" exe starts graphics window not on focus

Windows specific questions.
JJFlash
Posts: 5
Joined: Nov 30, 2018 8:06
Location: Rome, Italy

Win64: fbGFX "-s gui" exe starts graphics window not on focus

Postby JJFlash » Apr 17, 2019 15:33

Hello everyone! :)
First of all, I apologize for my English as it is not my first language :)

I think I stumbled upon a problem with Freebasic-compiled EXEs which use the fbGFX library. I believe this is the same problem that MrSwiss reported a couple of years ago in this post.

To try to investigate the problem, I wrote a very simple program:

Code: Select all

Screen 1
Sleep
I saved this code to a file, "testScreen.bas".

Then I compiled this program with the 32-bit "Version 1.06.0 (02-17-2019)" version of the fbc compiler, and also with the 64-bit "Version 1.06.0 (02-17-2019)" version of the fbc compiler (in short, I've used the latest release version).
This is the command line I used for both:

fbc -s gui testScreen.bas

The 32-bit version of testScreen.exe starts with the graphics window as expected, in front of all the other windows.
The 64-bit version of testScreen, however, shows the graphics window just for a tiny split second and then it goes into the background. The window can be seen in the taskbar, flashing. Then, if I click the flashing window, the graphics window shows up on top, and then I can press any key to exit the program.

I experienced this behaviour on three Win7 64-bit machines and two Win10 64-bit machines.

Then I remembered that the 32-bit compiler uses the GAS emitter by default, while the 64-bit compiler uses GCC by default, so I wanted to explore a bit further: maybe GCC is the culprit?

Since there is no GCC compiler in the 32-bit distribution of fbc, I took it from the latest WinFBE package (version 1.9.1) and placed the missing files in their respective folders (so: the 32-bit gcc.exe in the bin\win32 folder of the FreeBASIC installation, and the 32-bit cc1.exe in the bin\libexec\gcc\i686-w64-mingw32\8.1.0 folder of the FreeBASIC installation).

Then, I used this line to compile testScreen.bas for both 32- and 64-bit versions. I also wanted to see the .c intermediate file (I definitely don't know C, but maybe I could spot some difference):

fbc -s gui -R -gen gcc testScreen.bas

Alas, nothing changed from before...

This is the 32-bit .c intermediate file:

Code: Select all

typedef   signed char       int8;
typedef unsigned char      uint8;
typedef   signed short      int16;
typedef unsigned short     uint16;
typedef   signed int        int32;
typedef unsigned int       uint32;
typedef   signed long long  int64;
typedef unsigned long long uint64;
typedef struct { char *data; int32 len; int32 size; } FBSTRING;
typedef int8 boolean;
int32 __stdcall fb_GfxScreen( int32, int32, int32, int32, int32 ) asm("_fb_GfxScreen@20");
void __stdcall fb_Init( int32, uint8**, int32 ) asm("_fb_Init@12");
void __stdcall fb_End( int32 ) asm("_fb_End@4");
void __stdcall fb_Sleep( int32 ) asm("_fb_Sleep@4");

int32 main( int32 __FB_ARGC__$0, char** __FB_ARGV__$0 )
{
   int32 fb$result$0;
   __builtin_memset( &fb$result$0, 0, 4 );
   fb_Init( __FB_ARGC__$0, (uint8**)__FB_ARGV__$0, 0 );
   label$0:;
   fb_GfxScreen( 1, 8, 0, 0, 0 );
   fb_Sleep( -1 );
   label$1:;
   fb_End( 0 );
   return fb$result$0;
}
And this is the 64-bit intermediate .c file:

Code: Select all

typedef   signed char       int8;
typedef unsigned char      uint8;
typedef   signed short      int16;
typedef unsigned short     uint16;
typedef   signed int        int32;
typedef unsigned int       uint32;
typedef   signed long long  int64;
typedef unsigned long long uint64;
typedef struct { char *data; int64 len; int64 size; } FBSTRING;
typedef int8 boolean;
int32 fb_GfxScreen( int32, int32, int32, int32, int32 );
void fb_Init( int32, uint8**, int32 );
void fb_End( int32 );
void fb_Sleep( int32 );

int32 main( int32 __FB_ARGC__$0, char** __FB_ARGV__$0 )
{
   int32 fb$result$0;
   __builtin_memset( &fb$result$0, 0, 4ll );
   fb_Init( __FB_ARGC__$0, (uint8**)__FB_ARGV__$0, 0 );
   label$0:;
   fb_GfxScreen( 1, 8, 0, 0, 0 );
   fb_Sleep( -1 );
   label$1:;
   fb_End( 0 );
   return fb$result$0;
}

Now, as I said, I'm grandly ignorant of C, but I can see a "__stdcall" present in the 32-bit version which is absent in the 64-bit one. And, apart from the FBSTRING struct which uses "int64", in the 64-bit version everything else is declared using "int32".
Could it be that this is messing up somehow with the fbGFX library? (This is really a wild guess.)

I also managed to emulate the "no focus" behaviour in the 32-bit realm but calling the Screen function two times in a row, like this:

Code: Select all

Screen 1
Screen 1
Sleep

When I compiled this with fbc -s gui testScreen2.bas with the 32-bit version of fbc, the window has not the focus and it stays in the background.

Last thing: if instead of using "-s gui" I use "-s console", no matter if I go 32-bit or 64-bit, both the console window and the graphics window are on focus and on top of the other windows.

I don't know if this wall of text is helpful in some way to fix the problem (and if it is confirmed I will gladly create a Sourceforge account and report the problem there).
Is there also any workaround to this, apart from not using 64-bit for graphics programs? :)

Thank you so much for reading all of this, I hope I have posted this in the right sub-forum!
dodicat
Posts: 5812
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Win64: fbGFX "-s gui" exe starts graphics window not on focus

Postby dodicat » Apr 20, 2019 9:45

Looks like a bug.
If you set your driver to GDI, it is a workaround, although My win 10 displays GDI whether I choose GDI or DirectX, but if I set GDI the screen remains in focus with 64 bit -s gui.

Code: Select all

screencontrol 103,"GDI"


Screen 1
dim as string driver
screencontrol 9,driver
print driver

Sleep
fxm
Posts: 9010
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Win64: fbGFX "-s gui" exe starts graphics window not on focus

Postby fxm » Apr 20, 2019 10:50

fbc 64-bit only supports GDI.
MrSwiss
Posts: 3124
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Win64: fbGFX "-s gui" exe starts graphics window not on focus

Postby MrSwiss » Apr 20, 2019 12:23

dodicat wrote:Looks like a bug.
Yes, I agree, the DDraw-Driver (DirectX) hasn't ever worked in WIN64-FBC.
According to my tests (which confirm dodicat's findings), the invoked "fallback" mechanism,
triggers the "odd" behaviour. If "GDI" is forced, everything is "as expected".

fxm wrote:fbc 64-bit only supports GDI.
This is the bug, because "DirectX" is in the source, but not working ...
(According to doc, it should even be the default Driver used!)

Solution: fixing the DDraw-Driver, that it also works on FBC x64 (WIN).
(I'm going to write a bug report on sf.net, later on.)
fxm
Posts: 9010
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Win64: fbGFX "-s gui" exe starts graphics window not on focus

Postby fxm » Apr 20, 2019 15:39

coderJeff wrote:Currently, for our gfxlib2, looks like
fbc-32 on win32 - DirectX - OK
fbc-32 on win64 - DirectX - breaking
fbc-64 on win64 - DirectX - broken, I think. See here
MrSwiss
Posts: 3124
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Win64: fbGFX "-s gui" exe starts graphics window not on focus

Postby MrSwiss » Apr 20, 2019 20:07

Bug report #898, on Source Forge written ...
JJFlash
Posts: 5
Joined: Nov 30, 2018 8:06
Location: Rome, Italy

Re: Win64: fbGFX "-s gui" exe starts graphics window not on focus

Postby JJFlash » Apr 22, 2019 9:30

I really appreciate the time everyone of you took to answer to my post! Thanks Dodicat for the workaround, fxm for all the info, and also MrSwiss for the info and the bug report on sourceforge! :)

Return to “Windows”

Who is online

Users browsing this forum: Imortis and 2 guests