Big Fish Games Manager Forum

@Carlos -- As you may (or may not?) be aware, just about every BFG title
is going to call dxwebsetup.exe /Q and give you an abbreviated directx
runtime install (24mb or so....if you install directx-runtime modern before
running dxwebsetup, it determines the download to be ~10mb or so)...

...at any rate, I'm not sure which component is spooking this, but my best
estimate is the 2nd package of the 'managed directx redists 1.blabla' which
immediately throws an error because it's wanting to write manifests to hook
in with .NET 2.0 (there's a quaffle on this over on MSDN...'MDX' or such)...

...one wonders where to put this .NET 2.0 predependency - do you put it in
this c4p knowing that any future game installation is going to require it,
do you put it in each game's C4 c4p because you know the game installation
is going to need it...or does one accurately represent the situation...ie;
that it's actually the dxwebsetup.exe that has the .NET 2.0 dependency, and
we should have a C4 target for dxwebsetup (which I'll do in a moment anyhow
as it may be useful to have around for other things..)...blabla, blah..

....ergo, I ?was? just going to add .NET 2.0 as a predep here, but thought
better to raise discussion on it first. I believe having the dxwebsetup stuff
done early on in the bottle creation process, actually speeds up the installation
of the actual game(s) content from the word go...like I say however, if the
'abbreviated' directx runtime target is valid for other C4 games/apps (and it
likely will be me thinks), then it's useful to have around to be used in the
same way as we currently use directx9modern/legacy...we'll have a third choice
that also ropes in .NET 2.0 ....

...let me know what you think 8)

Cheers!

Hello Don,

I am going to make some tests about it. I wasn't aware about the dxwebsetup. And I agree with you about having every dependency installed by cx itself, so the user have to download it once. This Monday I am going to begin the tests and give you a better response.

Which games have you tested?

Regards,
Carlos

Hi Carlos,

I've tested their 'top 10 PC downloads' selection plus a smattering of others.

I've already done most of the testing so related (I submitted the ticket to make
mshtml7 our friend 8)...wrt a -game- installation, mshtml7 is required for both
the games manager UI -and- the dxwebsetup.exe stuff -- dxwebsetup has in fact two
predeps mshtml7 & .NET 2.0 -- so that muddles the cake further, in as much as if
you specify dxwebsetup as a predependency, you can drop mshtml7 here and use the
dxwebsetup c4p instead....

...ultimately, providing those predeps to dxwebsetup, results in the installation
completing correctly, and the required native dll's are copied into place, their
associated manifests created (or one supposes seeing as it all works in the end 8),
but we don't get any dll overrides as per what is provided by directx9modern.c4p
...dxwebsetup requires the same sort of registry key manipulation...I'll finish
that off in a bit...

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

....I'm still musing what to do about the dll overrides there -- probably the correct
way, should be to provide an override for each d3d9x dll it deduces we need native
versions of, but in real terms (during my testing) leaving the overrides -out- lets
you specify exactly which dll you actually need an override for...hmmm.....that's
probably more useful in a development sense....ie; just having overrides for those
needed lets you keep an eye on which d3d9.dll.so still need work...but at the base line
with one example, you really only need overrides for d3d9x27|36 to get that specific game
running....}shrug{...

...........I might leave the overrides out for now - I'll post in the above C4's forum
about this stuff -- I don't think it's necessarily 'good' to provide the 'correct' layout
as we might end up thinking we actually need overrides for certain dll's when in fact we're
not.....feel free to advocate the above yourself to access the c4p (I'll finish it off in
a minute or 10 )....

Cheers!

Update: ..okay, 7558.c4p probably behaves the way I want it to. It doesn't directly
provide any full directx9 supports perse, clinically that's correct though - the
bigfishgames manager itself doesn't need any directx stuff anyhow afaict -- only the games do...

...so you add the directx9modern target predep to the -game- c4p .... in this way,
the directx9modern runtime is installed before before the game installer is run,
when the game installer is run it [detects there's no need to install bfgm] and just
starts downloading the game content....at the end of the content download, the game
is installed as per usual and it calls to dxwebsetup, which correctly detects that
it's already been installed and thus skips installing itself [and the directx9modern
overrides remain intact/good]....app_id=7709 will be one of the first I try to complete...

In basic terms it provides a working placebo without treading on anything else. The
next issue is bfgclient.exe's insistence to hang around (and why it's doing that) and
getting that to behave, not to mention it seems 9.1 has broken emulated virtual desktop
mode somewhat (and the mac here didn't like the idea at all but would run fullscreen),
....my current workaround involved cutting a link to --workdir=$gameinstall game.exe and
bypassing bfgclient altogether (seems to work here after one time/initial game activation)
...but that's probably not fair on them (bfg) 'coz it doesn't display the game manager at
all when hoisted like that...I'll need look into the behavior more (might be because we're
not running .NET 2.0-SP2).....

Cheers!

Artist Formally Known as Dot wrote:

Update: ..okay, 7558.c4p probably behaves the way I want it to. It
doesn't directly
provide any directx9 supports perse, clinically that's correct
though - the bigfishgames
manager itself doesn't need any directx stuff anyhow -- only the
games do...

...so you add the directx9modern target predep to the -game- c4p
.... in this way,
the directx9modern runtime is installed before before the game
installer is run,
when the game installer is run it [detects there's no need to
install bfgm] and just
starts downloading the game content....at the end of the content
download, the game
is installed as per usual and it calls to dxwebsetup, which
correctly detects that
it's already been installed and thus skips installing itself [and
the directx9modern
overrides remain intact/good]....app_id=7709 will be one of the
first I try to complete...

In basic terms it provides a working placebo without treading on
anything else. The
next issue is bfgclient.exe's insistence to hang around (and why
it's doing that) and
getting that to behave, not to mention it seems 9.1 has broken
emulated virtual desktop
mode somewhat (and the mac here didn't like the idea at all but
would run fullscreen),
....my current workaround involved cutting a link to
--workdir=$gameinstall game.exe and
bypassing bfgclient altogether (seems to work here after one
time/initial game activation)
...but that's probably not fair on them (bfg) 'coz it doesn't
display the game manager at
all when hoisted like that...I'll need look into the behavior more
(might be because we're
not running .NET 2.0-SP2).....

