Wine Traffic #23 For 29 Dec 1999

By Zack Brown

Table Of Contents

Introduction

Eric Pouech couldn't write KC Wine this week, so I've whipped something up.

Mailing List Stats For This Week

We looked at 57 posts in 201K.

There were 26 different contributors. posted more than once. 14 posted last week too.

The top posters of the week were:

1. New W2K APIs

22 Dec 1999 (1 post) Archive Link: "new W2K APIs"

People: Andreas Mohr, , Mark

Andreas Mohr gave a pointer to an article by Mark Russinovich on New Win2K Kernel APIs (http://www.numega.com/drivercentral/tech_tips/102199.stm) . Mark is famous for an article Linux And The Enterprise (http://www.winntmag.com/Articles/Content/5048_01.html) , which stirred up a big discussion on the linux-kernel mailing list, covered in Kernel Traffic #18, article 3 (http://kt.zork.net/kt19990513_18.html#3) .

2. Windows To Wine Makefile Converter

21 Dec 1999 - 22 Dec 1999 (2 posts) Archive Link: "Windows to Wine makefile converter?"

People: Francois Gouget, 

Francois Gouget recalled that some months ago, someone had said they were working on a tool to convert Windows/Visual C++ makefiles, into makefiles that would work with 'make' and 'wine'. He couldn't find the original message in the mailing list archives, and wanted to know the status. He explained,
I'm asking this because I'm trying to write some wrapper code so that one can take the sample programs from "Programming Windows 95" and compile them with Winelib. I currently use a script that will build correct makefiles for most of the 80 programs. But using a makefile converter may be more flexible. In particular, if I'm successful adapting the programs in this book I have two others to work on: "MFC Programming windows 95" and "Developping for Windows 95 and NT" (french titles approximately translated to english).

Todd Osborne replied that he'd also considered taking on such a project, as part of porting VWCL to WINElib, and volunteered to help any such effort.

End Of Thread.

3. 16- Vs 32-Bit mmioinfo Fixes

22 Dec 1999 (1 post) Archive Link: "16 vs 32 bit mmioinfo fixes"

People: , Eric Pouech

Bradley Baetz announced that he and Eric Pouech, over the course of a few weeks, patched up the mmio functions to work with 32 bit custom mmio io procedures. He posted their patches, adding that there were still some unresolved issues. For one, pointer conversion problems had forced them to keep the 16-bit version of the internal lpmmioinfo structure. Another issue was that the patch did not distinguish between local and global procedures. They had also had trouble identifying the WAVEFORM mci type, as it didn't appear in either the Win95 or Win98 registries.

4. GCC problems

22 Dec 1999 (7 posts) Archive Link: "gcc woes"

People: , Eric Pouech, Patrik Stridvall, Peter Hunnisett

Eric Pouech had finally tracked an elusive bug to the compiler. Using gcc 2.91 would cause the Wine binary to set a window's y-position to 0, whenever the window was moved. Switching to the 2.95.1 compiler cleared the problem right up. He added that he had a workaround for the 2.91 problem, but wasn't sure whether to submit it because he didn't like circumventing compiler bugs.

Peter Hunnisett asked for confirmation that the code causing the problem was actually valid, and Eric replied that he had compiled the snippet as its own standalone program, without any problem. This told him the bad code was elsewhere, but he hadn't tried to find it. He also noticed that compiling with gcc 2.91 but without -O2, cured the problem.

Elsewhere, Patrik Stridvall pointed out that even though the code might be perfectly valid, it mixed Win16 and Win32 data structures. He added that while this was sometimes needed because of Win16/Win32 intercalls, in this case it definitely was not. He suggested changing the type of the pointer from POINT16 to POINT.

Eric was not sure at first whether Patrik's suggestion would work, but he tried it and it did. He also suggested a couple other possible solutions.

5. Some Explanation For A Rejected Patch

22 Dec 1999 (2 posts) Archive Link: "Why was my BiDi16 patch rejected?"

People: Patrik Stridvall, , Patrik Stridval

Several days before, Erez Volk had posted a patch related to win16 bidirectional functions, that had stubs for 3 new functions and names and prototypes for over 30 others. It seemed that the patch had not been accepted, and he asked why not, as it allowed sol.exe and winmine.exe from hebrew windows 98 to run.

Patrik Stridvall replied:

I am not sure it really was rejected, since Alexandre has applied very few patches lately.

However, I just looked at it and there is at least one possible ground of rejection AFAICS.

You have put implementations of USER and GDI functions in wine/if1632 where they do not belong IMHO.

I guess you did that because of the fact that the previous stubs where in wine/if1632/dummy.c.

Nether the less, I would recomend that you

I am not sure whether the file should be called bidi16.c or bidi.c. Wine currently mixes Win16 and Win32 functions but perhaps it shouldn't.

6. Bug In A Comment

22 Dec 1999 - 23 Dec 1999 (3 posts) Archive Link: "splitpath"

People: Francois Gouget, , Michael Cardenas, Patrik Stridvall

Michael Cardenas noticed that a comment in tchar.h claimed that splitpath was not implemented; and asked if this was still the case. Patrik Stridvall replied that splitpath had (as far as he knew) been available for a long time, and Francois Gouget added,
I wrote the initial version of tchar.h and it is _very_ possible that I overlooked the implementation of splitpath. If Patrik says it is implemented then it must be

 

 

 

 

 

 

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.