Wine Traffic #179 For 18 Jul 2003

I have some good news. I am able to play with WineMine on Mac OS X :) See the screenshot here:

http://stegefin.free.fr/WineMine.jpg

But comctl32 is not working and probably some others dlls, so I still have some work, but this is a good step.

Cheers,

Pierre

PS : I would like to know if the color of winemine are the colors which are supposed to be, thanks.

OK folks, it's time for my semiannual "I need Wine to run a commandline program, but can't get it to work" rant.

First try: just do a default installation of wine-20030709.

Log:

$ wine -- /dos/d/vss/win32/ss.exe
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
x11drv: Can't open display:
$ echo $DISPLAY
$

That should have worked, since ss.exe doesn't use any GDI functions.

Moving right along, now let's try the tty driver. I added "GraphicsDriver" = "ttydrv"

dank_at_dank:~$ wine /dos/d/vss/win32/ss.exe
dank_at_dank:~$

It blipped the display to a second screen, then when the program exited, the screen blipped back so I couldn't read what it said. That's pretty useless. In fact, this is exactly the behavior complained about in bug 1358 ( http://bugs.winehq.com/show_bug.cgi?id=1358 ) subtitled "GraphicsDriver" = "none" wanted.

On the off chance that a "none" driver had been implemented, I tried it. And suprisingly, something sensible happened:

dank_at_dank:~$ wine /dos/d/vss/win32/ss.exe help
Could not load graphics driver 'none'
fixme:console:SetConsoleCtrlHandler (0x449460,1) - no error checking or testing yet
Username:

It actually seemed to work, once past the warning! I haven't tested it beyond the password prompt yet, but that was pretty convincing.

Is this the recommended way to run console wine programs without any $&?@!\% curses stuff kicking in and without X? And is there a chance of setting this behavior on a program-by-program basis? AppDefaults appears to be keyed off the driver already, so is probably not able to say "these apps should not use x11drv or ttydrv".

Doesn't help. I tried it. It still does that horrid ncurses stuff, and setting ttydrv to 'none' doesn't help. It looks like wineconsole is only useful for non-filters. It might be fine for, say, a win32 implementation of vi, but not for one of ls.

Ideally, one should be able to use Windows commandline tools that don't try to position the cursor as normal Unix commandline tools. The commandline client for Microsoft Source Safe is a perfect example. The unix user doesn't want to know he's using Wine; he wants to be able to say 'ss get foo.c' and grab the latest foo.c from sourcesafe. (This requires having a little shell script or alias to translate ss into wine ss.exe, but that's easy.)

I've used Wine for over a year like this, and it really helped integrate Linux into the Windows network where I work. It was hard to set up, so periodically I try setting it up from scratch without any tricks to see if it's gotten easier (or harder!) in the meantime.

1. is anyone working on making winegcc do dlls?
2. what is the "hard part" about making winegcc do dlls?
3. is there something I can do (code-hacking wise) to help with winegcc dll support?

It's not rocket science, it's just that we should try (hard) to make winegcc behave (as much as possible) as mingw-gcc.

Help would be appreciated, as it seems this little thing holds up a lot of other stuff.

What we need to do is support -shared. The dllwrap/dlltool stuff from binutil has been deprecated for the more standard -shared flag to gcc.

So, what we need is:

• recognize the -shared flag in winegcc, and forward to winewrap (easy)
• instrument winewrap to do the winebuild invokation and all the other crap that is done in the Makefiles (not hard, we just need to study the Makefiles for the proper way to build a DLL in Wine).

Ideally, we should end up with the same way of building a DLL in Wine as in Mingw. Unfortunately, I don't think that's feasible 100% now. The problem is that mingw-gcc supports __declspec(dllexport) and __declspec(dllimport) which allows it to build the DLL without a .def file. The Unix gcc does not support these, so we will need a .def file for the time being. Not a big problem for now, we can worry about it later.

The ReactOS project is interested in making a change to WINE the function commented that would make API tracking a little nicer. We have implemented a web page like the mono project has that shows the implemented and unimplemented functions in the API. Will the WINE project accept patches to the comments to support this type of tracking system? It would be nice because you guys could implement the same thing on your website. If the answer is no it is REALLY going to be a PITA for us to diff our sources to yours for every function.

Please take a momenet to look at the site and how it works. http://reactos.wox.org/index.php?page=apistatus

As we might end up cloning large parts of the Internet Explorer infrastructure someday, it's worth knowing roughly how much Microsoft invested/lost on it:

$1.25 billion dollars

This is according to Robert Scoble, who is an "evangelist" for Longhorn/Windows, so I expect it's mostly accurate.

The figure sounds somewhat stupid, a pinky-to-the-mouth Dr. Evil moment. If you consider a large team of programmers working on the product for many years however, it becomes quite believable. Consider that IE encompasses not only MSHTML, but also things like MLANG, shell integration, ActiveX, probably elements of WSH and so on.

Bah. I'm sure it's peanuts compared to what Microsoft invested in and earned from the sale of the various versions of Microsoft Windows that Wine replaces.

And I would say that Wine is starting to score points on that front (even if there is still a lot of work). So it's not like such a statistic should deter or discourage us from doing whatever we feel is necessary.

I swear, fdi.c is the worst code I ever wrote, period.

It's just an absolute graveyard of abandoned code-paths and unused variables... it's downright embarassing... and of course all the stuff I carelessly brushed over is coming back to haunt me for split cabs... it doesn't help that this is really boring stuff, absolutely no real challenge to keep it interesting except the pure tediousness of it... Stuart Caie did all the real work already, of course, this is just some kind of insane-asylum housekeeping chore...

Seriously, why are you people letting me infect your beautiful non-emulator with such crap? You should have taken me out to the abandoned nether regions of the code mines and shot me several patches ago ;)

I'm really tempted to just pitch the whole mess and start over. I should have been editing cabextract.c all along, instead of employing this cut-and-paste bloatware approach... Bet I'd be done by now, if I'd just maintained some pretense of orthogonality.

Well, in such situations I am at least stubborn, if not effective. Either I will beat the infestation into remission, or I will fix it the hard (and right) way. Be advised, however, that previous "I'm really, really almost done this time" predictions may have been overly optimistic.