Big Fish Games Manager Forum

Okidoki, I spent last night looking closely at this, and I think
I've riddled it out -- I'd be keen for others to try it out and
post back -- note: I'm not entirely sure it works for OSX yet...(untested)

test case --> app_id=6798

silver bullet -> app_id=8477

requires --> Crossover Games 10 or better (for postdependency function) with this (app_id=6268) already installed

trigger --> WINE_WAIT_CHILD_PIPE_IGNORE

What happens -- In your BFG app's install profile, you set WINE_WAIT_CHILD_PIPE_IGNORE against bfggameservices.exe ; (same is so for 8477, but you don't need touch this one). During the actual installation phase of (here) 6798's profile, both bfggameservices.exe & bfgclient.exe are started (the GUI part) ; both these things hold locks at this time, but, once the installation is actually complete, it's the still running bfgclient.exe stopping the show, not bfggameservices.exe as we've specified WINE_WAIT_CHILD_PIPE_IGNORE against that process. From the end user's perspective, (who's watching the BFG Manager actually downloading and installing things), there's a chance they may notice cxinstaller sitting there likewise as the install proceeds. Users being people, are too hard to predict as to what they might do next, but, if they immediately choose to launch the game (from BFGM) after the game finishes installing, it should be ok (unless the default fullscreen of the BFG title smashes the display, figuratively speaking) You can ~try~ avoid this with install notes in the BFG title's install profile ...ie; Please exit the BigFishGames Manager when the game has completed installing ... for as long as bfgclient.exe is running, cxinstaller is going to be around showing install notes text (which should be able to flash and blink to get users' attention ... ;)

In any event, they either tried starting the game straight away and it went BOOM!, or they exited the BFGM once they saw the game install successfully,
and there's the auditory sound of Felix the Fish vibing on his Xylophone ... or they may have even played the game and want to 'finish installing'. The moment user exits BFGM and bfgclient.exe dies, 6798.tie is free to complete it's WINE_WAIT_CHILD_PIPE_IGNORE trigger, and move onto the next stage of execution (sic) -- postinstalldependency. Note that even though 6798 has been escaped here, -technically- speaking it was escaped far too early in the piece, and it's caught the 'go away now please' call long before the actual game has finished installing ; if we escape completely at this point, we won't end up with any menus (we need a rm menus function), -and-, installed detection will fail. This bit, accomplishes the 'controlled wait state' I was looking for here - get the user to do it =) .... they just appreciate interacting with BFGM as they should be ; they don't know they hold Uzi...

....cleaning up... as 6798.tie leaves center stage in sympathy with bfgclient.exe being closed, bfggameservices.exe is still running .. this has always been the problem ... so ... 8744 is invoked to kill this process dead, absolutely, 'double tap'. If you cite 8477.tie, you'll see it calls itself as a postdependency -- get the impression I'm fairly pissed at bfggameservices.exe? You bet! =) I haven't actually checked if the recursive rattle-gun effect is evident, but, 8477 is only virtual -- it calls the same 'taskill.exe' used in app_id=7992, but it's used in a different way -- 7992 provides (now) a task killer for CXG 9 users who install this (6268) via c4p/tie. We don't need to that for CXG 10 ; we can just link to the newly added 'taskkill.exe' native wine utility for this. When 8477 uses taskill.exe, it's to kill off bfggameservices.exe, even though the tie actually ignores the already running bfggameservices.exe process as such ; 8477 should always complete successfully (caveat no sanity checking is done to see if we -succeeded- or not, hence my attempt at a double-tap), and on the way out it's going to reread/refresh the bottle's menus/links, which 6798.tie probably didn't get done ... another double-tap at worst, benign at best... note: 8477 do not install anything - it fudges the line around the premise of being a 'virtual application' ... hehe ...

This gives the impression that the installation happened as a smooth progression, even though some non-typical install profile usage is afoot ....

Note: it still needs some cleaning up ; if .net is involved, more apps need to die =)

Let me know how it goes (or not) - try your own ties out using 6798.tie as a template

Cheers!

edit -SIFA

Following on from the above, there is an obvious flaw in the plan ; it
presumes this, app_id=6268, has already been installed, and, it assumes
the user wants to install it there. This may not always be the case...

Top of the list, is this install profile here - 6268.tie doesn't enable
emulated virtual desktop -- some BFG titles, depending on your Platform/OS
or video hardware, will need it. If this is the case, you can't start BFGM
with emulated virtual desktop off, and enable it just for a particular app.
In effect, the same locks I'm relying to pull this off, stop that from being
an option (presently anyhow)...

