All the news that fits, we print.
This week, 106 posts consumed 262 K. There were 52 different contributors. 21 (40%) posted more than once. 19 (36%) posted last week too. The top 5 posters of the week were:
|
Jobs around Wine (cont'd) | 30 Jun 2000 00:00:00 -0800 | Archive |
---|---|---|
In <kcref></kcref>, Doug Ridgway proposed three
items to be worked upon inside the Wine community:
|
A visual configuration tool for Wine | 10 Jul 2000 00:00:00 -0800 | Archive |
---|---|---|
Martin Pilka (from CodeWeavers) made the following proposal:
I'm working on graphical front-end for wine.conf
file. the goal is to provide useful tool for both newbie and linux-guru. It
will be something like wizard you know from windows, but it will also accept
the command line, which allows you to directly jump into something like
advanced section, where can you edit everything.
Following is the VERY PRELIMINARY draft, what should single screens
contains. your boggles are welcomed.
|
Kernel security path | 11 Jul 2000 00:00:00 -0800 | Archive |
---|---|---|
Gérard posted some follow-up of a debugging discussion he had on
comp.emulators.ms-windows.wine
(Title was 'Wine with ASS won't run
stripped binaries').
A kernel security patch changed the mapping of a program when loaded
into memory. This had some dramatic effects on Wine, since this
changed the memory layout of modules. Since some modules (without
relocation records) must be loaded at their default address, already
having some stuff mapped at this address broke the whole loader.
Since this patch is an unofficial one, Gérard asked:
|
Borland's developer conference report | 14 Jul 2000 00:00:00 -0800 | Archive |
---|---|---|
Jim Graham (CodeWeavers' CTO) gave a long report of his trip to BorCon: I was at BorCon for CodeWeavers. I hosted the BOF on "Using Wine to Port Application Software to Linux" and also gave a talk on "Porting Windows Application Software To Linux" (which really covered all of the tools, technologies, and techniques). I also worked in the booth all day Tuesday and Wednesday. CodeWeavers also had a BOF on porting Delphi code to Linux using Wine, but I missed that one, so can't talk about how it did. Overall impression: good show, lot's of interest and enthusiasm in both Linux and Wine. The BOF The BOF was surprisingly well attended, especially since it started at 7:00am on the last day of the conference. We had about 30 people in all, mostly windows application developers using C/C++ & Delphi. I spent about 30 minutes simply talking about what Wine is, what it does, it's history, and status. It turned out to be a great forum for educating the audience about Wine, since many of them were highly pessimistic about it (complaints about it not being able to run Word or Excel are all too common - argh). Most of the questions that came in related to winelib, which I was glad to talk about (beats having to discuss why Quicken won't work!). Most of the audience had never heard of it, and even those that had misunderstood its purpose. The only complaints that came in were in regard to it not being perfect (duh) and the "poor" documentation. Other than that, it was really well received. I really blew them away at the end when I showed them MS PowerPoint2000 running on Wine (thanks to all of you!). They were also excited about the future of Wine. In fact, when I discussed the objectives/goals of Wine 1.0, it generated a lot of discussion, and certainly a lot of enthusiasm. What surprised me though, is that the 1.0 discussion was not about "cool, it'll work with all of my windows apps," but instead, "cool, it'll work well with some of my windows apps," and "cool, it will be better documented and easier to install/configure." The Talk The talk focused on tools and technologies that are available for deploying windows software on linux. I covered everything from VMware to (what I call) "pure porting" (using Xlib/Xaw/Xm/libc, etc.). I focused on teaching the differences between the technologies, and showing what's good and bad about each. I emphasized Wine and winelib quite a bit, but again had to educate the audience about what it is. I think most of the audience agreed that, even if it's not your final solution, using winelib to get to Linux was the best starting point. The Exhibits According to some of the other exhibitors, this year's exhibit floor was the biggest one yet. Personally, I thought it looked small. It certainly wasn't LinuxWorld. Heck, it wasn't even as big as The Bazaar. But it was intimate, and we were able to meet a lot of great people. We were also able to talk to quite a few people for a longer period of time, which was a nice change. Traffic through the booth was near zero during the day (while sessions were running), but during lunch, and after the sessions ended, it was always busy. Again, a lot of interest in moving to Linux. I think the Borland development community is suddenly taking Linux very seriously, and as Kylix becomes available, we'll start to see more and more interest (at least from the business world). That interest will drive additional enthusiasm, and Wine is becoming an obvious consideration for everyone from users to developers and ISV's. That's about it for now. Feel free to ping me if you need/want more details. I'll be posting the talk on www.codeweavers.com, and for anyone that was at the show, it'll be on the post-conference CD. |
Wine benchmarks | 16 Jul 2000 00:00:00 -0800 | Archive |
---|---|---|
Ove Kåven forwarded a note from Thomas Elger which shed some lights on
Wine performances (compared to Windows):
I have a computer program GAUSS for Windows NT/95, Version
3.2.32. Aptech does provide a Linux version of the program, but they
charge for a completely new license. It is a highly advanced
statistical package used by many econometricians and mathematical
statisticians. I was very pleased to find that the NT version works
flawlessly
on Linux using WINE. I found a benchmark program for the
program on
http://gurukul.ucc.american.edu/econ/gaussres/GAUSSIDX.HTM
.
On the site, there is an extensive list of test results using various
operating systems and computers. The author states in the benchmark
program that it belongs to the public domain and can be used freely.
My test results were as follows (On an Intel PII 400, 128n Mb RAM,
Mandrake Linux 6.0 using the WINE distributed with Corel Photo paint
(since it is nicely preconfigured with printing etc)):
GAUSS - Benchmarkprogram
300x300 normal distributed random matrix^1000 : 1.837 sec.
These results are truly amazing. Running Gauss under WINE on Linux is
just as fast as running gauss natively under NT 4.0 (or faster) !!! On
the site referred above, a Dell Pentium II computer with 128 Mb RAM
gets an overall performance of 32.484.
A screenshot of Gauss running the benchmark is available on:
http://www.nek.lu.se/nektel/
If you have comparisons like this one, feel free to submit them to the editorial team
. If there is enough material,
we'll build a page containing all those good (and bad ?) figures.
|
Feature: Replacing Windows by Ove Kåven | |||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The last poll showed that people are interested in obviating the need
for having a real MS Windows installed to run Windows applications.
I will now attempt to explain Wine's strategy towards this end.
<h3>Installation Overview</h3>
A Windows installation consists of many different parts.
[Drive C] Path=/var/wine Type=hd Label=MS-DOS Filesystem=win95With this configuration, what windows apps think of as "c:\windows\system" would map to /var/wine/windows/system in the Unix filesystem. Note that you need to specify "Filesystem=win95", NOT "Filesystem=unix", to make Wine simulate a Windows-compatible (case-insensitive) filesystem, otherwise most apps won't work. <h3>System DLLs</h3> The Wine team has determined that it is necessary to create fake DLL files to trick many applications that check for file existence to determine whether a particular feature (such as Winsock and its TCP/IP networking) is available. If this is a problem for you, you can create empty files in the "system" directory to make the application think it's there, and Wine's built-in DLL will be loaded when the application actually asks for it. (Unfortunately, tools/wineinstall does not create such empty files itself.) Applications sometimes also try to inspect the version resources from the physical files (for example, to determine the DirectX version). Empty files will not do in this case, it is rather necessary to install files with complete version resources. This problem is currently being worked on. In the meantime, you may still need to grab some real DLL files to fool these apps with. And there are of course DLLs that wine does not currently implement very well (or at all). If you do not have a real Windows you can steal necessary DLLs from, you can always get some from a DLL archive such as http://www.dll-files.com/dllindex/index.shtml . |
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.