Wine Traffic
Zack Brown
Eric Pouech couldn't write KC Wine this week, so I've whipped something up.
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.
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.
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.
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
Move the GDI functions in wine/if1632/bidi16.c to wine/graphics/bidi.c
(possibly bidi16.c)
Move the USER functions in wine/if1632/bidi16.c to wine/windows/bidi.c
(possibly bidi16.c)
Remove (do not add) wine/if1632/bidi16.c
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.
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