Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||12 Jul 2003 - 18 Jul 2003||(2 posts)||News: Interview with Jukka Heinonen|
|2.||15 Jul 2003 - 16 Jul 2003||(2 posts)||MacOS X Success|
|3.||15 Jul 2003 - 16 Jul 2003||(5 posts)||Running Commandline Apps|
|4.||15 Jul 2003 - 16 Jul 2003||(3 posts)||Winegcc and Shared Libraries|
|5.||12 Jul 2003 - 13 Jul 2003||(2 posts)||API Tracking|
|6.||16 Jul 2003 - 17 Jul 2003||(2 posts)||Internet Explorer Trivia|
|7.||16 Jul 2003||(1 post)||CAB Update|
This is the 179th release of the weekly Wine Weekly News publication. It's main goal is to ponder why I never knew I there was a real gold mine down the street from where I live. It also serves inform you of what's going on around Wine. You can find more info at www.winehq.com
Mailing List Stats For This Week
We looked at 198 posts in 649K.
There were 64 different contributors. 35 posted more than once. 31 posted last week too.
The top posters of the week were:
1. News: Interview with Jukka Heinonen
12 Jul 2003 - 18 Jul 2003 (2 posts) Archive Link: "News"
People: , NewsForge, News
We don't just report the news.. we create it. Jukka Heinonen answered some questions about the work he's doing. Check out his interview on WineHQ.
NewsForge published an article about another Linux convert. It briefly mentions Wine as a way to run Kazaalite.
2. MacOS X Success
15 Jul 2003 - 16 Jul 2003 (2 posts) Archive Link: "Good News : WineMine Works on Mac OS X :)"
People: Pierre d'Herbemont,
Pierre d'Herbemont has spent a lot of time getting Wine to run on MacOS X. Along the way he's gotten his hands wet in assembly language and had to rework a bunch of patches. It seems his work has paid off:
I have some good news. I am able to play with WineMine on Mac OS X :) See the screenshot here:
But comctl32 is not working and probably some others dlls, so I still have some work, but this is a good step.
PS : I would like to know if the color of winemine are the colors which are supposed to be, thanks.
This is a pretty interesting development for many reasons. First, Wine has only had marginal portability. Most developers use Linux day in and day out. Some folks have worked on Solaris x86 and FreeBSD. Others have worked on Linux ported to other architectures. Now we have it running on a non-x86 processor on a non-Linux platform. Not just any platform, but one that has widespread adoption. It seems a lot of work remains to be done, but in theory a lot of Windows-specific programs could be recompiled with Winelib to run on MacOS X.
Yes Pierre, winemine is that ugly.
3. Running Commandline Apps
15 Jul 2003 - 16 Jul 2003 (5 posts) Archive Link: "Once again: Wine without X?"
People: Dan Kegel, Kelly Leahy, Eric Pouech, , Microsoft
As Dan Kegel points out below, running non-GUI executables is something Wine should do easily:
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.
$ 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
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
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".
Kelly Leahy asked, " This may be a stupid question, but aren't you supposed to use 'wineconsole' for wine console apps?"
Dan explained that wineconsole was overkill:
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.
Eric Pouech shed a little more light on what the program may be doing, " drivers are loaded for USER, not GDI. So the first question is where does ss.exe pull USER32.DLL from ?" As far as the recommended way of running commandline apps, Eric said it should be as easy as, " wine pgm.exe if pgm.exe doesn't depend on user & gdi (but that's not your case)."
4. Winegcc and Shared Libraries
15 Jul 2003 - 16 Jul 2003 (3 posts) Archive Link: "winegcc and dlls"
People: Jonathon Wilson, Dimitrie Paun,
Jonathon Wilson asked about winegcc:
Dimi Paun has done the majority of the work on this. Coincidentally he just got back from a long vacation. He explained a bit about winegcc:
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:
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.
5. API Tracking
12 Jul 2003 - 13 Jul 2003 (2 posts) Archive Link: "API tracking and documentation"
People: Steven Edwards, Alexandre Julliard, , ReactOS
Steven Edwards proposed a change to help document Wine's status:
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
Alexandre shot down the idea and provided an alternative, " I don't think we want to clutter up the source code with this kind of thing. We already have a status page on winehq.com, and while the percentages are still very approximative, at least they have some meaning. Doing statistics on the number of implemented/unimplemented functions is useless, it doesn't give any information about how well the dll will behave in real use. But if you really want to do that it should be easy to maintain a list of functions in a separate file; or you can simply grep for 'stub' in the spec files. "
6. Internet Explorer Trivia
16 Jul 2003 - 17 Jul 2003 (2 posts) Archive Link: "Internet Explorer related trivia"
Topics: Microsoft Windows
People: Mike Hearn, Francois Gouget, , Microsoft
Mike Hearn shared an interesting statistic on wine-devel:
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:
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.
Time is money and $1,250,000,000 can buy a lot of it. Of course, most of that money probably wasn't spent on engineers writing code and probably takes into account all sorts of orthogonal things like marketing. Francois Gouget pointed that out:
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.
7. CAB Update
16 Jul 2003 (1 post) Archive Link: "AAAUUGH!"
Topics: Status Updates
People: Greg Turner,
Greg Turner wrote in with a very eloquently worded status update about his CAB work, which right now seems focused on making split CABs work. Such updates are rare in the Wine community and it needs to be preserved for historical reasons:
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.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.