|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
Table Of Contents
| 1. | 2 Nov 2002 - 8 Nov 2002 | (4 posts) | News: Wine-20021031 and Commercial Devel |
| 2. | 7 Nov 2002 - 8 Nov 2002 | (19 posts) | Wine 0.9 To Do |
| 3. | 2 Nov 2002 - 3 Nov 2002 | (14 posts) | Testing Apps: Tucows' Top 20 Apps |
| 4. | 3 Nov 2002 - 5 Nov 2002 | (6 posts) | Testing Apps: Mozilla and Multimedia Players |
| 5. | 4 Nov 2002 - 5 Nov 2002 | (14 posts) | RPCSS.exe Replacement |
| 6. | 5 Nov 2002 | (8 posts) | Avoiding ASCII/Unicode Function Duplication |
| 7. | 6 Nov 2002 | (6 posts) | Thanks from Bob |
| 8. | 1 Nov 2002 | (1 post) | Author Needed for Winelib Article |
Introduction
This is the 143rd release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).
Mailing List Stats For This Week
We looked at 541 posts in 1596K.
There were 96 different contributors. 55 posted more than once. 53 posted last week too.
The top posters of the week were:
1. News: Wine-20021031 and Commercial Devel
2 Nov 2002 - 8 Nov 2002 (4 posts) Archive Link: "News"
Topics: News
People: Alexandre Julliard, CodeWeavers, , codeweavers, Xandros, News, TransGaming, Gavriel State
Oops. As I as doing last minute additions to last weeks' issue I missed announcing wine-20021031. Alexandre broke from his usual one month cycle and released this a mere 24 days since the last one. No doubt in part to the recent flurry of activity. From the announcement:
WHAT'S NEW with Wine-20021031: (see ChangeLog for details)
CodeWeavers released CrossOver Office 1.3.1 on Monday. This is basically a bugfix release as noted by the minor version number. Check out the release notes to find out what's new. One thing I found interesting was this note, " Warns user if they are about to run an executable attachment from the /tmp directory. This protects users against viruses such as KLEZ."
Gavriel State updated his column over at TransGaming. In it he discusses some of the more intangible aspects of selecting development work. Viktas Gupta also updated his column. In it he discusses he discusses how cool TransGaming is.
Xandros revamped their web site. Things seem a lot smoother than a few weeks ago. And if you order now you get free fedex shipping.
2. Wine 0.9 To Do
7 Nov 2002 - 8 Nov 2002 (19 posts) Archive Link: "Wine 0.9 TODO v0.2"
Topics: Project Management
People: Dimitrie Paun, Vincent Beron, , Huw Davies, Francois Gouget, Thomas Wickline, Marcus Meissner, Alexandre Julliard, Andreas Mohr, Gerald Pfeifer, Jeremy White, Bill Medland, Jeremy Newman, Shachar Shemesh, Dustin Navea, Carlos Lozano
Dimi Paun posted a link to the (official?) Wine 0.9 To Do list: http://www.dssd.ca/Wine-0.9-TODO.html. Most likely you'll find that page the most up to date, however I'll reproduce some of it below for reference. Dimi seems to be adding/updating/changing things on a daily basis as he gets more feedback.
I should also point out, if you've wanted to get involved with Wine this is an excellent opportunity. Many of the tasks don't require any coding ability. Wanna make some screenshots? Send them to me. Don't even worry about thumbnails or resolution, I can take care of that. (I'd prefer if they were in a compressed format though.) Other tasks, such as nailing down the default Wine configuration, provide an excellent chance at getting your feet wet with minimal knowledge of Wine or C needed.
Introduction
Before I start, a quick reminder for the 0.9 criteria:
What is not in 0.9:
Please review it, and let me know if:
Please send all comments, flames, and suggestions to Dimitrie O. Paun.
Resources
ChangeLog
TODO
A. WineHQ work
Beta available here
B. Documentation work
Wine configuration
Stabilize utilities
Important fixes
3. Testing Apps: Tucows' Top 20 Apps
2 Nov 2002 - 3 Nov 2002 (14 posts) Archive Link: "Today wine's compatibility with 20 popular apps from tucows"
Topics: Testing
People: Carlos Lozano, Carl Lozano, , Apple, Unknown
Carlos Lozano announced:
I have taken the 20 first entries of the top 100 tucows list, except that some entries has been removed, mainly antivirus and programs what need other different program to work. (URL: http://tucows.uam.es/toppicks.html)
Every application was tested with:
Results:
Total apps tested: 21 (*)
Applications:
A couple people wondered why bother testing many of the applications since there were clear Linux alternatives. Carl replied, " It is the same that when you are doing a videogame console emulator. You don't start testing the comercial games first, you start with simple demos, when you will get the basic working, then start with more complex one, and so. The important is not run this applications, the important is that sure that the authors of this applications have used features what are the base of other more complex. So if this features are working correctly, it will be easier run more complex software in the future :) "
4. Testing Apps: Mozilla and Multimedia Players
3 Nov 2002 - 5 Nov 2002 (6 posts) Archive Link: "Mozilla 1.0.1 Win32 works almost flawlessly"
Topics: Testing
People: Jakob Eriksson, Dimitrie Paun, , Max
Jakob Eriksson reported success running a Win32 version of Mozilla. His note was pretty short, " Works mostly fine. Resizing works, I think it didn't a couple of months ago."
In addition to the Tucows apps listed above, Dimi Paun decided to try out some multimedia apps and see how well they ran. He reported the following results:
5. RPCSS.exe Replacement
4 Nov 2002 - 5 Nov 2002 (14 posts) Archive Link: "RFC: rpcss skeleton prototype #2"
Topics: Status Updates
People: Greg Turner, Ove Kaaven,
Greg Turner has been working on a standalone equivalent to NT4/2000's rpcss.exe. That executable is responsble for lots of remote procedure call stuff, a lot of which still isn't fully understood. One functionality it provides is endpoint mapping. Distributed applications like SQL server and Exchange assign RPC services dynamically to TCP and UDP ports. The endpoint mapper is responsible for mapping the RPC services to their currently assigned ports. So when a client requires access to a service using RPC first it must request a port mapping. After that it can communicate directly with the service. Greg explained part of the problem with that:
There's a chicken-and-egg problem. We're trying to implement RPC, but, to do the full implementation, we're supposed to provide endpoint mapping API's, and these API's are, themselves, supposed to use RPC to accomplish their task... that puts us in a catch-22.
This is where the pipes hack comes into play; instead of implementing the endpoint mapping API's using RPC, like we're supposed to, I plan to use pipes to do the IPC between the endpoint mapper (rpcss) and the processes calling these API's.
This is what the unmerged server parts do, as well. Once the rest of the RPC implementation works, we'll be in a position to reimplement the endpoint mapping API's the right way (using RPC), and get rid of the pipes hack.
Greg set about building the app using named pipes for communication. His latest version, #2 added more functionality:
This one implements "pseudo-fork" behavior, a main workhorse loop, pseudo-debug log emitter, and command-line interpretation. In particular I'm looking for comments/criticism/flames/etc for:
Alexandre didn't think it was worth having the fork stuff in there since it would only be invoked from within Wine. Greg felt otherwise:
that's largely correct, except it should also support a "daemon" mode ("/s/index.html" command-line argument). For local RPC's, the "lazy" (from rpcrt4.dll) invocation method will be enough. But -- to be a "real," fully functional RPC server, we will need it running in "server" mode. Otherwise, networked RPC's, from without, will always fail, finding no endpoint mapper or name service to converse with at the local host.
This is why you will always find rpcss.exe running on W2K, even when nobody's logged in. Turn off the Remote Procedure Call service (rpcss), and your W2K host is basically dead, or, at best, incapable of networked communications, like domain browsing, mmc administration (even local), filesharing, etc.
So, to sum up my point... supporting some kind of daemon-like mode will become increasingly important as the implementation progresses, and at least marginally useful in the relatively near future (i.e., to test basic networked RPC's, I'll need this).
Alexandre still felt that the approach was wrong for now and the problem was best solved later. Ove pointed out another potential problem, " Note that to be a "real, fully functional RPC server", it would have to bind to a privileged port and such, providing all the DCE RPC daemon services that should live on that port. I'm not sure I would trust a complex Winelib app to run as root, listening on an open network port. It'd probably be much better to let the user run a real DCE RPC daemon (like freedce's) as root, and just have Wine's rpcss communicate with it as necessary to update this real daemon's registrations. Then several (Unix) users could run RPC services on the same host, too."
Greg kept working on it, saving some of that as things to worry about later.
6. Avoiding ASCII/Unicode Function Duplication
5 Nov 2002 (8 posts) Archive Link: "Avoiding FunctionA/W Duplication"
People: Jaco Greeff, Vincent Beron, Eric Pouech, Dimitrie Paun,
Jaco Greeff wanted some input on how to best avoid code duplication when implementing a function that had both an ASCII and Unicode version:
I would like some comments on somthing that has been bugging me quite a bit. Implementing parts of the API can lead to duplication of code inside the same file. In my example, let's take two functions, one operating on a ASCII string and one one a Unicode string, let's call them "funcA" and "funcW".
Upon implementation, the only real difference between these are the parameters, "funcA(const char *p)" and "funcW(const WCHAR *p)". What is the best way to keep the code maintainable and making sure that we don't have to fix a single bug in two places in the same file? I see 3 (maybe more) approaches:
What is the general feeling as to the right way to approach this? What is the preferred approach? (And maybe it is something I haven't listed here.)
Dimi Paun didn't like the macro idea at all. Vincent Beron suggested, " >From what I saw in a couple of places: from funcA, do some magic on the parameters (convert to Unicode), then call funcW, then reconvert the result from Unicode to ASCII. Yes you have to convert twice, but you use the same function."
Eric Pouech had another approach,
"
duplicating the code (in that case) is one solution
(in your example, you could use a shared function between A & W familly,
using as parameters
"
And Dimi Paun suggested yet another, " Implement the meat in a funcT that takes a boolean as an argument telling it if the input is A or W, and just have the func[AW] forward the call to funcT This works only within one module, and there are other problems. "
Alexandre really didn't like that though because of the casts required and the compiler not being able to do type checking.
7. Thanks from Bob
6 Nov 2002 (6 posts) Archive Link: "Forgive the intrusion"
Topics: Project Management
People: Bob Amstadt, Alexandre Julliard, , Thomas Wickline
If you've ever dug around through Wine docs you might have noticed references such as "..Wine was started in 1993 by Bob Amstadt.." And probably the next thing you'll notice is no other mention of his name in recent history. Bob's early involvement was crucial toward developing the goals of the project. Anyway, this message appeared on the list this week:
Please don't let me distract you from your important work, but Thomas Wickline asked me to stop in and say hello to all of you. I understand that we are approaching the 10 year anniversary of Wine. That is a remarkable feat. All of you should be proud to be contributing to this effort. It is an amazing piece of software.
Though many of the names I see on the WineHQ web site are new to me. I continue to see Alexandre Julliard's name on this work. I had the pleasure of meeting Alexandre many years ago and I am so glad to see that he continues the work after so many years. Alexandre, if you read this, thank you very much for all that you have done for free software.
Thank you to the rest of you as well. Wine has been a team effort from the start and is so successful because it is a team effort. When I stepped down from leading this project, I knew it would continue due to the efforts of all the people that have helped along the way. It not only has continued, but it clearly thrives. I'm amazed at the number of people that know what Wine is.
Congratulations to all of you Wine developers. You are amazing people.
Someone inquired further about the early days of Wine, and Bob explained, " As far as the very beginning, it started from a discussion on USENET. Some people said it couldn't be done which inspired me to begin writing a loader. Another person (unfortunately I don't remember who) started to do the same thing at the same time. I don't remember the details, but my work became the base system that everyone adopted. Eric Youngdale contributed a substantial amount of code in the early days. Someone else took the lead on developing the windowing code. I don't remember who. Was that you, Alexandre or did you join in after that?"
Alexandre said it was him, " Yes that was me. I remember the first patch I did was a hack to tie together the loader you had written with the tcl/tk menu stuff written by Peter MacDonald so that the menudemo program worked. After that I set out to implement GDI to replace tcl/tk..."
8. Author Needed for Winelib Article
1 Nov 2002 (1 post) Archive Link: "C/C++ Users Journal is looking for a WINE author"
Topics: Documentation
People: Joe Casad,
A request was posted to wine-devel for someone to write an article:
Is anyone interested in writing an article on the winelib development toolkit for the C/C++ Users Journal? This article would be a great way to bring some practical information about winelib to advanced C/C++ programmers who may not be familiar with it (plus you get paid).
We're looking for an article that will give some background on winelib and also provide a practical example of how to use winelib to port a Windows app to Linux. Our focus is on the code. We'd be looking for a very detailed description of how to use winelib in a specific, real-world situation.
Let me know if you, or someone you know, would be interested in helping us.
You can contact me at: jcasad -at- cmp.com
-Joe Casad
Editor-in-Chief
C/C++ Users Journal
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. |