...I should've been a bit clearer about winetricks...
Winetricks uses abbreviated target names, but most (not
all) targets have equivalents in Crossover - for example,
the command 'winetricks vcrun2005' is equivalent to
installing the Microsoft Visual C++ 2005 Redistributable
package from within the 'Runtime Support Components'
area of the cxinstaller GUI, the other targets will be
fairly self-obvious to a 'windows power user'...
...oh, mfc40.dll may be the exception there ; it's provided
by the c4p profile available from the vcrun2003 C4 page;
http://www.codeweavers.com/compatibility/browse/name/?app_id=8036
Never use/look for 'winetricks gecko' ; this is 'cxhtml engine'
to us, but there a couple of ways of presenting that. We also have
4 distinct targets for IE -- IE 6, IE 7 & mshtml6 , mshtml 7 ;
they are all different and provide different levels of functionality.
If you look at the 'Libraries' tab in the Wine Configuration GUI
(also check for an app profile entry in the Applications tab first),
you can see which related -native- win32 dlls are being used, and
any others where we are using the wine builtin versions instead.
Again, if you know windows really well, you'll know what dll does
which function...blablabla...I won't bother detailing it ;)
...if the app absolutely needs dcom98, you should probably be
using a win98 bottle profile ; if that were the case, IE6 instead
of IE7...etc and so forth ; you're basically trying to recreate
the windows environment as the win32 app expects to find it...
...windows error messages can be, for the most part, about as
useful as ashtrays on a motorbike - as we're not an emulator
and therefore not running any 'real' windows kernel, it's fairly
easy to provoke a win32 error message that has nothing to do with
the actual problem...ie; the windows error of 'cannot load some.dll'
might be disclosed in Crossover debuglogs as 'cannot load some.dll
because someother.dll on which it depends cannot be found'...or
such and similar -- if some win32 doesn't run 'out of the box',
the quickest way to find out why (and perhaps what is needed), is
via running the app with debugging turned on...see;
http://www.codeweavers.com/support/wiki/SubmitTechSupportLog
One can use those instruction to create debuglogs, and examine same
to determine what's going on - not all the available debug channels
are presented in checkbox fashion, hence the 'Other:' stringbox
widget. You can enter one (or more) debug channels here to look at
specific areas of interest...a more complete list of the available
debug channels is over at winehq...see;
http://wiki.winehq.org/DebugChannels?action=show&redirect=winedebug
If you know windows well, it's fairly self apparent what channels
you want to be looking at. Going through the resultant logfiles may
appear arduous at first, but, if you know what you're looking for,
it's fairly easy to grep the lines you're after...ie; debug output
lines starting with 'warn:' or 'err:' are going to be of immediate
interest. As exampled in the thread I linked to, some many times the
'missing pieces' as it were, are not identified by plaintext filename,
instead they will be identified by windows registry CLSID/GUID significs,
which I probably don't need to explain to you either <grin>...typically
my first debug pass uses +seh,+trace,+ntdll,+loaddll or such ; that
gives me a pretty good first glance at the 'lay of the land' as it were.
Hope this helps...
Cheers!