Cheers!

I didn't say that right....emulated desktop mode has broken thing, and with some games
the Mac wasn't very impressed -- in linux (depending on game title), setting ORM=backbuffer
fixes some titles, but the Mac abhors that idea...however you don't need touch ORM in Mac
provided emulated virtual desktop is off...ie; the games will start fullscreen just fine.
(they start in linux fullscreen as well, but we don't have the screen resolution handling
shizzle the Mac has, so on linux fullscreen is all stretched to 16:9/10 which doesn't look
very good at all...

...on the plus side, I just rolled 7558.c4p into the c4p here -- tested it all weekend and just
now, and it seems to work 'as expected'....Carlos, give it a go and see what you think,,,,

The benefits of using 7558.c4p as a predep are....

1. BFG games installations won't throw an error related to dxwebsetup - they will instead report the latest version is installed.

2. BFG games installations won't download ~24mb every time as a result of correctly detecting 1.

3. Any BFG games requiring .NET 2.0 are covered....

4. Any BFG games requiring more directx support than provided by dxwebsetup, can simply have directx9modern as their own predep.

5. Something else I haven't noticed yet 8)

Cheers!

Very good work my friend, I will try tonight with the new C4P file

There are a few niggling issues to resolve yet, as to make this all {ahem}...'perfect'...

1. You're using WINE_WAIT_CHILD_PIPE_IGNORE as part of the c4p here...that's fine, I do
   know why :: the problem with that, is if I have a BFG title and specify 6268.c4p as a
   predep, that actually breaks the app_install of said c4p. I chatted with Aric about it,
   and like me, the only immediate solution is to move the WINE_WAIT_CHILD_PIPE_IGNORE env
   var out of 6268.c4p and put it into the (an) app's c4p which is in no way ideal or perfect...

2. The above in 1. may only apply in the case where one doesn't want all their bigfish games
   in the 'Big Fish Games Manager' bottle...(if this bottle already exists and we can detect and
   install into it, we obviously don't need the 6268.c4p predep),,,but not everyone does (or wants
   to) install all games into the same bottle -- they would prefer one bottle per game, each bottle
   having the name of the BFG title installed...

...this is kind of like Steam but different -- in Steam you can have multiple titles (I have over
70 in my Steam bottle), but you also have the ability to backup (via Steam) each individual game
therein installed. With BFGM, you can't do that...if you have say 70 bfg games all installed into
the one BFGM bottle, you have to backup (cxarchive) the entire bottle -- you can't cxarchive on a
per game basis...

3. Part of the BFGM is the process 'bfggameservices' -- when you quit a BFG title, this process
   doesn't die --- instead, the wine system tray pops up, as associated with this still running task.
   Quitting the wine system tray does -not- kill bfggameservices --- it just keeps on running as an
   attached wine process....the only way to regain baseline, is to issue a killall -9 bfggameservices
   in the CLI (or start cxsetup and click on 'quit bottle' or 'force quit bottle' to the same ends).

Feel free to advocate yourself to http://www.codeweavers.com/compatibility/browse/name/?app_id=7709
and have a look at how this all pans out in practice...note: this app has been broken in 9.1 & linux
currently (still runs in Mac fullscreen however), but it does demonstrate some of the few remaining
issues at hand here....

Obviously, your thoughts and comments most welcome here!

Cheers!

I've added mshtml7 back as a dependency. This was because I hadn't realized dxwebsetup brought it in.

In any case, this is not a functional change (the AI engine will make sure mshtml7 is installed before dxwebsetup), and it documents that bfg has a need for it independent of the dxwebsetup.

Good!

@Don

Have you has problems with this error?

"err:seh:setup_exception_record nested exception on signal stack in thread 0038 eip 7bc73840 esp 7ffdbc7c stack 0x242000-0x340000"

It happens in many BFG games, and I don't know how to deal with it

Regards,
Carlos

P.D Game: MahJong Jade Expedition

Hi Carlos...

Oh boy do I know that error...I had it with another app (Eufloria)...

In my case the problem was a linux kernel bug (not really a bug perse,
just some undefined behavior) -- I grabbed a vanilla linux-2.6.34 tarball,
config/compile/install and that solved it.

Related wineHQ thread is.....;

http://bugs.winehq.org/show_bug.cgi?id=20380

Cheers!

Artist Formally Known as Dot wrote:

There are a few niggling issues to resolve yet, as to make this all
{ahem}...'perfect'...

1. You're using WINE_WAIT_CHILD_PIPE_IGNORE as part of the c4p
   here...that's fine, I do
   know why :: the problem with that, is if I have a BFG title and
   specify 6268.c4p as a
   predep, that actually breaks the app_install of said c4p. I chatted
   with Aric about it,
   and like me, the only immediate solution is to move the
   WINE_WAIT_CHILD_PIPE_IGNORE env
   var out of 6268.c4p and put it into the (an) app's c4p which is in
   no way ideal or perfect...

This is more troublesome than I first thought -- lets say you're either going to install
a bfg title purchase (or demo) via c4p --- you have a couple of options ;

(A) specify 6268.c4p as a predep, but then WINE_WAIT_CHILD_PIPE_IGNORE=bfgclient.exe trounces the c4p installation process....

(B) specify 7558.c4p as a predep, and include WINE_WAIT_CHILD_PIPE_IGNORE=bfgclient.exe in the apps's
c4p recipe...but then the WINE_WAIT_CHILD_PIPE_IGNORE trounces the c4p installation process....

There's an example of (B) here -> http://www.codeweavers.com/compatibility/browse/name/?app_id=5480
Again, feel free to advocate for that title for access to the c4p so you can have a play - currently
it's setup to download the demo of that app which does in fact work on Mac/linux...

So....we don't do it that way, we do it the other other way -- install BFGM first via 6268.c4p,
cxsetup (manage bottles), select BFGM bottle, install other app, select the game installer file
(be that the demo or purchased version) and click install -- the games manager will pop-up and
start downloading/installing the game....however....the installation doesn't complete (hangs
at end of process), because bfggameservices.exe has started (doesn't appear to start until you
install a game?), so you have to either killall -9 bfggameservices or send the bottle a force quit
to get it to complete....{sigh}...

