WWN: wn20030718_179.xml

Thu Jul 17 18:24:54 CDT 2003

wn20030718_179.xml

-brian
-------------- next part --------------
<?xml version="1.0" ?>
<kc>

<title>Wine Traffic</title>

<author contact="http://www.theshell.com/~vinn">Brian Vincent</author>
<issue num="179" date="07/18/2003" />
<intro> 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 <a href="http://www.winehq.com">www.winehq.com</a> </intro>
<stats posts="198" size="649" contrib="64" multiples="35" lastweek="31">

<person posts="20" size="60" who="Mike Hearn" />
<person posts="18" size="52" who="Dmitry Timoshkov" />
<person posts="13" size="29" who="Eric Pouech" />
<person posts="12" size="73" who="dd jj" />
<person posts="12" size="29" who="Vincent Beron" />
<person posts="9" size="45" who="Pierre d'Herbemont" />
<person posts="6" size="13" who="Jonathan Wilson" />
<person posts="6" size="13" who="BiGgUn" />
<person posts="5" size="28" who="Sylvain Petreolle" />
<person posts="5" size="25" who="Roderick Colenbrander" />
<person posts="7" size="21" who="Dimitrie O. Paun" />
<person posts="4" size="44" who="Marcelo Duarte" />
<person posts="4" size="13" who="Shachar Shemesh" />
<person posts="4" size="7" who="Lionel Ulmer" />
<person posts="3" size="14" who="Ove Kaaven" />
<person posts="3" size="8" who="Gregory M. Turner" />
<person posts="3" size="7" who="Steven Edwards" />
<person posts="3" size="7" who="Alexandre Julliard" />
<person posts="3" size="7" who="Jon Bright" />
<person posts="3" size="6" who="Tom" />
<person posts="2" size="8" who="Dimitrie O. Paun" />
<person posts="2" size="7" who="Robert Shearman" />
<person posts="2" size="6" who="Bill Medland" />
<person posts="2" size="6" who="Dan Kegel" />
<person posts="2" size="5" who="Fabian Cenedese" />
<person posts="2" size="5" who="Uwe Bonnes" />
<person posts="2" size="5" who="Jon Griffiths" />
<person posts="2" size="4" who="Lars Segerlund" />
<person posts="2" size="4" who="Marcus Meissner" />
<person posts="2" size="4" who="Stephan BEUZE" />
<person posts="2" size="4" who="Mike McCormack" />
<person posts="2" size="4" who="Michael Jackson" />
<person posts="2" size="4" who="Dustin Navea" />
<person posts="2" size="3" who="Evalet Olivier" />
<person posts="1" size="4" who="Rok Mandeljc" />
<person posts="1" size="4" who="Paul Rupe" />
<person posts="1" size="3" who="Rein Klazes" />
<person posts="1" size="3" who="Michael Gunnewig" />
<person posts="1" size="2" who="Maxime Bellenge" />
<person posts="1" size="2" who="Jeff Smith" />
<person posts="1" size="2" who="Stefan Jones" />
<person posts="1" size="2" who="Raphael Junqueira" />
<person posts="1" size="2" who="Troy Rollo" />
<person posts="1" size="2" who="Robin Connelly" />
<person posts="1" size="2" who="David Laight" />
<person posts="1" size="2" who="(mark)" />
<person posts="1" size="2" who="(martin-fuchs)" />
<person posts="1" size="2" who="Marcus Brubaker" />
<person posts="1" size="2" who="Todd Vierling" />
<person posts="1" size="2" who="Marcus Meissner" />
<person posts="1" size="2" who="Francois Gouget" />
<person posts="1" size="2" who="(amdxp&lt;amdxp)" />
<person posts="1" size="2" who="Rolf Kalbermatter" />
<person posts="1" size="2" who="Brian Vincent" />
<person posts="1" size="2" who="Gerald Pfeifer" />
<person posts="1" size="2" who="Vitaliy Margolen" />
<person posts="1" size="2" who="Kelly Leahy" />
<person posts="1" size="1" who="Mark Easton" />
<person posts="1" size="1" who="William M. Quarles" />
<person posts="1" size="1" who="Johan Gill" />
<person posts="1" size="1" who="olivier" />
<person posts="1" size="1" who="Saulius Krasuckas" />

</stats>
<section 
	title="News: Interview with Jukka Heinonen"
	subject="News"
	archive="http://www.winehq.com/?interview=9" 
	posts="2"
	startdate="07/12/2003"
	enddate="07/18/2003"
>
<topic>News</topic>
<p>We don't just report the news.. we create it.  Jukka Heinonen 
answered some questions about the work he's doing.  Check out
<a href="http://www.winehq.com/?interview=9">his interview</a>
on WineHQ.</p>

<p>NewsForge published an article about another
<a href="http://newsforge.com/newsforge/03/07/09/1934259.shtml?tid=23">Linux
convert</a>.  It briefly mentions Wine as a way to run Kazaalite.
</p>
</section><section 
	title="MacOS X Success" 
	subject="Good News : WineMine Works on Mac OS X :)"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/07/0326.html" 
	posts="2"
	startdate="07/15/2003"
	enddate="07//2003"
