From what I can tell, as of 16 March with the release of CXG 10.1
the Turbine Downloader (Pando) now works.
I'll let you know in about 7 hours if the Turbine Launcher also now
works.
....Just a few bobs' worth here, might save some time ... I've been mucking
around with a crosstie for DDO which actually works (just...) ; the Pando downloader
does indeed work .. if fact, you don't actually need anything else in the bottle
for that caveat arial_font (makes it look better) - it works...
...comes complete with it's own curse too - 'PMB.exe' - this is 'Pando Media Booster'
or such, which more or less orchestrates this part of the file download/installation
process - it actually spawns the various child processes (3 or 4 of them) to get the
'real' work done, but once complete and you exit the actual installer (dndsetup.exe),
PMB.exe keeps running in the background - this stalls the crosstie execution flow at
that point. This scenario is very similar to what 'bfggameservices.exe' does as part
of the BigFishGames installer/thin-client -- that exe does the same thing, so I created
app_id=8477 to deal with that issue...
...chatting with Aric the other night, I mentioned this to him mainly because I didn't
myself think it was exactly 'sane' to be going around creating virtual crosstie/C4 entries
for every time one wanted to killall -9 <some.exe> to facilitate an install profile
shizzle - InstallShield's 'idriver.exe' is another install helper like this that blocks
things, so Aric reworked my meanderings with taskill.exe|taskkill.exe (the former being
a 3rd-party task/process killer, the latter being the builtin wine exe that does the
same thing and appeared as of CX-10), so that one can specify one postdependency app_id
to kill numerous things, you just have to set it up for the exe you wish to kill or such...
...as it stands now, the DDO crosstie profile actually works but it's a tad more convoluted
than I would like presently ... some of it is a bit obscure, what with pre & post deps.
The same 'curse' above wrt PMB.exe that stops the show in a crosstie sense, also holds the
underlying win32 thread open ; you can exploit that in a crosstie by ignoring one process
and waiting for another (at the same time). I'm not installing directx9modern there, I'm
currently calling app_id=7558 in predep, and the old directx9 target (4099) as a postdep,
and that shouldn't be needed -- 7558 can be taught to do 4099 things, I just have to check
which part(s) of the old directx9 makeup DDO et_al actually needs (probably amstream/qcap
& friends at a guess). Directx9modern didn't get a look in yet, mostly because I didn't
perceive any need -- perhaps 7558 is providing what's needed, part of the same debug check =)
....which brings me down to 7558 itself, and why the heck - do we really need msxml3, mshtml7
and .NET 2.0? The answer is 'probably not', but the point of that is to satisfy dxwebsetup.exe
needs, specifically the MDX fractions, and stoopid dxwebsetup insists on something better
than our current builtin ... times will change I hope. The .NET 2.0 dep it needs for the MDX
components ; it includes some obscure directx assemblies that can avoid some vcrun2008 oops'.
However....
...I could probably live with msxml3&ie7 tagging along, if the Turbine launcher worked with
.NET 2.0 ... which it doesn't btw, it still insists on .NET 1.1 as per normal ... I'll have
restage a bottle, swap out 7558 for .NET 1.1 and see if there's smoke and the world stops
turning etc etc ... and then I might need the newer directx9 redist as well... the DDO
install profile will change tho' to remove 7558, but currently it resembles what would
have been 'a nice compromise' had the Turbine launcher played my silly little game... =)
Oh!, and btw, PyLotRO worked really really well during my testing above, with everything
working as expected - most civilized I thought, and seeing as it needs nothing in 7558,
for now it seems like the better way to go ... and then without un-needed M$ hangers on... B)
Cheers!