Quake Live Forum

First of all we know someone who managed to get Quake Live running just fine on mac through CrossOverGames so it can be done.

I have a friend who is running CrossOvergames on mac, he managed to get firefox installed, and the QL plugin installed, however when he tries to run the game he gets the famous "Q_strncpyz: NULL src" error.

The standard fix for this in windows is to update the video card drivers. However, he sent me some videos of the crossover application, and I think under:

/Library/Application Support/CrossOver/Bottles/Firefox/drive_c

He has all the necessary directories, including the Nvidia directory with the latest 285.58 driver in it. It also finds OpenGL32.dll per its error log:

...calling LoadLibrary( 'C:\windows\system32\opengl32.dll' ): succeeded

However there is definitely something video driver related that it is missing, or more accurately trying to copy data from when there is none to copy.

He understandably wants to get this problem fixed before he registers the program, but time is running out for the demo or w/e. I figure there is something simple to get this to 'kick over' but I can't figure out what it is.

Any help you could provide would be greatly appreciated. Thank you for your time.

Hi...

...you've misconstrued the video driver path somewhat ;
crossover/wine (and hence the app itself) are not going
to use any Windows video drivers at all, but rather, the
drivers builtin to MacOS (for whatever video card/chipset
your Mac has, and these drivers differ between MacOS versions)...

...the real information to be looking for, here, is what
version MacOS?, with what video card/chipset combination?,
was Quake live known to work in..(and in which version
of crossover?). It can be as simple a case of 'works on a
nvidia equipped Mac, doesn't work on all Ati fitted Macs,
and likely will never work on intel gma chipsets' ; that
is a very common (and real) example of what plays out...

..that said, when I look at the C4 entry here for QLive..;

http://www.codeweavers.com/compatibility/browse/name/?app_id=5827

..it's clearly apparent that nobody here has got it to
run (or never reported it) -- if you know someone that
-did- get it to run in CXG Mac, it'd be a case of bouncing
the same ?'s above off them, and then you'll have a much
better idea of what you're looking at...ie; if they were
using a nvidia chipset & your Mac is using Ati, that one
difference is enough in many cases...

..be also aware, that the current crossover version(s) are
based upon a somewhat aged winecore presently, and a new
crossover release is not far away now - considering the
amount of improvements in the upcoming release's winecore,
it would actually be a bit pre-emptive to judge crossover's
usefulness or not -today-, when I already know there's many
games that haven't worked before, that will start running in
the next crossover release that's on the horizon..

Cheers!

Artist Formally Known as Dot wrote:

...you've misconstrued the video driver path somewhat ;
crossover/wine (and hence the app itself) are not going
to use any Windows video drivers at all, but rather, the
drivers builtin to MacOS (for whatever video card/chipset
your Mac has, and these drivers differ between MacOS versions)...

Gotcha. So the path would look something like this:

MacOS --> Wine --> Emulated bottle --> Windows Application (game)

Then this asks MacOS for its graphics system and uses that to run the game?

...the real information to be looking for, here, is what
version MacOS?, with what video card/chipset combination?,
was Quake live known to work in..(and in which version
of crossover?). It can be as simple a case of 'works on a
nvidia equipped Mac, doesn't work on all Ati fitted Macs,
and likely will never work on intel gma chipsets' ; that
is a very common (and real) example of what plays out...

..that said, when I look at the C4 entry here for QLive..;

http://www.codeweavers.com/compatibility/browse/name/?app_id=5827

..it's clearly apparent that nobody here has got it to
run (or never reported it) -- if you know someone that
-did- get it to run in CXG Mac, it'd be a case of bouncing
the same ?'s above off them, and then you'll have a much
better idea of what you're looking at...ie; if they were
using a nvidia chipset & your Mac is using Ati, that one
difference is enough in many cases...

Yes this exactly I agree 100 % but we can't seem to find the guy. He just told us he got it running, gave some elementary instructions, and then disappeared. We've sent him e-mails but there hasn't been any response :-/

If we manage to get ahold of him I will suggest that he update that Crossover page for Quake Live and provide all of his system information.

In the meantime I am making a genuine effort to figure this out.

In the errorlog I see the following:

...getting DC: succeeded
...GLW_AutoSelectPFD( 32, 24, 0 )
... auto selected PFD 42...PIXELFORMAT 42 selected
...creating GL context: succeeded
...making context current: failed

What causes that should look like this:

if ((wglMakeCurrent(hdc, hglrc)) == false)
{
Issue error
}

hglrc being the Handle for GL Render Context, and hdc being the Handle for the Device Context.

So it's having trouble getting the window to render to, or rendering to it? Something.. running more tests and studying the matter.

Mike Kent wrote:

Artist Formally Known as Dot wrote:

...you've misconstrued the video driver path somewhat
;
crossover/wine (and hence the app itself) are not going
to use any Windows video drivers at all, but rather, the
drivers builtin to MacOS (for whatever video card/chipset
your Mac has, and these drivers differ between MacOS
versions)...

Gotcha. So the path would look something like this:

MacOS --> Wine --> Emulated bottle --> Windows Application (game)

Then this asks MacOS for its graphics system and uses that to run
the game?

...pretty much, with the graphics rendering routines being
realized as opengl transforms a lot of the time (due to the
fact linux/OSX video drivers don't provide any windows native
directx interface to the app). Where that obviously falls down.
a lot of the time revolves around how well the host native
opengl libraries work, and exactly what function calls any
particular gpu/driver supports...(and whether or not that
support comes bug free)..

...a simple example would be considering OSX 10.6.x which
iirc only supported the opengl 2.x API -- with OSX 10.7.x
the opengl 3.x API is available, but I'm not entirely sure
how complete/bug free that implementation is currently wrt
to all the different gpu/drivers part of Macdom these days...

snip<

Mike Kent wrote:

Yes this exactly I agree 100 % but we can't seem to find the guy. He
just told us he got it running, gave some elementary instructions,
and then disappeared. We've sent him e-mails but there hasn't been
any response :-/

If we manage to get ahold of him I will suggest that he update that
Crossover page for Quake Live and provide all of his system
information.

In the meantime I am making a genuine effort to figure this out.

In the errorlog I see the following:

...getting DC: succeeded
...GLW_AutoSelectPFD( 32, 24, 0 )
... auto selected PFD 42...PIXELFORMAT 42 selected
...creating GL context: succeeded
...making context current: failed

What causes that should look like this:

if ((wglMakeCurrent(hdc, hglrc)) == false)
{
Issue error
}

hglrc being the Handle for GL Render Context, and hdc being the
Handle for the Device Context.

So it's having trouble getting the window to render to, or rendering
to it? Something.. running more tests and studying the matter.

...I'm unsure of the current state of play with this (or
even if it's related here), but OSX did have (and may still
have) issues with gl_child_window_create or some-such, but
you'll do a lot better here debugging it at the wine layer
rather than the app level ... to do that, have a read of this;

http://www.codeweavers.com/support/wiki/mac/mactutorial/submittechsupportlog

...then familiarize yourself with the available debug channels
that you can choose to listen to...;

http://wiki.winehq.org/DebugChannels?highlight=%28debug%29

...and obviously something like +trace,+opengl,+wgl is going
to give you some useful look inside why the app is failing
on that particular call..

..hope this helps...

Cheers!

ps: I'll have this thread moved to the Quake Live C4 page forum
sometime later...

Update:

...one of our Ninjas mentioned a couple of things
to me about this title ...

*there was a winebug that stopped this title from
running (in linux at least) prior to wine-1.3.11 ;
as the current crossover release is based on the
wine-1.3.9 build tree, it's highly likely that bug
is still present in CXG 10.x ..(whether the bug goes
onto affect macos as well is polemical)...

*one of the devs did look at this title, and concluded
a lot of it's issue (when up and running which leads
into a disconnection or some other connection weirdness)
is because of the use of 'punkbuster' with this title.

...you can have a read of the WineHQ page for the view;

http://appdb.winehq.org/objectManager.php?sClass=version&iId=15796

...there's one other wrinkle with all of this ; this app
doesn't see a lot of dev time/interest just because there
is a linux client plugin. All things considered, and especially
in light of the past bug, I very much would not expect this
to work in CXG 10.x and would 'back-burner' this for another
round of testing come crossover 11 (or else test it in one of
the newer wine-devel trees)...

Cheers!

Still processing all the info you gave, thanks for your help 😊

Artist Formally Known as Dot wrote:

*one of the devs did look at this title, and concluded
a lot of it's issue (when up and running which leads
into a disconnection or some other connection weirdness)
is because of the use of 'punkbuster' with this title.

To clarify on this though, the game no longer uses punkbuster as of maybe a year ago.

..ahh, ok...as I said, this title lost a lot of momentum
when the linux client appeared, and 'a year ago' can be
construed as 'not long ago'...(which is what I was told =)...

...I kicked the iMac back into 10.7.2 and had a bit of a
poke at it out of curiosity ; I saw it was throwing this
with just the +trace,+loaddll channels enabled..

.
..
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winecoreaudio.drv" at 0x47e60000: builtin 
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\opengl32.dll" at 0x46f90000: builtin  
err:x11drv:error_handler XERROR: code 2 request 128 minor 2 xid 00a02859 
trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\opengl32.dll" : builtin
..
.