Close, but no cigar...I'll spark up the VM later and see exactly how winxp is presenting things,
but I'm starting to suspect this in .NET 2.0 related somehow (bfggameservices is actually a child
of mscorlib.exe I think)...possibly due to the lack of .NET 2.0 services packs (both SP1 & SP2)...

...oh, I also chatted with Vincent to see if we can get the associations of mshtml7 changed a bit
so BFGM throws to the -system- web browser instead of trying to use mshtml7 engine to display things
when you click on buttons in BFGM itself....but bfggameservices.exe is a more immediate problem
(with games), and having to use WINE_WAIT_CHILD_PIPE_IGNORE to get around the bfgclient.exe hang
is more important as well (seeing as it breaks a <predep> install via c4p of a bfg title)....but who
knows, that may also be related to .NET 2.0 shortcomings...>shrug<...I'll keep digging..

Cheers!

bfggameservices.exe

I'll have to watch my process list a bit closer, but I think I've found
this one...(might explain the wine systray popup and other behavior)...

It would appear to me as though bfggameservices.exe is hoisted on another perl
thread (?), and if I'm seeing it right (will recheck later) that thread results
in a defunct perl process. It possibly relates to this chatter;

warn:seh:setup_exception_record exception outside of stack limits in thread 0018 eip 7ec1a552 esp ffbe2510 stack 0x242000-0x340000
trace:seh:raise_exception code=c0000005 flags=0 addr=0x7ec1a552 ip=7ec1a552 tid=0018
trace:seh:raise_exception info[0]=00000001
trace:seh:raise_exception info[1]=00360000
trace:seh:raise_exception eax=80808081 ebx=7ecba720 ecx=00000000 edx=00000067 esi=0000032c edi=00360000
trace:seh:raise_exception ebp=ffbe2578 esp=ffbe2510 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010212
trace:seh:call_vectored_handlers calling handler at 0x7e58ef80 code=c0000005 flags=0
trace:seh:call_vectored_handlers handler at 0x7e58ef80 returned ffffffff

I see 6 of those warn events early on in the piece -- trying to close the main wine window hits tid:0018
every time - window never closes -- I suspect bfggameservices.exe has totally detached itself from it's
parent thread, which is now a defunct process, and thus can't answer anyhow....so when you quit the app,
the sigterm never gets delivered to bfggameservices.exe because of a dead parrot sketch...

If there's any bright side to this caper, at least the software itself (BFGM) and demos of the games are
free available for everyone to poke voodoo needles into...

I'll hoist a ticket here on this (I want to cross check on the Mac as well first)...maybe I should post a
bug on it over at wineHQ as well..(I note there's one on it already, however we're not seeing that in CX);

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

...onwards ever onwards...

Cheers!

edit: the Mac's doing pretty much the same thing in the same stack range..

edit: also doing the same thing in wine-1.3.0

Hey guys,

I have several BFG and want to try them on our new iMAC. Are you running them through CrossOver Mac or CrossOver games? I have both, have not tried any games yet (only Excel in an effort to get macros to work which are still problematic).

edit - I went with 'Games'

It looks like I install the C4P program, and then try the BFGs. Is there any more to it, and what kind of feedback would be most helpful for you all?

edit - it will hang about 80% through with an Adobe window open under everything else.

I ended up with two partial and one complete installs - deleted two partials via bottle manager

The C4P says it will install a few MS programs such as ie7, .net and parser, does this then expose my new iMac to viruses and the ills of the MS world which I am trying to leave or are they contained in the bottles to isolate them from the system?
Thanks,
Alec

CrossOver creates virtual Windows environments which we call "bottles". By default, when you install software, it creates a new bottle. You can use the Manage Bottles window, accessible from CrossOver's Configure menu, to, well, manage the bottles. To delete an unwanted bottle, select it in the list and click the minus ('-') button below the list.

If you prefer, you can direct the installation of an application to be targeted to an existing bottle.

Thanks, I just figured that out while you were posting;o)

I have the one complete Big Fish Games Bottle.

I open CrossOver Games, select Games Applications, it shows a Game Manager (wine), and BFG icon. If I click the BFG icon, it says 'There is no windows program configured to open this file'

When I click on the Game Manager it opens the BFG Game Manager, but when I try to click on a link to get to my account, it always goes to a wine ie which is blank.

Do I need to download on a non-Mac, write to DVD, and then import the games?

Hello Alex,

Sorry for the delay. Your answers:

• You can run Big Fish Games and Big Fish Game Manager using CrossOver Games 9.1
• Don't worry about windows viruses they do not run on CrossOver :)
• We have tested many BFG games, and only a few do not run.
• Install BigFishGames Manager and then install each game as an unsupported application, game manager will download and install the game for you.
• Don please assist him about the Mac issue due to, I only have Linux.

Regards,
Carlos

Alex wrote:

Thanks, I just figured that out while you were posting;o)

I have the one complete Big Fish Games Bottle.

I open CrossOver Games, select Games Applications, it shows a Game
Manager (wine), and BFG icon. If I click the BFG icon, it says
'There is no windows program configured to open this file'

When I click on the Game Manager it opens the BFG Game Manager, but
when I try to click on a link to get to my account, it always goes
to a wine ie which is blank.

Do I need to download on a non-Mac, write to DVD, and then import
the games?

Hi Alex,

I live on the other side of the planet, so I was either asleep or heavily sedated at the time... 8)

