I've basically never used WINE before. Any suggestions where to start? There seem to be a bunch of mailing lists, but with extremely low signal. (Yes, I've seen this. It is very long and overly optimistic.)
Oh, it also spits out this shit constantly:
- fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found!
Using closest match instead (United States keyboard layout) for scancode mapping.
Please define your layout in windows/x11drv/keyboard.c and submit them
to us for inclusion into future Wine releases.
See documentation/keyboard for more information.
...
Warning: L"/usr/bin/wine" not accessible from a configured DOS drive
Warning: L"/usr/bin/wine" not accessible from a configured DOS drive
Warning: L"/usr/bin/wine" not accessible from a configured DOS drive
Googling on that (and even reading the manual) has failed to provide any clue at all. This happens on multiple machines, so it's not like I'm using some crackpot keyboard driver.
I'd suggest getting a VMWare with a win2k running inside. Haven't had good experiences with DOSemu and WINE yet myself.
There's absolutely no advantage (and doubtless countless bite-you-in-the-ass-later disadvantages) to running Windows in an emulator instead of just running it on the box directly.
The point of this exercise is to avoid running Evil Empire software at all. Why do you think I'd even be bothering with this crap if not that?
*chuckles* OK, good point :P (and typical Linux-user at that!)
The wine config file lives in /etc/wine/wine.conf on Red Hat Linux 8.0. Within it is a setting for Windows Version to emulate (note that ; acts as a comment field):
[Version]
; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31)
;"Windows" = "win98"
; DOS version to imitate
;"DOS" = "6.22"
I'm not in any condition to test whether this will resolve the issue or not, but hopefully its useful information.
If your Red Hat 8 box is fully up to date w.r.t. patches from Red Hat, WINE won't run, according to an email I got from the Codeweavers guys. Basically, WINE does illegal things with errno in order to create a threading model that works more like Windows' threading, and as of the most recent glibc patch issued by Red Hat - which is, I think, a move from glibc 2.2 to 2.3 - this sort of tinkering is explicitly prohibited by the glibc guys and fails to work any more. It may well be this that's biting you. The solution - at least, to this part of the problem - is to downgrade your glibc again.
Of course, if you're still running an unpatched glibc, you've maybe just encountered an app that WINE simply won' run.
*sob*
I am actually Considering The Unthinkable at this point.
You could, you know, ask the SoundWeb guys to open-source their application.
*falls off chair laughing*
Before you try the unthinkable, and since you're going to have to build a box either way, try throwing together a Red Hat 7.3 box and running WINE on that. Or at least a lesser-patched 8.0. I've had a surprising amount of stuff work under WINE; things like Lotus Notes, which runs poorly on Windows to begin with anyway.
Even if they open its source, all you have is a bunch of code that only compiles in Windows with Microsoft's tools.
Well, if you did the Unthinkable, on Somebody Else's laptop, and patched in a protocol analyzer, you might figure out enough... (The Soundweb is controlled through a serial connection, right?) >:-)
Yeah, but it's hellaciously complicated -- there's quite a lot of UI. It's basically an interface builder that compiles down to code that runs on the DSPs. Writing a minimally-useful Soundweb UI would be a massive undertaking even with a protocol specification.
*laugh* Dear God, that thing's even more complex than I had thought! I figured it just sent some EQ, filter, and fader parameter values. Compiled DSP code... well, I guess your life is a bit busy, that might not be such an attractive reverse-engineering gig.
A company named Transgaming sells a commercial edition of WINE called WineX, mostly directed at playing DirectX games (rant about console systems vs. overhead of maintinence of a Microsoft operating system removed). You don't buy the software directly, but rather purchase a quarterly membership to have access to their downloads area. However, they have a public CVS repo, and although they claim to leave out certain DLLs, I have had extremely good luck getting various games and sound applications to run flawlessly. In addition, once you have the source, many things can be fixed using trivial patches, usually consisting of forcing certain "syscalls" to return constant enums. The idea here being to get the single program working, not generate a coherent emulation of the win32 behavior or something you could submit back to the project.
Then again, at a certain point it just becomes more pragmatic to just do X on Win98SE, or not do X at all.
Try it under winex. In my case, Street Atlas 98 wouldn't work under wine, but did just fine under winex. However, SA2003 still won't work.