All the news that fits, we print.
This is the 158th release of the Wine's kernel cousin publication. Its main goal is to steal your lunch money and donate it to the Wine developers. It also serves to inform you of what's going on around Wine (the Un*x Windows emulator).
|
This week, 211 posts consumed 632 K. There were 59 different contributors. 31 (52%) posted more than once. 33 (55%) posted last week too. The top 5 posters of the week were:
|
| News: Wine-20030219, TransGaming Update, WineX Game Manager | 02/15/2003 | Archive |
|---|---|---|
|
News
Ah yes.. that time of the month - time to uncork a new vintage: WHAT'S NEW with Wine-20030219: (see ChangeLog for details) TransGaming announced an update for the Kohan series with the following notes:
TransGaming also issued their February Development Status . They're in the midst of a big push for WineX 3.0. Development continued on both improved DCOM support (for InstallShield installers) and Direct3D. The results from January's poll of subscribers requested support for these games:
Also related is a new WineX Game Manager that you can find over at Frank's Corner: Installling a Windows game using WineX must always be done from the command line. Often playing the game must also be done from the command line. WineX Game Manager makes this all a little easier, beacause it's got a graphical interface for installing and playing Windows games. If you use the .transgaming directory for games it can happen that the registry gets messed up and you have to reinstall everything all over again. In WineX Game Manager each game gets its own registry and own configuration file and will be installed in a subdirectory of /usr/local/games. DesktopLinux.com interviewed Jim Curtain , CEO of the company that makes Win4Lin. He discusses migrating desktops to Linux and the problems associated with it. He briefly mentions Wine. | ||
| TaxCut 2002 | 02/15/2003 | Archive |
|---|---|---|
|
Fixes
Taxes.. I don't care where you live, they suck. For those of us living in the United States we have until April 15th to pay our 2002 taxes. And of course the tax code is so obscure that unless you're single, poor, and don't own anything chances are you're going to get screwed. That's where tax software comes into play. With a little luck you can complete the tax forms with a matter of a few months. In the past I've always used Intuit's TurboTax product. This year with the advent of their new licensing scheme , not to mention the recent revelations of low-level disk manipulation, I decided to try something different. (Chances are I could have easily used the new "Save as PDF" option, but that's besides the point.) I went out and bought H & R Block's TaxCut. Supposedly it imports from last year's TurboTax just fine. The little piece of software is sitting in the trunk of my car waiting to be opened. That's why I was excited to see Ori Pessach's post: TaxCut seems to work almost perfectly with a native msvcrt.dll, and a copy of Comic.TTF in Windows/Fonts, by the way. The update feature fails, but everything else I've tried so far seems to work as expected - I haven't completed a return yet, though. Looking over the update page it has a link to a self-extracting archive that can be downloaded separately for the updates. Anyone else have any success with tax software? If you write a review of the software you used, any configuration options you had to try, etc I'll post it here. Also of interest would be stuff that doesn't work. | ||
| Why Develop MSVCRT.DLL? | 02/15/2003 | Archive |
|---|---|---|
|
In the discussion of running TaxCut, Ori asked:
Am I correct in assuming that a [ed. builtin
] msvcrt.dll is useful mostly to
people porting Windows applications to architectures other than x86?
Since the native msvcrt.dll works with Wine, and is a redistributable,
I'm not sure how useful a Wine implementation of it is going to be. Am I
missing something?
MSVCRT is the Microsoft Visual C++ Run Time library that's needed by most applications. Several people jumped in to give reasons of why it's important for Wine to have its own version. Dmitry Timoshkov pointed out that the entire goal of Wine is to implement the features necessary to ensure running on a system free of Microsoft code and for native Winelib applications. John Hohm explained recent changes with this DLL: It does come with recent Windows. However, many programs install an updated version of msvcrt.dll, since it is a redistributable for Microsoft Visual Studio 5 and 6. Visual Studio 7 has switched to msvcr70.dll et. al. As of Windows XP, msvcrt.dll is part of the operating system. It is now under system file protection, so it cannot be replaced by a normal application. Apparently as a tribute to this, they changed the description from "Microsoft (R) C Runtime Library" to "Windows NT CRT DLL". Some programs that don't depend on having fixes in a certain version of msvcrt.dll will depend on the version from Windows; this includes most programs developed with VC6 specifically for Windows XP, and all programs developed with recent versions of the MinGW Win32 port of GCC. Therefore, we really do need a complete msvcrt.dll in Wine. And Eric Pouech mentioned, latest EULA states that redistribution must occur on Windows based OSes, so it might not be legal on Wine/*nix combo | ||
| Problems with OpenGL | 02/17/2003 | Archive |
|---|---|---|
|
Graphics
David Hagood reported a problem with Direct3D: Ever since upgrading to RH8.0, I've been getting the following errors when building Wine - even with a fresh CVS pull:
device.o: In function `DrawPrimitiveI':
/usr/src/wine/dlls/d3d8/device.c:392: undefined reference to
`glMultiTexCoord2f'/
If I disable the build of the D3D system, Wine builds and runs. Uwe Bonnes suggested a simple solution, Often for such problems a "make distclean ", .configure , make depend and make sequence helps. David said he tried that, but it didn't help. Johan Dahlin recognized the problem, but wasn't exactly sure what caused it: I've seen the same here on my Red Hat 8.0 box. A workaround is to disable opengl by passing --without-opengl to configure. Lionel Ulmer asked for some version information on the OpenGL packages David was using. David mentioned he had not used RPM packages, but got his GL headers from CVS. After looking at it he diagnosed them as the real problem: Well, I think the problem comes from one of your OpenGL headers... Can you do a 'grep GL_VERSION_1_3' in your GL headers (mostly GL.h I think). >From what I suspect, you will get something like this :
#define GL_VERSION_1_3 1
The problem is that your OpenGL library is NOT implementing GL 1.3 (as shown in your glxinfo output). This means that you have a mismatch between your system headers and your library. This could be considered as a bug to report to the DRI people (if they really provide a gl.h which defines GL_VERSION_1_3, they should also provide a library with all OpenGL 1.3 entry points). We *could* fix this in Wine by adding yet another configure check (or going the full 'GetProcAddress' way which would be needed if we wanted a nice OpenGL packaged Wine) but well, sometimes enough is enough and stuff should be fixed outside of Wine and respecting the rules instead of adding yet another work-around. Marcus Meissner reported he had the same issue and explained his setup, I have the same problem, Mesasoft headers are used during compile, but the xf86glx libraries are installed. The former are 1.3, the latter not which leads to that problem. | ||
| Testing Petzold's Example Programs | 02/07/2003 | Archive |
|---|---|---|
|
Testing
A few weeks ago John Kopplin announced some work he had done: I have just completed 145 Gnu makefiles that allow the free MinGW (Gnu) Compiler to compile and execute all of the example programs which Charles Petzold describes in his "Programming Windows Fifth Edition" book, which is the standard reference book on Microsoft's WIN32 API. I freely distribute these 145 makefiles in a .ZIP file, along with an installation program that will copy them into Petzold's directory structure, from my web page at: Only 5 of the 145 programs require user intervention to compile with the Gnu compiler, which is not bad for porting that many programs to a new compiler, especially given Microsoft's lax adherence to standards. I would be very pleased if these makefiles would help with the development of the Wine emulator. At the time I didn't put it in the news, mostly because no one had commented on it. This week Dimi wanted to know if anyone tried it and what the results were: As you probably remember, John Kopplin was kind enough to modify his MinGW-inifcation scripts: to support Winelib out of the box. This is great news, only problem is that now someone should try to see how they work. :) I would give it a try, but I don't own Petzold's book. I should probably buy it, but this is another matter. BTW, is it worth buying the book? | ||
| Patch Manager | 02/14/2003 | Archive |
|---|---|---|
|
Project Management
Fabian Cenedese wondered if a patch management system was necessary, I read all the mails about how to submit patches. I saw on the wxWindows page that they have a Patch- Manager. Mainly just a form to enter all necessary data. Maybe something like that could be useful here too. http://sourceforge.net/tracker/?group_id=9863&atid=309863&func=add A few people wrote in to disagree, mainly because no one had a problem with the current system (i.e. sending patches to the wine-patches list). As Dimi put it, I personally don't like it much. wine-patches is just as good, and easier to use with standard tools (email). As long as Alexandre responds to rejects (and he usually does), I see no reason to change the status quo. Dan Kegel also pointed out a another project with a similar goal: See also Rusty's Trivial Patch Monkey, http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/ | ||
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.