Alrighty, lets see here....when you say "If I click the BFG icon"....which icon exactly do you speak of?
I've done the majority of my testing wrt BFG titles on linux (although I have recently acquired a iMac,
I've only about half as much testing done on that platform so far), but iirc some of the menu/shortcut
creation which BFGM (big fish games manager) does at install time was a bit goofy. I believe this was one
the issues that made me suggest to Aric that C4P have something in it to either stop or delete application
created links so that we could fashion our own (that's in the pipeline I think but I'm unsure when it'll
be part of C4P)...that said, I was using linux for those tests, so I'll look at it again on the Mac to check
this behavior is consistent across both platforms - use the 'games manager' shortcut for now, it works..

When you start BFGM and click on one of the buttons in that UI, presently it throws to mshtml7 which, as
you've discovered, leads you nowhere. This is actually intended/expected behavior at this time. This is noted
above where I mention "[i]I also chatted with Vincent to see if we can get the associations of mshtml7 changed
a bit so BFGM throws to the -system- web browser instead of trying to use mshtml7 engine to display things
when you click on buttons in BFGM itself[/i]"....I'm going to do some more testing on that front this weekend.

Due to that issue with mshtml7, at present you have to use your system's web browser to login to your BFG
account and/or purchase and/or download the game title installer stub of any game you have bought. Once you
download that installer, you can install it into your existing BFGM bottle (install other application), and it
should start BFGM automatically and start the installation itself.

See my posting above wrt bfggameservices.exe -- that's rather problematic, more so on the Mac, because the
seemingly detached process is lurking in the background somewhere, and after you quit a game (or quit a game
installation), that process is still running. In linux, you can click on 'force quit bottle' and it clears
the issue, however in OSX that wasn't an option -- only the 'quit bottle' button ever becomes active, and that
does not kill the bfggameservices.exe process. If you aren't aware of this and subsequently try to start a
BFG title, the game process locks up on the defunct bfggameservices.exe process and the game will -appear- to
start (you get an icon on the Mac's dock) but seems totally unresponsive -- I'll look into that today and see
if I can figure out a way to cleanly kill the process on OSX.

Hope that helps...just keep in mind this is all a bit wip and not quite as we would like it yet. If you've any
further question etc, post to this thread 8)

Cheers!

Thanks to you both. I will give downloading my previous MS version installer of a BFG via Safari to the desktop, and then figure out how to install it into my existing bottle. That part is the only part I am not quite sure of, but will have to attack tomorrow.

Do I just drag it from the desktop to the crossover games icon, or actually to the wine glass icon within crossover applications?

Thanks!

Hi Alex,

Install the BFGM app first - this will give you a bottle named 'Big Fish Games Manager'.

Using your system web-browser, login to your account and purchase a game (or download a demo installer)

Note: Safari wasn't handling the login part very well -- I use firefox on the Mac a lot of the time.

Note: If you go to 'PC Downloads' on the BFG site and click on a title to download, if a Mac port
of that game exists, the site logic will detect your OS and redirect the download call to the Mac version.
If an Mac port of a BFG title exists, it's probably advisable to use the Mac port in OSX instead of using
the win32 version via crossover.

Once you've downloaded the installer, start crossover games, and then go Configure->Manage Bottles

In the cxsetup GUI that appears, highlight the 'Big Fish Games Manager' bottle in the left panel, then click
the Applications tab -> Install Software.

In the cxinstaller GUI that appears, choose 'Other Application' then 'Select an installer', and navigate to
the installer file you downloaded above and click 'Use this installer' then click install -- the BFGM should
startup and begin downloading/installing the game itself.

Note: I've tested about 30 BFG titles -- not all are the same, and some require other dependencies.
This varies from title to title -- if you have any problems actually running the installed game, just let us
know which BFG title you're trying to get running so we can figure out what needs to happen...

Cheers!

Thanks again guys for the quick feedback, and especially to Don for the Mac specific instructions.

They worked like a champ for both versions of Elf Bowling. The only hang up was that after it looked like they installed within the BFG native window, the CrossOver App Installer Window progress bar was still hung up at 50%.

I waited for an hour, and finally escaped out of the installer since it looked like it took.

I restarted the system (old PC habit), and loaded CrossOver Games, went to apps, and it had both listed. Clicked on the wine glass which opened BFG, and the games worked flawlessly after that.

So just the one hang up, but it did not seem to affect anything.

I will let you know what works, and if there are any issues.

I will try Puzzle Quest tomorrow, and some hidden picture games next.

Thanks again for all your work, and easy instructions. I tried to find some that were that clear in the support FAQs and forums, but yours was the best. I also used Firefox for the downloads.

Cheers,
Alex

I myself posted;

"When you start BFGM and click on one of the buttons in that UI, presently it throws to mshtml7 which, ..."

Wrong - I tried realigning the moon with the planet saturn in the associations
for the bottle, but it made no difference -- going to need suspect it's throwing
to ieframe instead...need more coffee...

I also posted this;

"...but iirc some of the menu/shortcut creation which BFGM (big fish games manager) does at install time
was a bit goofy. I believe this was one the issues that made me suggest to Aric that C4P have something
in it to either stop or delete application created links so that we could fashion our own..."

..ahh yes, I remember now....Carlos actually 'beat me to it' wrt creating a c4p for this title by a matter
of hours 8) When I was testing stuff, I noticed you're given the option to create desktop icons and/or
'quicklink' shortcuts in the BFGM installer, and I was going to put in <installnotes> that you were best
advised to uncheck the quicklink item or whatever because it resulted in creating things that don't work
(which Alex ran into as well 8) If I had the choice, I'd rather automate that than rely on the user reading
the installnotes or even having to do any of that stuff anyhow....future fodder...

Some fool, probably me, said this..

"....bfggameservices.exe -- that's rather problematic..."

I didn't say enough...this linux box is running my own CLFS based build - it's a native multilib build,
and I've gotta be careful running/testing software on this machine, 'coz there's two distinctly different
runtime paths available -all- of the time. So I have two of everything..normally it runs like a 64bit distro
with 32bit 'compatibility' libs, but I can toss it the USE_ARCH=32 env-var and force it to use the 32bit
libs and binaries...due to the system build/makeup being unlike what 'most other people would likely be
using', I always check/test against a debian 5 box here...iirc it's 32bit 5.0.4 on a 1.2ghz sempron ...