....when I look at that bit of loadout with +trace,+x11drv ...

trace:x11drv:X11DRV_ExtEscape SET_DRAWABLE hdc 0x41c drawable 1000002 gl_drawable 0 pf 0 dc_rect (53,213)-(853,813) drawable_rect (56,44)-(1289,1023) 
warn:x11drv:set_win_format XComposite is not available, using GLXPixmap hack 
trace:x11drv:set_win_format Created GL drawable 0xa0339b, using FBConfigID 0x4c
trace:x11drv:X11DRV_ExtEscape SET_DRAWABLE hdc 0x3d8 drawable 77 gl_drawable 0 pf 0 dc_rect (0,0)-(1920,1058) drawable_rect (0,0)-(1920,1058)
trace:x11drv:X11DRV_WindowPosChanged win 0x1009a window (0,0)-(800,600) client (0,0)-(800,600) style 50000000 flags 0000bc1f
trace:x11drv:X11DRV_ExtEscape SET_DRAWABLE hdc 0x41c drawable 1000002 gl_drawable a0339b pf 42 dc_rect (53,213)-(853,813) drawable_rect (56,44)-(1289,1023)
err:x11drv:error_handler XERROR: code 2 request 128 minor 2 xid 00a03399
trace:x11drv:X11DRV_WindowPosChanged win 0x1009a window (0,0)-(800,600) client (0,0)-(800,600) style 40000000 flags 00001897
trace:x11drv:X11DRV_ExtEscape SET_DRAWABLE hdc 0x8444 drawable 1000002 gl_drawable 0 pf 0 dc_rect (53,213)-(54,214) drawable_rect (56,44)-(1289,1023)

...I'd wager that's where things are going awry...

Ok awesome.

Can you tell me what exactly you debugged? Like just roughly how you got this output.

He is able to run opengl applications such as quake 3 through crossover games on mac.

Also any idea what "XERROR: code 2 request 128 minor 2" itself refers to?

...I attached the debug to 'firefox.exe' to get those traces...

..no, I don't know what the xserver error code is (nor does
such an error code alone necessarily tell the whole story)..ie;
the xserver can throw such an error wrt the app or the host os
display manager ; one would probably need to debug a little
deeper with gdb or such to get to the exact reason/cause...

Cheers!

Update 2;

...definitely an OSX thing though.. the same 11,2 iMac running
debian6, and the game starts without this error raising it's
ugly head -- that said, there is no mouse input (I saw this in
the debug from earlier), which of course makes the game unplayable
(unless you like running around bouncing off walls as somebody
else's live moving target practice)...

Artist Formally Known as Dot wrote:

..ahh, ok...as I said, this title lost a lot of momentum
when the linux client appeared, and 'a year ago' can be
construed as 'not long ago'...(which is what I was told =)...

I'm curious, do a lot of mac users emulate linux apps? Or dual boot it?

I mean me personally if I had to not use windows I would use linux for sure and never bother with mac. I've tried to convince the guy to boot some other OS for games but he isn't interested 😊

...I kicked the iMac back into 10.7.2 and had a bit of a
poke at it out of curiosity ; I saw it was throwing this
with just the +trace,+loaddll channels enabled..

So I am assuming you got the same Q_strncpyz NULL src error?

.
..
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winecoreaudio.drv" at 0x47e60000: builtin 
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\opengl32.dll" at 0x46f90000: builtin  
err:x11drv:error_handler XERROR: code 2 request 128 minor 2 xid 00a02859 
trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\opengl32.dll" : builtin
..
.

Here's where I am a bit confused.

Is it using this opengl32.dll that's found in the "C" directory or somewhere else or what?

Like you said it has to interface with the graphics system on OSX. Are all opengl32.dll's created equal?

Could it make a difference if we emulate XP versus Vista/Win7? I can't access that menu bar so I don't know what all options it has. This would be easier if I actually had the machine in question as I could run a gazillion tests quick fast in a jiffy. As it is I have to kind of tell him what to try and bless his heart he is not that computer savvy so it is a lot more time consuming.

...I attached the debug to 'firefox.exe' to get those traces...

Ok very interesting. The game as far as I know uses "plugin-container.exe", I wonder if attaching the debug to that would produce the same or different info or anything useful. Firefox starts this program so perhaps the debugger is smart enough to see programs started by the program it is set to debug?

The error it gives is definitely consistent with the whole hdc, hglrc business. I feel like I am missing something very simple but I just can't seem figure out what it is.

Can you elaborate a bit on the gdb thing? (not expecting much as I imagine this is a deep subject)

Hmm, even if I got that working though I think it would still present a problem as to what to do about it.