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

Windows specific questions.
JJFlash
Posts: 6
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: 6754
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: 10035
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: 3655
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: 10035
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: 3655
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: 6
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! :)
TeeEmCee
Posts: 314
Joined: Jul 22, 2006 0:54
Location: Auckland

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

Postby TeeEmCee » Jan 04, 2021 4:56

This thread was actually about two different bugs:
-the fbgfx DirectX backend not working on 64-bit Windows, which is now fixed;
-if the fbgfx DirectX backend fails to initialise then the window appears for an instant, then opens behind all open windows when it falls back to the GDI driver.

Testing in 32-bit Win XP in a VirtualBox VM (with 3D acceleration enabled), with both latest FB from git and FB 1.04, the fbgfx DirectX, Direct2D and OpenGL drivers don't work. Despite other Direct3D 9 programs working, and dxdiag reporting DirectDraw and Direct3D 8 and 9, but not 7, work.
Nevermind, let's assume it's VirtualBox's fault; I do get a lot of glitches. I also assume that the drivers are meant to support WinXP. It's unfortunate that fbgfx does no error reporting.

So exactly as described earlier in this thread I'm seeing the problem with the window appearing behind all others. And adding "screencontrol 103, "GDI"" works around the problem.
I wonder whether there are other people who see the same problem because the DirectX driver doesn't work for whatever reason.

Interestingly compiling with "fbc -s console" also avoids the problem.
MrSwiss
Posts: 3655
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Postby MrSwiss » Jan 04, 2021 15:11

It is from my point of view illogical, to still use FBC 1.04 for anything any longer.
Win XP is 2 decades old -- out of service -- for any serious work.

Latest release of 1.07.3 (WIN64 only) fixes all the problems described.

Emulators, VM's and the like are more often than not, introducing problems unseen w/o them ...
TeeEmCee
Posts: 314
Joined: Jul 22, 2006 0:54
Location: Auckland

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

Postby TeeEmCee » Jan 05, 2021 13:32

The latest FB version (compiled from git) does NOT fix the problem I mentioned, that was my point.
I don't use FB 1.04, I only tested with it to confirm it isn't a recent problem.

FB and fbgfx supports Windows 95 still, although I could accept that only the GDI driver supports Win XP (it would surprise me though). But yes, VirtualBox is certainly at fault for the DirectX driver not working.
adeyblue
Posts: 37
Joined: Nov 07, 2019 20:08

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

Postby adeyblue » Jan 05, 2021 19:50

TeeEmCee wrote:FB and fbgfx supports Windows 95 still, although I could accept that only the GDI driver supports Win XP (it would surprise me though). But yes, VirtualBox is certainly at fault for the DirectX driver not working.


The DirectX driver doesn't work with VirtualBox. At least, it obviously doesn't work with yours and it definitely does work with mine where I do the developing. It fails because wherever DirectDraw gets the amount of VRAM from, it returns an insufficient number for it to initialise and so fails. Freebasic can't fix VirtualBox's or Windows' code.

Direct2D started with Vista (but the driver requires 7) so that was never going to work on XP, and afaik the OpenGL one requires installing the proper graphics card drivers or a replacement opengl runtime since the basic Windows OpenGL support only supports a really old version and it doesn't have the functions/extensions the driver uses.


The window being behind all the others is due to how Windows works. Essentially, you can only put one of your windows into the foreground if you already have one there, or if your app has just been started by one.

In the DirectX fail case, your app has just been started by the foreground app so the window created by the DirectX driver would be put there. DirectX then fails, and the window is destroyed. The GDI driver window then comes along, but your app doesn't have a foreground window (since it doesn't have any) and it's already used its free 'started by' one on the destroyed DirectX window, so when FB asks Windows for the GDI window to be put up front, Windows doesn't allow it.

This is also why the console version works, because your app has the console window in the foreground, so it can give the foreground to any other window it created no matter when or in what order they were created.

One window created per driver is the main villain here, but that's an entrenched design of gfxlib2. The potential for this bug was introduced then, and it will remain there until gfxlib / the drivers are changed to not do that.

So on XP in VirtualBox, GDI is pretty much your only option.
TeeEmCee
Posts: 314
Joined: Jul 22, 2006 0:54
Location: Auckland

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

Postby TeeEmCee » Jan 05, 2021 22:16

Thanks for the explanation. It's always fascinating to me how one piece of software trying to do the right thing adds extra complexity that stuffs things up for other software.

I don't really care whether this problem is fixed, I just wanted to mention and document it since I was puzzled and surprised by it.
So it turns out that I'm quite lucky that the simple Direct3D 9 program I use that VM to test actually runs there at all (it's simpler than fbgfx's driver).

Return to “Windows”

Who is online

Users browsing this forum: No registered users and 6 guests