That installation is having the same dramas, but it's a little different...for one, the bfggameservices
brouhaha times out in around 3minutes, which is roughly half the time it takes for this twice as quick
linux box or the three times as quick mac to accomplish the same kerplunk....

When I enforce the use of the 32bit runtime path on this machine, I encounter this;

err:seh:setup_exception_record stack overflow 884 bytes in thread 001a eip f754d976 esp 00240fbc stack 0x240000-0x241000-0x340000

On the deb5 checking proc, I found cxmenu <defunct> so something is parting ways there as well. So there
is definitely something afoot here.....on one hand I was sort of hoping the deb5 wouldn't have issues, on
the other hand I'm glad it's stumbling into the same problems (makes my build look 'sane' 8)

...I think I might install a 64bit based debian instance on the deb5 box and check there...

@Alex -- thanks for the positive feedback vis the instructions I gave you : I've only
recently (couple of weeks) had a Mac/been a Mac user, and one of the reasons I wanted
the iMac was be to able to type up clear examples for users of both platforms. Seeing
as how you commend those Mac instructions so, I've turned them into a tip&trick along
with the linux equivalent ... hopefully they will help others too... glad that you got
things going, I'll see if I can recreate the installation hang but I believe I know
what it is...to be thorough I'll check the specific titles you mention 8)

@Carlos -- thanks also for pointing out the need to better 'isolate' issues with some
individual BFG titles themselves -- you'll note the sticky thread I've posted here, I
think that makes as good a move as any to try funnel all BFG titles into this forum
and help get them slotted as well. Otherwise folks are going to end up having to pick
through some monstrously big thread for one tidbit of information -- it also may help
identify specific titles all suffering from the same issue, so we can figure out not
only which titles are popular which users, but also which of those are affected by the
most common issue(s), so there's some notion of which issue is the more important to
scratch our heads about?...something like that anyway 8)

Cheers!

I installed JewelQuest, and although the installation app progress bar froze at 50%, the BFGM installed completely, and the game works fine. I escaped out of the installer without incident.

My son and I played JewelQuest for about an hour with no problems.

My son played Elf Bowling: Christmas with no problems.

Thanks

dxwebsetup can be tweaked;

Thanks to Vincent for pointing out the change in d3dx9 handle wrt my slime army ticket.

When the 7558.c4p predep runs an dxwebsetup is called, it scans %WinSysDir% for already
existing d3dx9 dll files. By default, at bottle creation time many of these d3dx9 dll's
are fake (builtin) stubs....dxwebsetup determines these are already installed and as a
result, installs only those things it did not find. As a consequence, a BFG game like Slime
Army (which requires native d3dx9_27 & d3dx9_36 dlls) doesn't start after installation
because these dll files are not there.

If one uses <prermfakedll>d3dx9_27.dll</prermfakedll> <prermfakedll>d3dx936.dll</prermfakedll>
as part of 7558.c4p, dxwebsetup -does- then download and install native versions of these
libraries. So far with my BFG titles testing, I find quite a number of games titles rely on
(particularly) these 2 d3dx9 dll files. We could either include directx9modern as part of
a BFG game's* c4p predeps (full install of directx9 redist even tho we only need two dll files),
use prermfakedll to ensure both these dll files are pulled native, install directx9modern as
part of the BFGM construct to begin with (cover all future needs that may be encountered by
most any BFG title)...there's a few options....

Personally, I'd like to use builtin (fake) d3dx9 if at all possible, and only rely on native
dll libraries "when we absolutely really need to" .....ie; if dxwebsetup (which mostly provides
d3dx10 dlls) + just 2 native dlls (d3dx9_27/36) work with all the other d3dx9 set up builtin,
what point is there in making all the builtin d3dx9 native when we don't really have to? We
should be relying on builtin where we can imho...it might also help better identify when/where
any builtin d3dx9 dll goes strange on us -- if we override/replace -every- d3dx9, we might
not as easily see how d3dx is going (or breaking) and then which specific d3dx9* builtin may
all of a sudden change behavior.....

Thoughts, comments?

Cheers!

dxwebsetup can be tweaked [part 2];

Ok...finally something that works as expected --

1. leave 7558.c4p as it stands - when dxwebsetup is run, it will detect which d3dx dll
   files do not exist in %WinSysDir% (a reflection of which d3dx builtin stubs we do not
   currently have), and copy native versions of same into place. As said before. this is a
   lot of d3dx10 stuff + some other things we don't implement as builtins yet.

2. if your BFG title is requiring native dll files, like with the example wrt slime army.
   include your <prermfakedll> tags in the game's c4p file. During installation of the game
   itself, dxwebsetup is still run, but now it will detect the missing d3dx* dlls as defined
   in <prermfakedll> tags, and just download those parts of directx runtime required (2 dll
   files) and install the native version.

...that's not so bad in the end, perhaps even civilized...

Cheers!

Here's yet another way of handling this....it's briefer, it only provides the files
bfgclient itself requires, which furthers the onus on BFG titles c4p files to just
provide those things the actual game itself needs.

Pros - much quicker install, better isolates the dependencies required by BFGM and
what the games themselves need (no overlaps) and I think BFGM is perhaps a little
faster. The other bonus is when you click on buttons/links in the BFGM UI, it will
throw to your system web browser instead of a blank page hoisted on ieframe/iexplorer..

Cons - the BFGM UI flickers a bit, but overall the rendering/presentation of the GUI
looks a lot better in usage. At the same time, installing a bigfishgame title becomes
a little more complex in as much as you need to make sure everything -it- needs is
provided by it's own c4p (it no longer relies of predeps pulled in by the BFGM install).

Here's how to recreate it ;

New winxp bottle, install mshtml6 into this bottle...

Provide the following library overrides -- ieframe=native | mshtml=native | shadocvw=builtin

That should give you a nicely working BFGM -- I'n still seeing perl defuncts however looks like
winewrapper or cxmanip.exe.so are falling apart and dwafting the perl process...

I'll spool up and app c4p a bit later to show the ramifications of doing it like this...