...the short of it is, if the BFG game absolutely requires emulated virtual
desktop, you probably shouldn't specify 6268 as 'extra for' ; it might be
best to install it into it's own bottle. Likewise, the user might want to
do that anyhow, because they prefer 10 BFG titles in 10 bottles (each with
it's own name and menu entries), and not have the same 10 BFG titles all
bundled into the 1 BFGM bottle...

.... "for whatever reason" it should be made possible that any BFG title's
install profile be able to "stand on it's own" without any need or reliance
on this, app_id=6268 - doing this is a bit tricky, because you don't want
to break what works (above). The large slice of common sense here, is that
cxinstaller -tells- the user what it's going to do before anything happens.
Ergo, the text string "Will install into [bottlename]" is the user's last
chance to sway the automation. Thus, you can leave 6268 in a BFG title's
profile, 'just in case' this app, a BFGM bottle, exists and that's where
the user wants it. If they -don't- want it there, it's up to them to choose
the 'non-default location' they want, which invariably will be 'new winxp
bottle' bearing the same name as the BFG game....

... everything else the BFG title needs to install and run, it carries in
it's own install profile. If it gets installed into a bottle where any of
the dependencies it needs are already present, it won't install them again...

...when this, BFGM, isn't already installed, you immediately lose the very
same software locks instantiated by the first win32 process the currently
running wine process initiated ... m'kay? ... so you have to forcibly use
bfgclient.exe as a conditional against the currently running wine process...

...so....

test case --> app_id=7832

silver bullet -> app_id=8477

requires --> Crossover Games 10 or better (for postdependency function) without this (app_id=6268) already installed

trigger --> WINE_WAIT_CHILD_PIPE_IGNORE

safety-catch --> WINE_WAIT_CHILD_PIPE

What happens -> Much like the above, except the safety catch. At the time
of install profile execution, the effective locks are attached to the BFG
game installer stub (and child processes spawn off that), and bfgclient.exe
doesn't actually start until much later on in the stub installer's proceedings.
So, if you escape bfggameservices.exe here as per the first example, the child
process lock isn't yet established against bfgclient.exe .. ERGO .. we push
WINE_WAIT_CHILD_PIPE against bfgclient.exe and still ignore bfggameservices.exe
at the same time. This holds the flow together just like it does above, and
maintains the lock 'that's soon to be there' so cleanup can be achieved via
the same method, and we don't break automation installing into 6268 either....

...(since'a'this'ah''since'a'this'ah')...

Example case --> app_id=7832

That one is all but finished, or as far finished as I can take it
right now. I don't have the full version, 7832 was one of the first
BFG titles I started toying with, and so it was always 'first cab
off the rank'. The only thing really missing, is <downloadglob>,
which once filled in, should allow the cxinstaller logic to go
automatically discover the user has already downloaded the full
version of the BFG title stub, and use that installer instead....

...now...lemme see, an example with downloadglob .....

edit: downloadglob may be impossible at this time ; it might also
be considered superfluous here depending on how one looks at things...

Oooo.... since'a'this'ah can spook C4 ... interesting....

Example case --> app_id=5480

This is an example of one of those BFG titles you don't want
to sling into the BigFishGames bottle because it requires that
emulated a virtual desktop be set. (my iMac particularly spews
if emulate virtual desktop isn't set)....

It also demonstrates another nuance in using crossties like this ;
as it requires .NET 2.0 as a runime dep (not an install time dep),
you will break the crosstie install flow (lose a handle lock) if
you install .NET 2.0 as a predependency. You'll tend not to find
this with other apps needing .NET 2.0 (caveat Impulse which needs
.NET 2.0 handled differently for another reason), but in this shizzle
it'll unhook things as a predep....

....so, the .NET 2.0 runtime is installed -after- everything else is
done, and when it has finished installing, 8477 helps clean off the
floor as we leave by the proper door....

Do not get this case example confused with a BFG title that needs
.NET 2.0 as an install time dep (and a runtime dep) ; that situation
is still handled in postdependency, but to get there one has to jump
over an error and fix what didn't happen on the way thru ... ummm ...
which BFG title behaves like that (there's a few)...I'll make that the
next example, and explain a bit about 7558 & BFG titles at the same time...

Example case --> app_id=7709

In this case, we need .NET 2.0 to happen after main install as well
(to maintain the flow), but, the BFG title here is expecting .NET 2.0
to be available -at- install time. This is due to the fact that this
BFG title's installer stub as going to call dxwebsetup.exe as part of
the show. What the BFG title is looking for, is managed DirectX (MDX)
and what we need (in CXG) are 2 native directx dll files...

..note that for the MDX components to install correctly, .NET 2.0 needs
to be available. Normally you'd just install .NET 2.0 as a predep, but
we can't here ... so ... one of the first things the tie does is to use
rmfakedll to remove the wine placeholders for the directx dlls required.
When the app installation calls dxwebsetup itself, this will cause the
needed directx dlls to be installed .... as mentioned though. the MDX part
of this install can't work yet, because .NET 2.0 isn't available at that
moment, but it will do this much and not throw an error...

..once the app itself has finished installing, then the tie calls our own
dxwebsetup target (app_id=7558) as a post dependency - this installs the
.NET 2.0 package, and reruns dxwebsetup a second time to fix the MDX that
quietly failed to do this during the app's install --- once this finishes,
we clean up with 8477 as per previous examples....

...note also, that this BFG title (7709) tries to first time start fullscreen
@ 640x480 -- this can be less than desirable. Some BFG titles actually store
the windowed/fullscreen mode setting in the windows registry (like this one)
and you can use preinstallregistry to set up the builtin windowed mode of
the game before the user needs to touch anything ; after installation when
they start the game, it will start in windowed mode to avoid 640x480 panic =)

Wow. Thanks for all that work, Don.

Hopefully I'll get to add some RPG Maker XP game caveats to that list 😀

Work? Where? .... /me was playing the Crossover game 'crossties' =)

...I've just been checking this on the iMac today -- the install works,
but not to the same depth ; the staging of the tie execution still holds
good, and the tie itself finishes out ok (menus get created, we exit in
a graceful fashion[1] etc), but, our old friend bfggameservices.exe -is-
still left running in the background -- we can't do anything about this....

....for non-OSX users, this is why -> in linux, each win32 process can
be identified by name as it appears in the host's process list, so
if you use ps you will see 'bfgclient.exe', 'bfggameservices.exe' etc etc
in the list along with linux native processes. In OSX, the native host
processes started by cxwine are -all- named 'wineloader' or 'wineserver'
and the output of ps will show multiple, same name instances of win32
processes. Each process name, although name identical, does have it's own
unique PID, but as we don't keep record table of which win32 exe got what
PID, we can't use wine-app taskkill (nor win32 taskill) introspectively
to target a specific process .... {sigh} .... what does work on the Mac,
is either the wine-app taskmgr.exe (or the win32 taskill.exe launched with
no options) ; then the Mac user can see the individual win32 processes just
as cxwine views them, by their proper name....

...the corollaries of all this, are that the 'shutdown bigfishgame services'
menu link created by this c4p/tie, works in linux but not in OSX, and as
said, 8477 doesn't work in OSX either (although it does refresh the menus)...

....what actually makes more sense here (for OSX) is calling taskmgr.exe or
win32 taskill.exe so that they pop the little GUI listing the win32 processes
currently running in the BFGM bottle (or a standalone BFG bottle), and the user
can select bfggameservices.exe process and terminate it -- that said, I would
want what we currently have that works (in linux) to stay put, and that we
somehow have platform detection in the c4p/tie system, so if it's OSX we're
install to, we create different menu links to taskmgr.exe/win32 taskill.exe
in that situation.... (I'll pop a post into the advocate c4p/tie thread about
this just to make sure it gets some air)...

TBH, I'm being somewhat dismissive of the OSX situation with this -- there's a
number of BFG titles with native Mac ports, and the issue itself ... imho ...
is more-overly to do with silly notion of renaming processes all to the same
name (I believe it's considered a security feature of OSX) - that makes it hard.
However, for these reasons I'm less persuaded to spend time/effort chasing the
OSX issues here, and would rather get the linux case up to snuff instead - at
the same time, it would still of course be nice to get things nice in OSX too,
but I figure that may take some time ... a case of priorities...

Note also, bottle detection is being a little over zealous - I'll post to the
same advocate c4p/tie thread about that situation, as it is likely going to
hit Impulse driven games as well....

...it would appear as though we don't need the double-tap on menus
in 8477 ; if I can prove this to myself beyond reasonable doubt, I'll
alter 8477 for that it doesn't try that operation...

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

...I was just working on the above to fine out a few more things...

*now have a way to kill bfggameservice.exe in OSX using cxwine taskmgr.exe

*found a registry key to preselect the processes tab in taskmgr.exe ;)

*created post in forum here and use <postinstallurl> to throw to it, which
better explains the bfggameservice.exe position & menu links

*changed text in <installnotes> to better expound a possible issue wrt mshtml7

You can grab the above 8684.tie from within the crosstie editor on that
page if you want to give it a go, see what you think, comment etc etc...

...I'll move some of those things into 6268.tie (here) on Monday to avoid
the crosstie on this page from dropping off the map...(or I might put the
bits in 8477 instead ... might make more sense )...

..Tally Ho!...

Ok, I've finally gone over all those examples and I know what everything does ...

Except for the environment vars.

What exactly does setting WINE_WAIT_CHILD_PIPE_IGNORE or WINE_WAIT_CHILD_PIPE mean? You're setting environment variables, and their values are some .exes, that much I understand. But who looks for these vars, when does it look for them, and what does it do when it finds them?

Thanks!

Alejandro Moreno wrote:

Ok, I've finally gone over all those examples and I know what
everything does ...

Except for the environment vars.

What exactly does setting WINE_WAIT_CHILD_PIPE_IGNORE or
WINE_WAIT_CHILD_PIPE mean? You're setting environment variables, and
their values are some .exes, that much I understand. But who looks
for these vars, when does it look for them, and what does it do when
it finds them?

Thanks!

..M'kay ... let's see if I can answer here and make sense at the same time. First up,  

I did actually 'go out of my way' to -not- refer to these things as environment variables.
I see them more as directives of what to do resultant of receiving the semaphore hacked
into the cxwine code (this is all in the CXG FOSS btw) ; if one wanted to refer to them as
environment variables, it's best to understand they are env_vars to the python/perl and
scripting processes being run ; cxwine itself doesn't respond nor interact here ; it merely
pops a semaphore dependent on the state of the child win32 processes it spawns....

..the default position is one of WINE_WAIT_CHILD_PIPE == unconditional ; cxinstaller will
not continue/finish off for as long as there is a child process active registered against
the instantiating cxwine 'parent' process. There may be one or more child processes spawn
by the parent, as if often the case, and assigning the condition specified by an executable
name .. ie; WINE_WAIT_CHILD_PIPE = win32process_1.exe .. in real terms means 'do not complete
script execution until win32process_1.exe exits and cxwine tosses the semaphore indicating
that has happened'. If the cxwine process also spawn other win32 processes (win32process_2.exe,
win32process_3.exe etc etc) then the default position applies to those executables....

So, WINE_WAIT_CHILD_PIPE = bfgclient.exe only means 'hold this position until cxwine tells
us bfgclient.exe exited'. As for where 'this position' is, it's perhaps easiest understood
as being inside <installprofile> and before <postinstallprofile> is instigated...

...now, because we aren't taking any particular notice of any other child process, and,
those processes my still be running, to move on from 'this position' we would need to
ignore the fact those win32 processes are still running ... in other words, we have to
negate the default position established by the semaphore locks ; enter the antonym for this
shizzle, WINE_WAIT_CHILD_PIPE_IGNORE. This tells the cxinstaller process (not cxwine)
to do just that -- ignore any (specified) still running win32 processes and move on. The
<postdependency> is actually nested here, just before <postinstallprofile>, and so if
the latter exists that's where things move onto, else the former is next in line...

...I suppose the other thing to mention, is that both <appprofile> & <installprofile>
must be satisfied before things can move on ...and this means, <installedfile|keypattern>
must return cleanly before <postdependency> and/or <postinstallprofile> can be actuated.
This is, in fact, another facet of WINE_WAIT_CHILD_PIPE = bfgclient.exe, because that win32
process is needed to create the match for the <installedfile|keypattern> specification =)

Btw, another place where this strategy could be used, is to handle InstallShield's 'IDriver.exe'
process which invariably hangs on and thwarts a normal c4p/tie profile ; one could have an
'InstallShield Installation Helper' in C4 to be called as a postdependency to automatically
kill IDriver.exe after the main app installation had completed ; the staging would be very
much similar, I think the only difference being attaching WINE_WAIT_CHILD_PIPE to the installer
exe process or such'n'similar....

Cheers!

Excellent!

Very clear. And yes, they don't sound like shell environment variables, but more like global variables for the cxinstall script.

Thanks!