Re: winex11: use XkbKeycodeToKeysym instead of (deprecated) XKeycodeToKeysym (see http://bugs.freedesktop.org/show_bug.cgi?id=5349)
Alexandre Goujon wrote: > -if (!(keysym = XKeycodeToKeysym (display, keyc, i))) continue; > +if (!(keysym = XkbKeycodeToKeysym (display, keyc, 0, i))) continue; Not every X11 implementation has the XKB extenstion. You may want to take into account 'use_xkb' and 'HAVE_XKB'. -- Dmitry.
Re: [1/2] include/wine: add option to specify the unittest target via environment variable
Am Tuesday 20 April 2010 20:57:41 schrieb Paul Vriens: > On 04/20/2010 08:37 PM, Stefan Leichter wrote: > > Am Tuesday 20 April 2010 07:59:22 schrieb Paul Vriens: > >> On 04/19/2010 11:44 PM, Stefan Leichter wrote: > >>> --- > >>>include/wine/test.h |6 +- > >>>1 files changed, 5 insertions(+), 1 deletions(-) > >> > >> Hi Stefan, > >> > >> What's the idea/thought behind this (or what problem are you trying to > >> solve)? > > > > Hi Paul, > > > > the problem is the "command line parsing" of ShellExecuteEx, see bug19666 > > (http://bugs.winehq.org/show_bug.cgi?id=19666#c3). > > > > When a directory contains two executables where the name of the first, > > without extension, is the leading part of the name of the second and the > > second file have a blank at the position where the first file has the > > dot, wine implementation of ShellExecuteEx starts the first executable > > when the name of the second given to ShellExecuteEx. > > > > If a unittest call the second executable via ShellExecuteEx, the first > > executable is started and the test target is the trailing part of the > > filename including the extension. This causes a test failure because the > > test target does not exist. > > > > Example: > > test file.exe > > test file two.exe > > > > Builtin ShellExecuteEx starts always "test file.exe". If "test file > > two.exe" was passed as name to be ShellExecuteEx argv[1] will be > > "two.exe". > > > > To get around this problem and make a valid unittest without fixing the > > problem, i looked for another way to pass the test target to the > > executable. > > This statement classifies this patch as a hack, not? What is your suggestion about my last point, which you removed silently? -- Bye Stefan
Re: Writing test programs for dlls/krnl386.exe16
Morten Rønne wrote: > I can't see what I should have missed in Makefile.in for this to fail. I would > expect the needed rules would be made automatically when creating the final > Makefile with make depend. > > I can run tests in kernel32 just fine. 1. You went in the wrong direction by choosing to write the tests in asm. 2. It should be acceptable to add the tests in kernel32 (you won't be able to call 16-bit APIs directly or link to 16-bit libraries anyway). -- Dmitry.
Re: Adding translation for wineprefixcreate manpage
Frédéric Delanoy writes: > In the process, I also added the wineprefixcreate En manpage in the "install > install-dev". Is that problematic? > > Could so please tell me what I did wrong so I can fix and resubmit the patch? I don't think there's much point in adding translations for wineprefixcreate, it's deprecated and should probably be removed. -- Alexandre Julliard julli...@winehq.org
Adding translation for wineprefixcreate manpage
Hi folks, A couple of days ago, I submitted a patch to add French manpage of wineprefixcreate, which was discarded (see attachment). I modeled it after German winemaker addition (SHA d53e75af1474d0bd9c8b8660827baaf8fe708f4c) by adding - entries in tools/Makefile.in - a .gitignore entry for the generated manpage - actual translated manpage I guess the patch was refused because of problems in tools/Makefile.in. Basically what I added was - entry in MANPAGES - french dir in INSTALLDIRS - entries in "install install-lib" and "install install-dev" - uninstall entry In the process, I also added the wineprefixcreate En manpage in the "install install-dev". Is that problematic? Could so please tell me what I did wrong so I can fix and resubmit the patch? Thanks in advance. Frédéric >From 14e26ada32e07f2772120aa5a1d9fbf5216b69d1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Delanoy?= Date: Mon, 12 Apr 2010 22:27:11 +0200 Subject: tools: Add French translation of wineprefixcreate manpage --- .gitignore |1 + tools/Makefile.in| 11 - tools/wineprefixcreate.fr.man.in | 81 ++ 3 files changed, 90 insertions(+), 3 deletions(-) create mode 100644 tools/wineprefixcreate.fr.man.in diff --git a/.gitignore b/.gitignore index d2ba32b..9287fb7 100644 --- a/.gitignore +++ b/.gitignore @@ -280,6 +280,7 @@ tools/winegcc/winegcc.man tools/winemaker.de.man tools/winemaker.man tools/wineprefixcreate +tools/wineprefixcreate.fr.man tools/wineprefixcreate.man tools/wmc/mcy.tab.c tools/wmc/mcy.tab.h diff --git a/tools/Makefile.in b/tools/Makefile.in index 526ac1b..5dd5370 100644 --- a/tools/Makefile.in +++ b/tools/Makefile.in @@ -21,7 +21,8 @@ PROGRAMS = \ MANPAGES = \ winemaker.man \ winemaker.de.man \ - wineprefixcreate.man + wineprefixcreate.man \ + wineprefixcreate.fr.man C_SRCS = \ fnt2bdf.c \ @@ -38,7 +39,8 @@ INSTALLDIRS = \ $(DESTDIR)$(datadir)/applications \ $(DESTDIR)$(datadir)/wine \ $(DESTDIR)$(mandir)/man$(prog_manext) \ - $(DESTDIR)$(mandir)/de.UTF-8/man$(prog_manext) + $(DESTDIR)$(mandir)/de.UTF-8/man$(prog_manext) \ + $(DESTDIR)$(mandir)/fr.UTF-8/man$(prog_manext) UPDATE_DESKTOP_DATABASE = update-desktop-database @@ -79,15 +81,18 @@ install install-lib:: wine.inf wineprefixcreate $(INSTALLDIRS) $(INSTALL_DATA) wine.inf $(DESTDIR)$(datadir)/wine/wine.inf $(INSTALL_DATA) $(SRCDIR)/wine.desktop $(DESTDIR)$(datadir)/applications/wine.desktop $(INSTALL_DATA) wineprefixcreate.man $(DESTDIR)$(mandir)/man$(prog_manext)/wineprefixcreate.$(prog_manext) + $(INSTALL_DATA) wineprefixcreate.fr.man $(DESTDIR)$(mandir)/fr.UTF-8/man$(prog_manext)/wineprefixcreate.$(prog_manext) -$(UPDATE_DESKTOP_DATABASE) install install-dev:: $(DESTDIR)$(bindir) $(DESTDIR)$(mandir)/man$(prog_manext) $(INSTALL_SCRIPT) $(SRCDIR)/winemaker $(DESTDIR)$(bindir)/winemaker $(INSTALL_DATA) winemaker.man $(DESTDIR)$(mandir)/man$(prog_manext)/winemaker.$(prog_manext) $(INSTALL_DATA) winemaker.de.man $(DESTDIR)$(mandir)/de.UTF-8/man$(prog_manext)/winemaker.$(prog_manext) + $(INSTALL_DATA) wineprefixcreate.man $(DESTDIR)$(mandir)/man$(prog_manext)/wineprefixcreate.$(prog_manext) + $(INSTALL_DATA) wineprefixcreate.fr.man $(DESTDIR)$(mandir)/fr.UTF-8/man$(prog_manext)/wineprefixcreate.$(prog_manext) uninstall:: - $(RM) $(DESTDIR)$(bindir)/winemaker $(DESTDIR)$(bindir)/wineprefixcreate $(DESTDIR)$(mandir)/man$(prog_manext)/winemaker.$(prog_manext) $(DESTDIR)$(mandir)/de.UTF-8/man$(prog_manext)/winemaker.$(prog_manext) $(DESTDIR)$(mandir)/man$(prog_manext)/wineprefixcreate.$(prog_manext) $(DESTDIR)$(datadir)/wine/wine.inf $(DESTDIR)$(datadir)/applications/wine.desktop + $(RM) $(DESTDIR)$(bindir)/winemaker $(DESTDIR)$(bindir)/wineprefixcreate $(DESTDIR)$(mandir)/man$(prog_manext)/winemaker.$(prog_manext) $(DESTDIR)$(mandir)/de.UTF-8/man$(prog_manext)/winemaker.$(prog_manext) $(DESTDIR)$(mandir)/man$(prog_manext)/wineprefixcreate.$(prog_manext) $(DESTDIR)$(mandir)/fr.UTF-8/man$(prog_manext)/wineprefixcreate.$(prog_manext) $(DESTDIR)$(datadir)/wine/wine.inf $(DESTDIR)$(datadir)/applications/wine.desktop -$(UPDATE_DESKTOP_DATABASE) depend: makedep$(EXEEXT) diff --git a/tools/wineprefixcreate.fr.man.in b/tools/wineprefixcreate.fr.man.in new file mode 100644 index 000..97db584 --- /dev/null +++ b/tools/wineprefixcreate.fr.man.in @@ -0,0 +1,81 @@ +.\" -*- nroff -*- +.TH WINEPREFIXCREATE 1 "avril 2010" "@PACKAGE_STRING@" "Windows sur Unix" +.SH NOM +wineprefixcreate \- créer ou mettre à jour la configuration de Wine +.SH SYNOPSIS +.BI wineprefixcreate\ [options] +.SH DESCRIPTION +.B wineprefixcreate +crée ou met à jour un répertoire de configuration de Wine. Quand Wine +s'exécute, le nom de base du répertoire de configuration est
Re: Writing test programs for dlls/krnl386.exe16
Hi
Thank you for the pointers Dmitry.
But it seems none of these projects made any progress since no tests
have turned up in the git tree. :)
Also none of these really answers any of the question I asked in any
detail.
So I have tried to follow the description on how to add a new test, but
I can't get the test to run.
The "make test" ends by saying "No rule to make .dll.so needed by .ok".
I can't see what I should have missed in Makefile.in for this to fail.
I would expect the needed rules would be made automatically when
creating the final Makefile with make depend.
I can run tests in kernel32 just fine.
So I am attaching the Makefile.in and the only c-source that should be
needed to create something that should able to run but do no tests, in
the hope that someone can point out what obvious thing I have missed.
Best Regards
Morten Rønne
Dmitry Timoshkov wrote:
Morten Rønne wrote:
I would like to write some tests for the krnl386.exe16 part of wine, or
more precisely the DOS parts of that.
Archives should have enough asnwers to question like this one, one of
the attemps is here:
http://www.winehq.org/pipermail/wine-devel/2009-January/072560.html
TOPSRCDIR = @top_srcdir@
TOPOBJDIR = ../../..
SRCDIR= @srcdir@
VPATH = @srcdir@
TESTDLL = krnl386.dll
IMPORTS = user32 kernel32
ASM =
C_SRCS = \
krnl386.c
# Rule for making 16 bit sources if assembler is available
ifdef ASM
ASM_SRCS = \
int21.asm
$(TESTDLL) : $(ASM_SRCS)
.com.asm:
-$(ASM) -f bin -w+orphan-labels -o $@ $<
endif
@MAKE_TEST_RULES@
/*
* Copyright 2010 Morten Rønne
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*/
#include "wine/test.h"
#include
static DWORD pos, end;
char buffer[8192];
static int read_line (HANDLE *file, char *text)
{
DWORD o;
o = 0;
if(pos == end) {
ReadFile(file, buffer, 8192, &end, NULL);
pos = 0;
}
while(pos < end) {
if(buffer[pos] == '\n') {
text[o++] = '\n';
text[o++] = '\0';
pos++;
return 1;
}
if(o < 510)
text[o++] = buffer[pos];
pos++;
if(pos == end) {
ReadFile(file, buffer, 8192, &end, NULL);
pos = 0;
}
}
return 0;
}
static int read_test_file(char *name) {
HANDLE file;
char line[512];
file = CreateFileA("test.rep", GENERIC_READ, 0, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
ok(file != INVALID_HANDLE_VALUE, "CreateFile failed for test.rep: %08x\n",
GetLastError());
if(file == INVALID_HANDLE_VALUE)
return 0;
pos = 0;
end = 0;
/* Read each line and make report */
while(read_line(file, line)) {
if(line[1] == ':' && line[2] == ' ') {
if(line[0] == 't') {
todo_wine {
ok(FALSE, "%s: %s", name, &line[3]);
}
} else {
ok(FALSE, "%s: %s", name, &line[3]);
}
}
}
CloseHandle(file);
return 1;
}
static int run_program(char *name)
{
STARTUPINFOA si;
PROCESS_INFORMATION pi;
/* The file is not found, then tests are not run, so we return TRUE */
if(GetFileAttributes(name) == INVALID_FILE_ATTRIBUTES)
return TRUE;
memset(&si, 0, sizeof(si));
si.cb = sizeof(si);
if (CreateProcessA(NULL, name, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi))
{
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
if(read_test_file(name))
return TRUE;
}
return FALSE;
}
START_TEST(krnl386)
{
/*
* We are testing DOS functions which requires 16 bit mode.
* But this program runs in 32 bit mode.
* So we load a 16 bit test program to do the actual testing.
* After that reports are gathered and tested based on file created
* by the run program.
* So to affect todo's, change the 16 bit program not this.
*/
/* First test int 21 which are required by all the others */
ok(run_program("int21.com") == TRUE,
"Failed to run int 21 tests. Last Error: 0x%04x", GetLastError());
/* Test int 10, graphics card */
/* Test int 2f */
/* Test int 31, ems */
}
Graphics Driver Interface Standardization
Hi,
I'm getting ready to implement the Quartz Driver. For those of you who
don't know, this is a special graphics driver that only works on Mac OS
X, and uses its native Core Graphics (aka, Quartz) system to draw.
But before I can do this, there are two things that need to be done:
1. Wine currently assumes that the current graphics driver is the X11
driver. It directly GetModuleHandle()'s winex11.drv in order to call
driver functions. This needs to be fixed.
2. The driver interface needs to be standardized.
I can fix the first problem by adding a Wine-specific export to GDI32,
then updating all the winex11 clients to call this function, but the
second problem will make writing a non-X11 driver problematic. The GDI
and USER interfaces are already somewhat standardized, but the reason
many clients call winex11.drv directly is to call the "Thread-Safe X11"
locking routines. Also, Explorer calls winex11 to create the desktop and
notification area ("systray") windows.
Therefore, I propose this interface. It's largely based off of winex11,
but with some small modifications. It's attached to this mail. What do
you think of this?
And don't tell me that we need a DIB engine before I get started on
winequartz. I intend to use Mac OS X native APIs (like Core Image) to
accelerate DIBs, in much the same way winex11 uses Xrender.
Chip
# GDI driver
@ cdecl AlphaBlend(ptr long long long long ptr long long long long long)
@ cdecl Arc(ptr long long long long long long long long)
@ cdecl ChoosePixelFormat(ptr ptr)
@ cdecl Chord(ptr long long long long long long long long)
@ cdecl CreateBitmap(ptr long ptr)
@ cdecl CreateDC(long ptr wstr wstr wstr ptr)
@ cdecl CreateDIBSection(ptr long ptr long)
@ cdecl DeleteBitmap(long)
@ cdecl DeleteDC(ptr)
@ cdecl DescribePixelFormat(ptr long long ptr)
@ cdecl Ellipse(ptr long long long long)
@ cdecl EnumDeviceFonts(ptr ptr ptr long)
@ cdecl ExtEscape(ptr long long ptr long ptr)
@ cdecl ExtFloodFill(ptr long long long long)
@ cdecl ExtTextOut(ptr long long long ptr ptr long ptr)
@ cdecl GetBitmapBits(long ptr long)
@ cdecl GetCharWidth(ptr long long ptr)
@ cdecl GetDCOrgEx(ptr ptr)
@ cdecl GetDIBits(ptr long long long ptr ptr long)
@ cdecl GetDeviceCaps(ptr long)
@ cdecl GetDeviceGammaRamp(ptr ptr)
@ cdecl GetICMProfile(ptr ptr ptr)
@ cdecl GetNearestColor(ptr long)
@ cdecl GetPixel(ptr long long)
@ cdecl GetPixelFormat(ptr)
@ cdecl GetSystemPaletteEntries(ptr long long ptr)
@ cdecl GetTextExtentExPoint(ptr ptr long long ptr ptr ptr)
@ cdecl GetTextMetrics(ptr ptr)
@ cdecl LineTo(ptr long long)
@ cdecl PaintRgn(ptr long)
@ cdecl Pie(ptr long long long long long long long long)
@ cdecl PolyPolygon(ptr ptr ptr long)
@ cdecl PolyPolyline(ptr ptr ptr long)
@ cdecl Polygon(ptr ptr long)
@ cdecl Polyline(ptr ptr long)
@ cdecl RealizeDefaultPalette(ptr)
@ cdecl RealizePalette(ptr long long)
@ cdecl Rectangle(ptr long long long long)
@ cdecl RoundRect(ptr long long long long long long)
@ cdecl SelectBitmap(ptr long)
@ cdecl SelectBrush(ptr long)
@ cdecl SelectFont(ptr long long)
@ cdecl SelectPen(ptr long)
@ cdecl SetBitmapBits(long ptr long)
@ cdecl SetBkColor(ptr long)
@ cdecl SetDCBrushColor(ptr long)
@ cdecl SetDCPenColor(ptr long)
@ cdecl SetDIBColorTable(ptr long long ptr)
@ cdecl SetDIBits(ptr long long long ptr ptr long)
@ cdecl SetDIBitsToDevice(ptr long long long long long long long long ptr ptr
long)
@ cdecl SetDeviceClipping(ptr long long)
@ cdecl SetDeviceGammaRamp(ptr ptr)
@ cdecl SetPixel(ptr long long long)
@ cdecl SetPixelFormat(ptr long ptr)
@ cdecl SetTextColor(ptr long)
@ cdecl StretchBlt(ptr long long long long ptr long long long long long)
@ cdecl SwapBuffers(ptr)
@ cdecl UnrealizePalette(long)
# USER driver
@ cdecl ActivateKeyboardLayout(long long)
@ cdecl Beep()
@ cdecl GetAsyncKeyState(long)
@ cdecl GetKeyNameText(long ptr long)
@ cdecl GetKeyboardLayout(long)
@ cdecl GetKeyboardLayoutName(ptr)
@ cdecl LoadKeyboardLayout(wstr long)
@ cdecl MapVirtualKeyEx(long long long)
@ cdecl SendInput(long ptr long)
@ cdecl ToUnicodeEx(long long ptr ptr long long long)
@ cdecl UnloadKeyboardLayout(long)
@ cdecl VkKeyScanEx(long long)
@ cdecl SetCursor(ptr)
@ cdecl GetCursorPos(ptr)
@ cdecl SetCursorPos(long long)
@ cdecl ClipCursor(ptr)
@ cdecl GetScreenSaveActive()
@ cdecl SetScreenSaveActive(long)
@ cdecl ChangeDisplaySettingsEx(ptr ptr long long long)
@ cdecl EnumDisplayMonitors(long ptr ptr long)
@ cdecl EnumDisplaySettingsEx(ptr long ptr long)
@ cdecl GetMonitorInfo(long ptr)
@ cdecl AcquireClipboard(long)
@ cdecl CountClipboardFormats()
@ cdecl CreateDesktopWindow(long)
@ cdecl CreateWindow(long)
@ cdecl DestroyWindow(long)
@ cdecl EmptyClipboard(long)
@ cdecl EndClipboardUpdate()
@ cdecl EnumClipboardFormats(long)
@ cdecl GetClipboardData(long)
@ cdecl GetClipboardFormatName(long ptr long)
@ cdecl GetDC(long long long ptr ptr long)
@ cdecl IsClipboardFormatAvailable(long)
@ c
Re: [PATCH 4/6] [WineGcc]: when specifying -m32, force i386 cpu when compiling on x86_64 boxes
André Hentschel a écrit : Hi Eric, That will not be enough as it will still just find the 64-bit libs. Maybe we should implement a check in utils.c if it is a ELF32 or ELF64 lib which we try to import. AFAICS it's not worse than when we use -b i386-elf when building for wow64, we use winegcc for linking either 32bit or 64bit execs (with the --sysroot switch) not use what you propose will help... it'll prevent an error later on in gcc (or ld), but if winegcc is passed directories with wrong libraries, it should, IMO, fail and not try to find the right lib A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: Winebuild b0rken on Mac OS X?
On 4/20/10 1:26 PM, eric lanz wrote: > I've seen this error using the os 4.0 beta 1 sdk, using the GM 3.2 sdk I > don't get this error -- so the last couple weeks I've been switching > sdk's back and forth to get around the problem. I'm downloading os 4.0 > beta 2 right now to see if apple fixed it. Hey, now that you mention it, I did just install the beta 1 SDK. I think you're on to something. Is beta 2 out already? Wow, that was fast. Let's see if they fixed this in beta 2. Chip
Re: Winebuild b0rken on Mac OS X?
I've seen this error using the os 4.0 beta 1 sdk, using the GM 3.2 sdk I don't get this error -- so the last couple weeks I've been switching sdk's back and forth to get around the problem. I'm downloading os 4.0 beta 2 right now to see if apple fixed it. --- On Tue, 4/20/10, Charles Davis wrote: From: Charles Davis Subject: Winebuild b0rken on Mac OS X? To: "wine-devel" Date: Tuesday, April 20, 2010, 12:21 PM While building Wine (latest git) on Mac OS X, I noticed this: /usr/bin/nm: object: amstream_test.MDsdpi.o malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) Undefined symbols: "_GetDesktopWindow", referenced from: _func_amstream in amstream.o "_TlsGetValue", referenced from: _get_tls_data in testlist.o "_MultiByteToWideChar", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_CloseHandle", referenced from: _func_amstream in amstream.o "_TlsSetValue", referenced from: _get_tls_data in testlist.o "_DirectDrawCreate", referenced from: _func_amstream in amstream.o "_CoCreateInstance", referenced from: _create_ammultimediastream in amstream.o "_WaitForSingleObject", referenced from: _winetest_wait_child_process in testlist.o "_CoInitializeEx", referenced from: _func_amstream in amstream.o "_HeapAlloc", referenced from: _get_tls_data in testlist.o "_CoUninitialize", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_GetExitCodeProcess", referenced from: _winetest_wait_child_process in testlist.o "_GetEnvironmentVariableA", referenced from: _main in testlist.o _main in testlist.o _main in testlist.o _main in testlist.o "_ExitProcess", referenced from: _exit_process in testlist.o ___wine_spec_exe_entry in libwinecrt0.a(exe_entry.o) "_CreateFileA", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_TlsAlloc", referenced from: _run_test in testlist.o ld: symbol(s) not found collect2: ld returned 1 exit status winegcc: gcc failed make[1]: *** [amstream_test.exe.so] Error 2 make: *** [dlls/amstream/tests] Error 2 Something's gone horribly wrong. Winebuild shouldn't be generating b0rken Mach-O files. What gives?
Re: [1/2] include/wine: add option to specify the unittest target via environment variable
On 04/20/2010 09:04 PM, Juan Lang wrote: To get around this problem and make a valid unittest without fixing the problem, i looked for another way to pass the test target to the executable. This statement classifies this patch as a hack, not? Perhaps, but there's a chicken and egg problem: fixing the problem without a valid unit test doesn't seem likely to happen. --Juan But a statement just before that says it 'just' causes a test failure. Is there no other way around this? If we only want to have a test case to prove how Windows works I'd find a hack to skip the test on Wine a little bit better. And why couldn't we fix the problem before submitting tests? This happens all the time. If people really want to see proof before changing the implementation we can use our testbot to show the tests are correct (just give the tests patch to the testbot and run it on all platforms). -- Cheers, Paul.
Winebuild b0rken on Mac OS X?
While building Wine (latest git) on Mac OS X, I noticed this: /usr/bin/nm: object: amstream_test.MDsdpi.o malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) Undefined symbols: "_GetDesktopWindow", referenced from: _func_amstream in amstream.o "_TlsGetValue", referenced from: _get_tls_data in testlist.o "_MultiByteToWideChar", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_CloseHandle", referenced from: _func_amstream in amstream.o "_TlsSetValue", referenced from: _get_tls_data in testlist.o "_DirectDrawCreate", referenced from: _func_amstream in amstream.o "_CoCreateInstance", referenced from: _create_ammultimediastream in amstream.o "_WaitForSingleObject", referenced from: _winetest_wait_child_process in testlist.o "_CoInitializeEx", referenced from: _func_amstream in amstream.o "_HeapAlloc", referenced from: _get_tls_data in testlist.o "_CoUninitialize", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_GetExitCodeProcess", referenced from: _winetest_wait_child_process in testlist.o "_GetEnvironmentVariableA", referenced from: _main in testlist.o _main in testlist.o _main in testlist.o _main in testlist.o "_ExitProcess", referenced from: _exit_process in testlist.o ___wine_spec_exe_entry in libwinecrt0.a(exe_entry.o) "_CreateFileA", referenced from: _func_amstream in amstream.o _func_amstream in amstream.o "_TlsAlloc", referenced from: _run_test in testlist.o ld: symbol(s) not found collect2: ld returned 1 exit status winegcc: gcc failed make[1]: *** [amstream_test.exe.so] Error 2 make: *** [dlls/amstream/tests] Error 2 Something's gone horribly wrong. Winebuild shouldn't be generating b0rken Mach-O files. What gives?
Re: [PATCH] d3dx9_36: Implement D3DXCheckTextureRequirements + tests
Yeah, I was refering to this particular error. I just saw I didn't commit the remaining code to my public git repo (... because it's a bit ugly), this ( http://tonwas.freefronthost.com/gsocwork.tar.gz ... early snapshot of my work, which I vastly cleaned up lateron) tarball provides the remaining code at snapshot/texture.c. What this code does is if the requested format is not supported, try to find some other format which hopefully won't reduce image quality. This is done by using some heuristics, i.e. rules (some of which are more important than others). Generally speaking, FourCC and 24-bit formats are avoided unless directly requested. Also we won't change format _types_, e.g. no ARGB to DXT conversion. Then, we try to not remove any color component channel; then we try to not reduce the number of bits per requested channel; then (of the few remaining formats) we pick the one with the lowest INCREASE in number of bits per channel (i.e. the best would be the same bpc); the last heuristic is the increase in number of channels, which ofc should be kept to a minimum. btw note that the heuristics given on the MSDN site of this function aren't the real ones; they have similiarity with the real ones, but my version of them is closer to actual native behavior. I've thoroughly tested this code and it works in almost 99% of all possible cases for ARGB/QWVU/Paletted/Luminance (i.e. "simple" uncompressed formats)) and in the very few cases it doesn't copy native behavior it at least returns a usuable fallback format. Anyway, I strongly advise you to add this stuff in a later patch and replace it with a FIXME message or some comment for now. I was thinking about something like this. I put a FIXME if CheckDeviceFormat fails until there is a real implementation.
Re: [1/2] include/wine: add option to specify the unittest target via environment variable
>> To get around this problem and make a valid unittest without fixing the >> problem, i looked for another way to pass the test target to the >> executable. > > This statement classifies this patch as a hack, not? Perhaps, but there's a chicken and egg problem: fixing the problem without a valid unit test doesn't seem likely to happen. --Juan
Re: [1/2] include/wine: add option to specify the unittest target via environment variable
On 04/20/2010 08:37 PM, Stefan Leichter wrote: Am Tuesday 20 April 2010 07:59:22 schrieb Paul Vriens: On 04/19/2010 11:44 PM, Stefan Leichter wrote: --- include/wine/test.h |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) Hi Stefan, What's the idea/thought behind this (or what problem are you trying to solve)? Hi Paul, the problem is the "command line parsing" of ShellExecuteEx, see bug19666 (http://bugs.winehq.org/show_bug.cgi?id=19666#c3). When a directory contains two executables where the name of the first, without extension, is the leading part of the name of the second and the second file have a blank at the position where the first file has the dot, wine implementation of ShellExecuteEx starts the first executable when the name of the second given to ShellExecuteEx. If a unittest call the second executable via ShellExecuteEx, the first executable is started and the test target is the trailing part of the filename including the extension. This causes a test failure because the test target does not exist. Example: test file.exe test file two.exe Builtin ShellExecuteEx starts always "test file.exe". If "test file two.exe" was passed as name to be ShellExecuteEx argv[1] will be "two.exe". To get around this problem and make a valid unittest without fixing the problem, i looked for another way to pass the test target to the executable. This statement classifies this patch as a hack, not? -- Cheers, Paul.
ImageCapture Wine TWAIN plug-in
Anybody else up for the idea of an ImageCapture (Mac OS X) plug-in for Wine's TWAIN? It would fit the role of sane.ds and gphoto.ds, as it can both scan and access cameras. ImageCapture can also use Mac OS X TWAIN drivers.
Re: [1/2] include/wine: add option to specify the unittest target via environment variable
Am Tuesday 20 April 2010 07:59:22 schrieb Paul Vriens: > On 04/19/2010 11:44 PM, Stefan Leichter wrote: > > --- > > include/wine/test.h |6 +- > > 1 files changed, 5 insertions(+), 1 deletions(-) > > Hi Stefan, > > What's the idea/thought behind this (or what problem are you trying to > solve)? Hi Paul, the problem is the "command line parsing" of ShellExecuteEx, see bug19666 (http://bugs.winehq.org/show_bug.cgi?id=19666#c3). When a directory contains two executables where the name of the first, without extension, is the leading part of the name of the second and the second file have a blank at the position where the first file has the dot, wine implementation of ShellExecuteEx starts the first executable when the name of the second given to ShellExecuteEx. If a unittest call the second executable via ShellExecuteEx, the first executable is started and the test target is the trailing part of the filename including the extension. This causes a test failure because the test target does not exist. Example: test file.exe test file two.exe Builtin ShellExecuteEx starts always "test file.exe". If "test file two.exe" was passed as name to be ShellExecuteEx argv[1] will be "two.exe". To get around this problem and make a valid unittest without fixing the problem, i looked for another way to pass the test target to the executable. Finaly to perform the same flow as the program in bug 19666 does, ShellExecuteEx needs to be called without any parameter. -- Bye Stefan
Re: imm32: rework storage of thread default contexts
I think for threadproc function it should be WINAPI or CALLBACK. DWORD WINAPI ThreadProc( __in LPVOID lpParameter ); yes. I should set the test to be static. -aric André Hentschel wrote: Hi Aric, You should have a second look at the Function heads in the tests (imm32.c). I doubt WINAPI should be used and the functions should be static.
Re: imm32: rework storage of thread default contexts
Hi Aric, You should have a second look at the Function heads in the tests (imm32.c). I doubt WINAPI should be used and the functions should be static. -- Best Regards, André Hentschel
Re: [PATCH 4/6] [WineGcc]: when specifying -m32, force i386 cpu when compiling on x86_64 boxes
Hi Eric, That will not be enough as it will still just find the 64-bit libs. Maybe we should implement a check in utils.c if it is a ELF32 or ELF64 lib which we try to import. -- Best Regards, André Hentschel
Re: [PATCH] d3dx9_36: Implement D3DXCheckTextureRequirements + tests
Am 19.04.2010 20:48, schrieb Christian Costa: > Well, it's your code, correct ? > I suggest to simply remove these checks. There does not bring any > added values. It's my own code, but I noticed this flaw some time after GSoC was over, it can be quite disturbing. Additionally, the checks might not be useful in this case, but when/if D3DXCreateTexture gets implemented it'll make it easier to spot subtle memory leaks (like not Release()ing some buffer surface the function might use internally) which otherwise would go unnoticed. > Could you be more specific on what's need to be implemented ? > The if statement catches several errors. Maybe you want to catch an > error on CheckDeviceFormat, correct ? Yeah, I was refering to this particular error. I just saw I didn't commit the remaining code to my public git repo (... because it's a bit ugly), this ( http://tonwas.freefronthost.com/gsocwork.tar.gz ... early snapshot of my work, which I vastly cleaned up lateron) tarball provides the remaining code at snapshot/texture.c. What this code does is if the requested format is not supported, try to find some other format which hopefully won't reduce image quality. This is done by using some heuristics, i.e. rules (some of which are more important than others). Generally speaking, FourCC and 24-bit formats are avoided unless directly requested. Also we won't change format _types_, e.g. no ARGB to DXT conversion. Then, we try to not remove any color component channel; then we try to not reduce the number of bits per requested channel; then (of the few remaining formats) we pick the one with the lowest INCREASE in number of bits per channel (i.e. the best would be the same bpc); the last heuristic is the increase in number of channels, which ofc should be kept to a minimum. btw note that the heuristics given on the MSDN site of this function aren't the real ones; they have similiarity with the real ones, but my version of them is closer to actual native behavior. I've thoroughly tested this code and it works in almost 99% of all possible cases for ARGB/QWVU/Paletted/Luminance (i.e. "simple" uncompressed formats)) and in the very few cases it doesn't copy native behavior it at least returns a usuable fallback format. Anyway, I strongly advise you to add this stuff in a later patch and replace it with a FIXME message or some comment for now. > > BTW, you are reviewing your own patch (albeit slighty modified) ;-) , > does that mean you plan to make your work > go into mainline ? I'm glad someone picks up my patches, so I try to support this work as far as I can. I just have no time on working on this stuff myself anymore, i.e. no (direct) further work on this planned... By the way, IMO the function documentation is pretty useful, at least description and the stuff about the return values (and additional NOTES), since it kind of verifies that the behavior is intended and not the result of some ugly coding..
Re: [2/2] dlls/shell32/tests: add some tests for ShellExecuteEx
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=1612 Your paranoid android. === WNT4WSSP6 (NT4 Workstation SP6 (English, IE2)) === Timeout === W7PROX64 (Windows 7 Professional 64 bit) === shlexec.c:1662: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt6C9.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1662: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt6C9.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1662: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt6C9.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1662: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt6C9.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1662: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt6C9.tmp\test file.sde", null, null) failed: rc=29 err=2