Cheers!

Ok, my opinion about many things in this thread (as I understand):

• If at last dxwebsetup won't take advantage of the dll overrides, maybe it is better let the game to download dxwebsetup due to it will be downloaded once per bottle, same as running dxwebsetup directly via BFG dependency.
• If the game requires additional DirectX support maybe is better use the directxmodern provided by cxgames because it relies on the CX own cache so it will be downloaded once, even using more than a bottle.
• If we use dxwebsetup as a dependency, why inserting in the same C4P instead of using a different C4P file?
• Maybe we can define profiles for generic BFG Games and list the supported games in those profiles. For example I noted before that are games that are Macromedia Director based and ... do not run, for example: Return to Ravenhearst. We can do a C4P file for director based games.

Comments?

Regards,
Carlos

Carlos Rafael Ramirez wrote:

Ok, my opinion about many things in this thread (as I understand):

• If at last dxwebsetup won't take advantage of the dll overrides,
  maybe it is better let the game to download dxwebsetup due to it
  will be downloaded once per bottle, same as running dxwebsetup
  directly via BFG dependency.

dxwebsetup will take advantage of dll overrides, but as said before it's the games that depend on this, not BFGM....(nor does it need .NET. flash, corefonts, msxml, or anything else we drag in using either 7558 or mshtml7). Using the mshtml6 approach proves as much -- we should, by rights, only be providing BFGM with what it needs, and then let the games themselves look after their own dependencies. The game c4p files will become a bit more involved as a result, but it is still the 'proper' way to do it.

Carlos Rafael Ramirez wrote:

*If the game requires additional DirectX support maybe is better use
the directxmodern provided by cxgames because it relies on the CX
own cache so it will be downloaded once, even using more than a
bottle.

This would be one approach, sure, and I can tell you what happens if we follow that course;

1. You include directxmodern in a game c4p predep, that will be installed before the game and provide (all) the d3dx9* dll files

2. After any other predeps are installed, the game itself is then downloaded and installed. As part of the game install,
   it will -still- call dxwebsetup regardless because directx10runtimes aren't there (or represented) and Managed Directx
   (MDX) isn't there either -- with directx9modern preinstalled, when dxwebsetup is run it will look in %WinSysDir% and
   conclude that it only needs download 10mb of directx redists (instead of 24mb). As the game is routinely going to call
   dxwebsetup anyway, the MDX part of that installation will error out without .NET 2.0 being installed, so .NET 2.0 is by
   rights a predep of dxwebsetup all told --- that said, I'm not entirely sure the dxwebsetup error at the end of it's
   installation is mission critical..ie; AFAICT it's only some of the BFG titles based on directx7/8 (or earlier) that may
   actually need MDX (at least, that's what I gather from reading the MDX pages). If it is not absolutely required, we
   can probably live without .NET 2.0, and let the users know (via installnotes) just to ignore the error thrown. I think
   that to be a bit silly -- I'd rather the users never see an error (that we can avoid) nor have them read installnotes
   about an error (that we can avoid) which they can safely ignore. Avoiding the error by providing .NET 2.0 (even though
   only dxwebsetup needs it) looks more professional - having to alert users about an error (or even letting the error
   occur when we can avoid it) is for mine a bit hacky by comparison...

3. (I blame Jack for this comment 8)....if we install directx9modern into the BFGM bottle, we may never know exactly which
   d3d9x dll files are needed by any particular title, we just blithely assume all BFG titles need directx9modern (or some
   part of it), The truth is, that isn't the case -- some BFG titles do not need additional directx runtimes at all - the
   provided inbuilt d3d* targets work fine. Installing directx9modern as a mandatory predep will veil this truth..

Carlos Rafael Ramirez wrote:

• If we use dxwebsetup as a dependency, why inserting in the same
  C4P instead of using a different C4P file?

Well, the truth of the matter is the game installations themselves have the dxwebsetup hardcoded into them as a predep.
As such, we really don't need to state dxwebsetup as a predep in any c4p file - it's going to be called by the game
installer anyhow. As that is the case, by rights -every- BFG title should have .NET 2.0 included as part of it's own
c4p file, because of the hardcoding of dxwebsetup into the installer...ie; even if the game itself has no need for
.NET 2.0 perse, it's still going to need that to avoid the error when dxwebsetup is run....(see footnotes)

Carlos Rafael Ramirez wrote:

• Maybe we can define profiles for generic BFG Games and list the
  supported games in those profiles. For example I noted before that
  are games that are Macromedia Director based and ... do not run, for
  example: Return to Ravenhearst. We can do a C4P file for director
  based games.

Yeah, Macromedia based titles are the main ones I have found not to work as well....I've not found a resolve as yet to
that problem. Regarding profiles, that's definitely on the cards -- I've tested over 40 BFG titles now, and certainly
there are multiple BFG titles that all require the same c4p treatment. When this is the case, we could use the c4p tag
<installerid> ....ie; the Slime Army title requires d3dx9_27 & d3dx9_36, there are many BFG titles that require native
versions of just these 2 dlls, so any other game in this group profile can use the Slime Army install profile as well
via the <installerid> tag. No doubt there will be other targets like this, and this would expedite matters somewhat.

Footnotes:

! Right the now, all of this is going to heavily rely on <appbottlegroup> working as expected - this is currently not
the case, and as a result I think we should leave things just as they stand for now. Reasoning is (as Alex has helped
validate) we presently need to rely on users manually installing other BFG titles :: we don't want to break that now
until we have something better to replace it with - <appbottlegroup> will be that better thing.

! As Alex has also helped establish, in no way do we need to install directx9modern for all targets -- as he's discovered
there's games that run -without- directx9modern redist installed. I'm a bit standoffish pushing directx9modern into the
picture as a holistic approach wrt the BFGM bottle....ie; not all games in that bottle will need this silver bullet. (plus
I don't think it gives credit to the wine devs who's d3d9x targets actually work fine 8)

! As Vincent pointed out, having multiple c4p files with common predeps included in each is not a problem - the AI logic
will figure it out that a package is already installed (or needs to be installed at a certain time in c4p execution), so
for example including .NET 2.0 in every BFG title c4p as a predep isn't a problem -- once you install one BFG game title
into the BFGM bottle, the .NET 2.0 redist will be installed, once, into the BFGM bottle -- any subsequent BFG title you
install into the BFGM bottle will skip the .NET 2.0 install (already present), but dxwebsetup will still be invoked by the
game installer itself -- dependent on what dxwebsetup finds, will dictate what other things it needs to install (if any),
or else return that the latest version is installed :: if it's a first time install of dxwebsetup then it will install the
d3dx10* stuff + MDX but this too will only happen with the first installation of a BFG title into the BFGM bottle. You have
to treat it something like this, because beyond the BFGM install (without 7558 as a predep), we have no idea which BFG title
a user might install....
.....the issue I had with that (and why I figured to set it up like it is right now), is that a user
might come along and install BFGM and then try to install some other BFG title not covered in C4, and if so they're going
to run into the dxwebsetup error because .NET 2.0 won't be present -- right now, we avoid that possibility...but it is not
-technically- correct ; BFGM does not need .NET 2.0 or dxwebsetup itself.

! The other issues wrt bfgclient and bfggameservices are more painful at present imho...the c4p stuff isn't so much of a bother,
just a matter of logistics and having a common approach to handle these titles...and a bit of time for c4p to evolve more 8)