>
<topic>Ports</topic>
<p>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:</p>
<quote who="Pierre d'Herbemont"><p>
I have some good news. I am able to play with WineMine on Mac OS X :)
See the screenshot here:
<ul><a href="http://stegefin.free.fr/WineMine.jpg">http://stegefin.free.fr/WineMine.jpg</a>
</ul></p><p>
But comctl32 is not working and probably some others dlls, so I still 
have some work, but this is a good step.
</p><p>
Cheers,
</p><p>
Pierre</p><p>

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

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.

<p>Yes Pierre, winemine is that ugly.</p>
</section><section 
	title="Running Commandline Apps" 
	subject="Once again: Wine without X?"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/07/0332.html" 
	posts="5"
	startdate="07/15/2003"
	enddate="07/16/2003"
>
<topic>Configuration</topic>
<p>As Dan Kegel points out below, running non-GUI executables
is something Wine should do easily:</p>
<quote who="Dan Kegel"><p>

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:
<ul><code>
$ 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 
$
</code></ul>
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"
<ul><code>
dank_at_dank:~$ wine /dos/d/vss/win32/ss.exe 
dank_at_dank:~$
</code></ul>
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
( <a href="http://bugs.winehq.com/show_bug.cgi?id=1358">http://bugs.winehq.com/show_bug.cgi?id=1358</a> )
subtitled "GraphicsDriver" = "none" wanted.

On the off chance that a "none" driver had been implemented, I tried it.
And suprisingly, something sensible happened:
<ul><code>
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:
</code></ul>
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 $&amp;?@!\% 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".
</quote>

<p>Kelly Leahy asked,
<quote who="Kelly Leahy">
 This may be a stupid question, but aren't you supposed to use 'wineconsole'
 for wine console apps?</quote></p>

Dan explained that wineconsole was overkill:
<quote who="Dan Kegel">
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.
</quote>

Eric Pouech shed a little more light on what the program may be
doing, <quote who="Eric Pouech">
 drivers are loaded for USER, not GDI. So the first question is where 
 does ss.exe pull USER32.DLL from ?</quote> As far as the recommended
way of running commandline apps, Eric said it should be as easy as,
<quote who="Eric Pouech">
 <tt>wine pgm.exe</tt> if pgm.exe doesn't depend on user &amp; gdi (but that's not 
 your case).</quote>

</section><section 
	title="Winegcc and Shared Libraries" 
	subject="winegcc and dlls"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/07/0329.html" 
	posts="3"
	startdate="07/15/2003"
	enddate="07/16/2003"
>
<topic>Utilities</topic>
<p>Jonathon Wilson asked about winegcc:</p>
<quote who="Jonathon Wilson">
<p><ol>
<li>is anyone working on making winegcc do dlls?</li>
<li>what is the "hard part" about making winegcc do dlls?</li>
<li>is there something I can do (code-hacking wise) to help with winegcc 
dll support?</li>
</ol></p></quote>

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:
<quote who="Dimitrie Paun">

It's not rocket science, it's just that we should try (hard)
to make winegcc behave (as much as possible) as mingw-gcc.
</p><p>
Help would be appreciated, as it seems this little thing holds
up a lot of other stuff.
</p><p>
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.
</p><p>
So, what we need is:
<ul>
    <li> recognize the -shared flag in winegcc, and forward to 
       winewrap (easy)</li>
    <li> 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).</li>
</ul></p><p>
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.
</p></quote>

</section><section 
	title="API Tracking" 
	subject="API tracking and documentation"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/07/0242.html" 
	posts="2"
	startdate="07/12/2003"
	enddate="07/13/2003"
>
<topic>Documentation</topic>
<p>Steven Edwards proposed a change to help document Wine's
status:</p>
<quote who="Steven Edwards"><p>
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.
</p><p>
Please take a momenet to look at the site and how it works.
<a href="http://reactos.wox.org/index.php?page=apistatus">http://reactos.wox.org/index.php?page=apistatus</a>
</p></quote>

Alexandre shot down the idea and provided an alternative,
<quote who="Alexandre Julliard">
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.
</quote>

</section><section 
	title="Internet Explorer Trivia" 
	subject="Internet Explorer related trivia"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/07/0358.html" 
	posts="2"
	startdate="07/16/2003"
	enddate="07/17/2003"
>
<topic>Microsoft Windows</topic>
<p>Mike Hearn shared an interesting statistic on wine-devel:</p>
<quote who="Mike Hearn"><p>
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:
<ul>
   $1.25 billion dollars
</ul></p><p>
This is according to Robert Scoble, who is an "evangelist" for
Longhorn/Windows, so I expect it's mostly accurate.
</p><p>
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. 
</p></quote>

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:
<quote who="Francois Gouget">
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.
</quote>

</section><section 
	title="CAB Update" 
	subject="AAAUUGH!"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/07/0366.html" 
	posts="1"
	startdate="07/16/2003"
>
<topic>Status Updates</topic>
<p>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:</p>
<quote who="Greg Turner"><p>
I swear, fdi.c is the worst code I ever wrote, period.
</p><p>
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...
</p><p>
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 ;)
</p><p>
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.
</p><p>
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.
</p></quote>

</section></kc>