I'll do up a triplet of trial c4p files so related to demonstrate my experiments over the weekend - I'll post back when done...

Cheers!

Alex wrote:

I installed JewelQuest, and although the installation app progress
bar froze at 50%, the BFGM installed completely, and the game works
fine. I escaped out of the installer without incident.

My son and I played JewelQuest for about an hour with no problems.

My son played Elf Bowling: Christmas with no problems.

Thanks

@Alex - would you mind letting us know what your system specs are please?..ie;
OSX version, videocard and how much ram it has....you can get all this info by
startings Applications/Utilities/System Profiler ... (just so a can keep a map
of what's working with what hardware 8)

Cheers!

Up around 60 BFG titles I've looked at now...

The range of games in the BFG catalog includes titles based on directx 6
through to directx 9 -- afaict, it's only the dx9 based titles which go
and defaultly call dxwebsetup -- other titles do not do this...

With that in mind, we're probably in overkill mode with BFGM using 7558
as a predep -- it's convenient, sure, but it doesn't correctly represent
the situation of what BFGM actually needs. I'd even extend that premise
here wrt having mshtml7 as a predep -- it too is providing support packages
that BFGM itself does not actually require ; using mshtml6 with overrides
proves as much (and apart from the BFGM UI flicker, works just as well as
it does with mshtml7)...plus going that route throws to the system web browser
which makes the BFGM UI buttons more functional...examples;

app_id 7709 -- it will call dxwebsetup so .NET 2.0 is a dependency here.
It also requires d3dx9_27/36 which is accounted for by using <prermfakedll>
or whatever...

app_id 7837 -- it will not call dxwebsetup, however has a dependency for flashplayer

There are other examples like this where a particular BFG title requires
their own deps...vcrun, vbrun etc etc and so on.....

Wrt BFGM itself though, all it really needs (bare minimum using mshtml7) is
the ie7 rendering engine + msxml3 -- we don't need flash10ocx nor corefonts
to satisfy BFGM's requirements...

Cheers!

Carlos Rafael Ramirez wrote:

@Don

Have you has problems with this error?

"err:seh:setup_exception_record nested exception on signal stack in
thread 0038 eip 7bc73840 esp 7ffdbc7c stack 0x242000-0x340000"

It happens in many BFG games, and I don't know how to deal with it

Regards,
Carlos

P.D Game: MahJong Jade Expedition

@Carlos -- I had a quick look at this ; with linux-2.6.34 I instead get ;

err:seh:setup_exception_record stack overflow 900 bytes in thread 001a eip 7bc6fae0 esp 00240fac stack 0x240000-0x241000-0x340000

I'm getting this with a couple of other BFG titles, plus there's some chatter on this over
at wineHQ....check the following search results;

http://www.hotbot.com/?query=setup_exception_record+stack+overflow+900+bytes+stack+0x240000-0x241000-0x340000&ps=&loc=searchbox&tab=web&mode=search&currProv=msn

It appears like this is all so related to the ptrace function in the linux kernel itself,
so it may be the 'fix' for this is at the kernel level...where we go from here is up in the
air...I'll attempt to find out exactly where this is headed...

Cheers!

It is the new iMac 21.5

OS X 10.6

Hardware Overview:

Model Name: iMac
Model Identifier: iMac11,2
Processor Name: Intel Core i3
Processor Speed: 3.2 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache (per core): 256 KB
L3 Cache: 4 MB
Memory: 4 GB

ATI Radeon HD 5670:

Chipset Model: ATI Radeon HD 5670
Type: GPU
Bus: PCIe
PCIe Lane Width: x16
VRAM (Total): 512 MB

Hi,

http://rapidshare.com/files/413434809/C4PSTUFF.tar.gz

Imho, I think that's how we should be proceeding - there's a readme in the tarball

@Alex -- Thanks - exact same machine as I have here ; question -- was that
the full version of Jewel Quest? With the demo version I get a C++ runtime
error. so I'm just wondering why that is so ;)

Cheers!

Per my posting immediately here above - I also sent that information to info@

As a result, mshtml7.c4p has been weight reduced by removal of the corefonts
and flash10.ocx -- if your BFG title needs these things, you can pull them
in with the app's c4p. Further, if we're going to be succinct about reflecting
in the c4p system exactly what each app -actually- depends on, 7558.c4p no
longer belongs here either as a predep, so later on when there's a Ninja about
I'll remove that spec and get the c4p toggled back on.

...I'm actually going to put this back up to silver after seeing how it behaves
in real winxp -- we're actually following the native behavior very closely, the
only real shortcoming being the throw-to-web-browser (which does work w/ mshtml6)
....it's just the nature of the universe that bfggameservices.exe hangs around
for 4minutes anyhow, and it makes one wish for a bottle watchdog that you could
assign to a specific process, and if that process goes down (bfgclient.exe) then
we pull a magic silver bullet out and shoot bfggameservices.exe down in response...

{sigh}

Cheers!

Note: there are some BFG titles which require emulated virtual desktop enabled or
they will now start -- is may also be to do with a wine-bug, but it's very similar to
the situation with Steam...ie; if emulated virtual desktop is OFF for the Steam bottle,
you cannot turn emulated virtual desktop ON for any steamaaps therein - they will inherit
the bottle setting for emulated virtual desktop. Same is so for the BFGM bottle -- I'm
attempting to leave emulated virtual desktop OFF for the BFGM bottle and working around
that presentation on a per app basis...so far the majority of BFG can handle this...

...however, BFG titles such as app_id=7833 do not play with this approach well, so if needs
be some BFG titles will need to live outside of the BFGM bottle to run (and not end up
breaking anything else)...at least, at this stage anyhow....FYI only...

Cheers!

Another couple of more points;

1> the new version of BFGM, the downloaded demo installer stub is removed/deleted at end of installation

2> I notice if you set the library override for iexplorer.exe to 'disable', this stops BFGM throwing
to the IE window that isn't going to do anything. Of course, this isn't as preferable as finding a
way to get BFGM to throw to the system browser, but it may be 'nicer' if it didn't try throwing to
something that doesn't work at all....

Comments invited wrt to point 2> ; should we disable this anyhow for now in 6268.c4p?

Cheers!

Hi,

I've added another predependency to the C4P profile here ; it's
a bit of a kludge to work around the standoff wrt bfggameservices.exe
for now. Later on when C4P matures a bit and grows it's flight feathers,
we can rework this somewhat to better automate it, but for now this
is about as close as we can get I think...

Details :- app_id=7992 provides the win32 app 'taskill.exe' which is
linked to the %StartMenu%/Shutdown BigFishGames Services shortcut - this
provides a quick menu driven way to kill bfggameservices.exe at any time,
either after playing a game or during the install of a BFG title into the
BFGM bottle. I'm also including this specification in my C4P profiles for
BFG titles, so that in the stand alone install choice (a bottle other than
than the BFGM bottle) this menu item is also available.

Later on, and presuming bfggameservices.exe is always going to present us
with this tiny handling problem, the link to the %StartMenu%/Shutdown BigFishGames
Services shortcut can be reworked so it calls reboot.exe.so instead as it
will effect the same ends here achieved by taskill.exe....

At that time, I can rework 7992.c4p to be something more appropriate as a
postinstall target -- it will provide a 'one shot' mechanism to kill
off bfggameservices.exe at install time of a BFG title. In this instance,
taskill.exe isn't installed at all into the bottle -- it's postinstall process
should be able to be triggered by WINE_WAIT_CHILD_PIPE_IGNORE attached to the
BFG title's registration helper (variations of the exe name 'rtpndxz.exe' for
example where the leading 7 chars differ from one BFG title to another) - this
works fine in local testing.

Of course, nothing is set in stone here, and things may well change in the future
but for now this is 'the plan' I have and provides a way to make life a little less
problematic for the user when it comes to dealing with bfggameservices.exe...

Cheers!

Hi,

Ooops....what I forgot to mention above, is that taskill is ostensibly
useless in OSX, as you can't 'see' bfggameservices.exe in the process list.
The only way out of the hole in OSX will be to call reboot.exe.so or such,
to enforce a bottle reboot (which should take down the running process) --
this is neither here nor there, but I just wanted it to be known before
someone says "it doesn't work on Mac"....8)

....we have another issue as well -- when you run 6268.c4p, cxinstaller
will routinely download the BFGM client installer, and leave/keep that
file in $installers --- if, in the interim, the BFGM client software is
updated, and you subsequently install another BFG title ('outside' of the
BFGM bottle) when the c4p in question has 6268.c4p as a predep, cxinstaller
will install the older version from $installers, and when the BFG title stub
starts, it will install BFGM client again to update it -- you'll see BFGM
client being installed twice. I don't think it's a problem perse, just looks
a bit strange when it happens...

Cheers!

Artist Formally Known as Dot wrote:

Ooops....what I forgot to mention above, is that taskill is
ostensibly
useless in OSX, as you can't 'see' bfggameservices.exe in the
process list.
The only way out of the hole in OSX will be to call reboot.exe.so or
such,
to enforce a bottle reboot (which should take down the running
process) --
this is neither here nor there, but I just wanted it to be known
before
someone says "it doesn't work on Mac"....8)

It doesn't seem to work in Linux either.

I just installed Drawn (7982), another Big Fish game, with the c4p I just created for it, and taskill could not be downloaded.

Power outage was the first problem, followed some 20hours later by some networking
issue our ISP was having...it is up again now, so I hope they've got everything
sorted properly...

Cheers!

...well, this is going to be near the end of this thread - once
Crossover (Games) version 10 is released, we won't be talking about
c4p recipes, we'll be chatting about crossties instead...I will
probably lock this thread at that time, and create another with
the newer name....

...I haven't seen reboot.exe making an appearance in winsysdir,
but we will have taskmgr.exe && (native) taskill.exe available
in 10, which will make things a lot better (you can actually ID
specific win32 processes in OSX using this stuff ;)...I know it
works, I just haven't noodled it all out yet...

...the win32 taskill.exe will, I think, be replaced with something
else, likely a virtual c4p as a post-dep best I can figure it
now. I'm not sure exactly what will become of app_id=7992 - I will
probably still change it (because..) we now have the same functions
using native wine tools ,..hmm...I suppose it doesn't hurt to have
an extra silver bullet around to kill off pesky win32 processes ~B)

..the links in BFGM will throw to the native web browser properly
as well, but the menu handling is still a bit goofy when you get
multiple BFG titles installed...the swf should start to work too...

...life would be nicer if the BFG devs linked the delayed exit
of bfggameservices.exe back to whether or not the quick launch
bar is installed, but nothing seems to have changed there...;-/