Re: registry keys of serial ports
Hello, while hunting down why a drop down box didn't offer me the serial port I configured, I stumbled across Stefans proposal from Summer 09. The patch still applied cleanly, and after setting up hal and the hal development library, the progarm worked as expected. What is the status of that proposal? Thanks -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Wine/USB, was: Re: Glitch-free iTunes?
>>>>> "Damjan" == Damjan Jovanovic writes: Damjan> So it's slow going and there's a lot to do, and few Wine Damjan> developers seem to care. One can only hope that when some Damjan> devices start working, it will generate new interest in Wine Damjan> (and Linux), and Wine will get many more patches :-). Damjan, do you have a GIT tree to test with some easily available device to play with and some rmearks what to expect and what to expect not? Lowering the entry barriere might help finding additional interest... Bye -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: USB Osciloscope
>>>>> "Shachar" == Shachar Shemesh writes: >> I have a USB osciloscope (Link Instruments DSO 8002) that I am quite >> motivated to get working in wine. I have followed the instructions >> to install the USB patches. The osciloscope software works fine in >> demo mode, but it still cannot find the device. I have spent some >> time messing around with this, but I am new to wine, so I am a little >> lost. I am a half decent c programmer, so If somebody could point me >> in the right direction I should be able to get this working. >> >> I have gotten error message usbd.sys failed to load. >> >> I don't know if this program requires functions that wine does not >> support or I have just failed to install something correctly. >> >> I have attached lsusb and winedump -x output >> >> Any help would be greatly appreciated. >> Shachar> usbd.sys sounds like a kernel driver. I'm not sure those are Shachar> supported, even for USB. USB driver are not supported per se, but Alexander Morozov tried to build infrastructure for such driver loading. He provided patches and asked for discussion, but few to non feedback happened on this list. Also Damjan Jovanovic Jan 23 91/4337 "USB architecture: driver loading question" tried to take up the subject, again with no feedback. Linux users in the elektronic area would love to see Wine supporting USB drivers... Archie >> I have gotten error message usbd.sys failed to load. Try to get more information about that error. Is some kernel driver api missing? At some point I had at least usbd.sys loading, also the final device driver failed. Another approach: Can you look at the ezusb-imports of your application and compare against what linux-2.6.34.7-0.7/drivers/usb/serial/ezusb.xxx sipplies? Perhaps you can write a replacemment ezusb DLL. Bye -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Wine and serial port AGAIN
>>>>> "Wolfram" == Wolfram Sang writes: ... Wolfram> No need to do this. Vijay just needs to Wolfram> 1) read Documentation/SubmittingPatches 2) consult the Wolfram> MAINTAINERS file (or use scripts/get_maintainer.pl) (you can Wolfram> set me on CC, too) 3) send the patch 4) wait for comments 5) if Wolfram> not applied goto 3 Wolfram> No magic involved :) Only patience and perstistance needed ... And hopefully more feedback than on wine-devel ... -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Wine and serial port AGAIN
>>>>> "Pavel" == Pavel Troller writes:
Pavel> Hi! As a technician, I need often to use some form of serial
Pavel> port communication. My recent experience is with a program for
...
Pavel> power-cycled. The radio is connected using a USB cable, which
Pavel> contains just a regular PL-2303 USB to serial converter, which is
Pavel> perfectly supported in Linux. Port assignment for wine is also
It seems that the PL2303 driver doesn't implement TIOCGICOUNT
/usr/src/linux/usb/serial/pl2303.c
static int pl2303_ioctl(struct tty_struct *tty, struct file *file,
unsigned int cmd, unsigned long arg)
{
struct serial_struct ser;
struct usb_serial_port *port = tty->driver_data;
dbg("%s (%d) cmd = 0x%04x", __func__, port->number, cmd);
switch (cmd) {
case TIOCGSERIAL:
memset(&ser, 0, sizeof ser);
ser.type = PORT_16654;
ser.line = port->serial->minor;
ser.port = port->number;
ser.baud_base = 460800;
if (copy_to_user((void __user *)arg, &ser, sizeof ser))
return -EFAULT;
return 0;
case TIOCMIWAIT:
dbg("%s (%d) TIOCMIWAIT", __func__, port->number);
return wait_modem_info(port, arg);
default:
dbg("%s not supported = 0x%04x", __func__, cmd);
break;
}
return -ENOIOCTLCMD;
}
Perhaps
http://www.mp3car.com/vbulletin/linux/82704-iguidance-2-1-3-wine-7.html has
some hints.
Bye
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: Wine and serial port AGAIN
>>>>> "Pavel" == Pavel Troller writes: Pavel> Hi! As a technician, I need often to use some form of serial Pavel> port communication. My recent experience is with a program for Pavel> programming TYT radios from China. They supply a simple windows Pavel> app, which allows to program all the features of the radio, which Pavel> cannot be accomplished using the radio keyboard only. The Pavel> program works perfectly in wine, with one exception - a physical Pavel> comms with the radio. It complains that it doesn't receive a Pavel> response from the radio, while the radio crashes - it stops Pavel> working, when a programming attempt is made, and has to be Pavel> power-cycled. By programming you mean volatile programming of some parameter and not flash programming? > trace:comm:get_irq_info TIOCGICOUNT err Invalid argument Go to dlls/ntdll/serial.c get_irq_info() and and add TRACES for the parameters to find the invalid argument. A run with +comm,+relay can also be helpfull. Look for the messagebox with the "It complains that it doesn't receive a response from the radio" and look what call before fails. If it is the get_irq_info above, we are on the right track... Bye -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: wiki slightly broken still?
>>>>> "Octavian" == Octavian Voicu writes: >> "What is the name for a billion bytes?" Terabyte, at least in germany. Billion -> 10^12. 10^9 -> "Milliarde" So these questions can be tricky... -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: How to handle Wrapper(?) Dlls
>>>>> "Henri" == Henri Verbeet writes: Henri> On 26 July 2010 13:28, Uwe Bonnes Henri> wrote: >> there are several hardware related libraries, like libusb and >> libftd2xx which exist on Windows and at least linux. I tried already >> to add libftd2xx, but with silent reject. >> >> What is the preferred way to handle it? I feel including in wine is >> favorable, as this gives a good user impression, as some hardware >> device connected to the machine with the windows software installed >> has good chances to work out of the box. >> Henri> I think the idea there is that these would be redundant once Wine Henri> gets proper USB support, though that may still take a while. Wrapper DLLs, where possible, are much more favorable. They don't require server calls for each function call. -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
How to handle Wrapper(?) Dlls
Hello, there are several hardware related libraries, like libusb and libftd2xx which exist on Windows and at least linux. I tried already to add libftd2xx, but with silent reject. What is the preferred way to handle it? I feel including in wine is favorable, as this gives a good user impression, as some hardware device connected to the machine with the windows software installed has good chances to work out of the box. Another possibility, but much less favourable i.m.h.o. would be to build an add-on dll, distributed at either some place at winehq or else. This however requires user intervention and some way to let the user know about the translation dll. Bye -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Any more infos about the build failure for my (small) patch
>>>>> "Paul" == Paul Vriens writes: >> Paul> And this is what my include file shows: Paul> SSL_CTX *SSL_CTX_new(SSL_METHOD *meth); 61557 88 -rw-r--r-- 1 root Paul> root 87238 Jun 2 11:11 ./usr/include/openssl/ssl.h Ah, Readhat defining in it's own way. What about debian? Isn't the OpenSSL documentation way th way it should be? -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Any more infos about the build failure for my (small) patch
Hello, on my Suse 11.3, /usr/include/ssl/ssl.h defines const SSL_METHOD *method; as does http://www.openssl.org/docs/ssl/ssl.html and so in ../dlls/winhttp/net.c and ../dlls/wininet/netconnection.c static SSL_METHOD *method; is flagges as an warning. My patch exchanged -static SSL_METHOD *method; +static const SSL_METHOD *method; but http://source.winehq.org/patches/ flags 63746 Build failure Uwe Bonnes Add-missing-const-qualifier.patc Can anybody give more information? -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: usbd.sys: add usbd.sys (try 2)
Damjan, can you tell us what to expect to work with these patches applied? And to Alexandre: Please -vv if rejected... -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Wine coding style
Hello, are there any examples for Editor settings (e.g. emacs c-mode) resulting in acceptable indentation? Thanks -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: example code appending files with w32api broken?
>>>>> "Hin-Tak" == Hin-Tak Leung writes: Hin-Tak> --- On Tue, 19/1/10, Uwe Bonnes Hin-Tak> wrote: >> Register with the winetestbot, upload your test exe and compare the >> test output Hin-Tak> Thanks for the pointer. I'll bear that in mind. ATM I have a Hin-Tak> patch for one bug which does not work, possibly because it Hin-Tak> uncovers another bug in wine - I can verify the latter by Hin-Tak> trying out the stand-alone version of the patch on a genuine Hin-Tak> windows. So I'll possibly try a genuine windows, and if it Hin-Tak> works out, file a 2nd bug, make the first one depending on the Hin-Tak> 2nd and attach my patch to the first. I'll just need to find a Hin-Tak> time to reboot to windows... Dear Hin-Tak, try to write test for the test suite. And for trying genuine windows, use the winetsetbot. No need to reboot. Test in the test suite fingerpoint at errors and help to not introduce regressions. Bye -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: example code appending files with w32api broken?
>>>>> "Hin-Tak" == Hin-Tak Leung writes: Hin-Tak> I needed a WIN32 API based file-appending solution to fix a bug Hin-Tak> (http://bugs.winehq.org/show_bug.cgi?id=21394) and using the Hin-Tak> example code Hin-Tak> http://msdn.microsoft.com/en-us/library/aa363778%28VS.85%29.aspx Hin-Tak> as reference, I have got a somewhat working solution, except if Hin-Tak> I follow the code, the WriteFile part for appending fails. Hin-Tak> Then I have cross-gcc compiling that example source code Hin-Tak> standard-alone, and the resulting executable won't append under Hin-Tak> wine cmd either. So it looks like either the example code is Hin-Tak> wrong, or wine's implementation of WriteFile() is a bit broken Hin-Tak> sometimes. I have determined the ReadFile succceeds and the Hin-Tak> SetFilePointer() also work) Hin-Tak> So I have two questions - (1) can somebody tell if there is Hin-Tak> something obviously wrong with the example, (2) can somebody Hin-Tak> say if it is because wine is not working e.g. SetPointer Hin-Tak> doesn't work? Register with the winetestbot, upload your test exe and compare the test output ... -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Winetest: What to do if NT4 behaves other then W2k and up
Wine Bug 21292 shows a problem with
CreateFileA("bla/n", GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL)
All winebot systems beside WNT4WSSP6 return ERROR_INVALID_NAME 123L, while
wine and NT4 happily open the file. How to proceed?
=== WNT4WSSP6 (NT4 Workstation SP6 (English, IE2)) ===
file.c:875: Test failed: CreateFileA failed on nonexist.ent/, hFile
00B4, err=0, should be 123
=== W2KPROSP4 (Windows 2000 Professional SP4) ===
No test failures found
=== WXPPROSP3 (XP Professional SP3 (English, IE6)) ===
No test failures found
=== W2K3R2SESP2 (Server 2003 R2 Standard Edition SP2) ===
No test failures found
=== WVISTAADM (Windows Vista (English, IE7)) ===
No test failures found
=== W2K8SE (Server 2008 Standard Edition) ===
No test failures found
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: MSVCRT: Handle \r at buffer boundary
>>>>> "Alexandre" == Alexandre Julliard writes:
Alexandre> Uwe Bonnes writes:
>> @@ -1767,6 +1771,12 @@ static int read_i(int fd, void *buf, unsigned
>> int count) if (MSVCRT_fdesc[fd].wxflag & WX_TEXT) { DWORD i, j; + if
>> (bufstart[num_read-1] == '\r') + { + if(pushback) +
>> MSVCRT__lseeki64(fd, -1, SEEK_CUR);
Alexandre> You can't use lseek for this, the file may not be seekable.
Would SetFilePointer() do the right job?
Thanks
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: Wine 64-bit in Fedora ...
>>>>> "Michael" == Michael Stefaniuc writes: Michael> Fedora includes now a 64-bit Wine package (at least in F11) Michael> which of course breaks existing Wine setups. "yum install wine" Michael> will install the 64-bit version... Looks like we had our Michael> WineConf too late for this. Michael> I have opened Michael> https://bugzilla.redhat.com/show_bug.cgi?id=533988 for this Michael> problem. Michael> The quick fix is to just remove the wine*.x86_64 rpms and Michael> install the wine*.i586 instead. Did nobody of the packages test what they did? -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Infinite loop with translation DLL
>>>>> "Henri" == Henri Verbeet writes: Henri> 2009/11/9 Uwe Bonnes : >> Can anybody help with the flaw in my implementation? Or did anything >> change in wine? >> Henri> I'm not sure if anything changed there recently, or if that's Henri> even supposed to work, but I suppose that one way to solve the Henri> problem would be to load the linux library dynamically with Henri> wine_dlopen() and explicitly load the entry points with Henri> wine_dlsym(). I wonder how it works in dll/glu32 or what is different in my approach? Marcus: Do you have an example that uses dll/glu32? -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Infinite loop with translation DLL
Hello,
around July 2009, I implemented a translation dll, allowing to run Win32
programms using ftd2xx.dll with Wine translating the calls to
linux-libftd2xx. It was done while looking at dll/glu32.
I was able to run mprog.exe (www.ftdichip.org) some time ago. Reapplying
now, I hit an infinite loop with the first translated call.
I short, ftd2xx.spec contains:
@ stdcall FT_ListDevices(ptr ptr long) FTD2XX_FT_ListDevices
and ftd2xx_main.c:
extern FT_STATUS FT_ListDevices(PVOID, PVOID, DWORD);
FT_STATUS WINAPI FTD2XX_FT_ListDevices(
PVOID pArg1,
PVOID pArg2,
DWORD Flags
)
{
FT_STATUS res = FT_ListDevices(pArg1, pArg2, Flags);
TRACE("res %s\n", res2string(res));
return res;
}
and dlls/ftd2xx/Makefile.in contains:
EXTRALIBS = @FTD2XXLIBS@
with EXTRALIBS detected in configure.ac.
MProig.exe calls FT_ListDevices(), which is resolves as
FTD2XX_FT_ListDevices(). Then
FTD2XX_FT_ListDevices() is entered and FT_ListDevices() resolves again to
FTD2XX_FT_ListDevices(), resulting in an infinite loop.
Can anybody help with the flaw in my implementation? Or did anything change
in wine?
The patches still linger on the mailing-list as "Stub implementation for
ftd2xx.dll"
Thanks
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Add-stub-for-IoOpenDeviceRegistryKey-needed-for-l.patch
Appended stup is needed for libusb-win32-0.1x
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
>From 7216b1e26b9cbd3d4bb7eaa096757ad11d0b77b5 Mon Sep 17 00:00:00 2001
From: Uwe Bonnes
Date: Tue, 9 Jun 2009 16:41:09 +0200
Subject: Add stub for IoOpenDeviceRegistryKey(), needed for libusb-win32-0.1.2
---
dlls/ntoskrnl.exe/ntoskrnl.c| 11 +++
dlls/ntoskrnl.exe/ntoskrnl.exe.spec |2 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c
index 5a043e5..99c2847 100644
--- a/dlls/ntoskrnl.exe/ntoskrnl.c
+++ b/dlls/ntoskrnl.exe/ntoskrnl.c
@@ -2493,6 +2493,17 @@ NTSTATUS WINAPI PsSetCreateThreadNotifyRoutine(
PCREATE_THREAD_NOTIFY_ROUTINE No
/***
+ * IoOpenDeviceRegistryKey (NTOSKRNL.EXE.@)
+ */
+NTSTATUS WINAPI IoOpenDeviceRegistryKey( PDEVICE_OBJECT DeviceObject,
+ULONG DevInstKeyType, ACCESS_MASK DesiredAccess, PHANDLE DevInstRegKey)
+{
+FIXME( "stub:\n");
+return STATUS_SUCCESS;
+}
+
+
+/***
* MmGetSystemRoutineAddress (NTOSKRNL.EXE.@)
*/
PVOID WINAPI MmGetSystemRoutineAddress(PUNICODE_STRING SystemRoutineName)
diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec
b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec
index 52efd92..cda9230 100644
--- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec
+++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec
@@ -409,7 +409,7 @@
@ stdcall IoIsWdmVersionAvailable(long long)
@ stub IoMakeAssociatedIrp
@ stub IoOpenDeviceInterfaceRegistryKey
-@ stub IoOpenDeviceRegistryKey
+@ stdcall IoOpenDeviceRegistryKey (long long long long)
@ stub IoPageRead
@ stub IoPnPDeliverServicePowerNotification
@ stub IoQueryDeviceDescription
--
1.6.0.2
Re: Latest git fails compiling
>>>>> "Ben" == Ben Klein writes:
Ben> 2009/6/9 Uwe Bonnes :
>> Hello,
>>
>> on a fresh tree check out and compiled successfully yesterday
>> (090608) and updated today(090609), compile fails with:
>>
>> make[1]: Entering directory
>> `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' ../tools/widl/widl
>> -I. -I. -I../include -I../include \ -h -H activaut.h activaut.idl
>> ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H
>> activdbg.h activdbg.idl ../tools/widl/widl -I. -I. -I../include
>> -I../include \ -h -H activscp.h activscp.idl oaidl.idl:121: error:
>> parameter 'pvData' of (null) 'tagSAFEARRAY' \ cannot derive from void
>> * make[1]: *** [activscp.h] Fehler 1 make[1]: Leaving directory
>> `/media/sda8/sdb8/spare/bon/Wine/wine-git/include'
>>
>> This is on Suse 11.1, x86-64. I have not seens this reported
>> before. Any hints for fixing (perhaps my setup)?
Ben> Please provide the git revision number, not just the date.
Trying to run "git bisect" and going back to
de945384a4c1f593820e91811c1c04ff0263ca48 (the number gitk reports in the
topmost entry) now everything compiled fine. Strange...
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Latest git fails compiling
Hello, on a fresh tree check out and compiled successfully yesterday (090608) and updated today(090609), compile fails with: make[1]: Entering directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H activaut.h activaut.idl ../tools/widl/widl -I. -I. -I../include -I../include\ -h -H activdbg.h activdbg.idl ../tools/widl/widl -I. -I. -I../include -I../include\ -h -H activscp.h activscp.idl oaidl.idl:121: error: parameter 'pvData' of (null) 'tagSAFEARRAY' \ cannot derive from void * make[1]: *** [activscp.h] Fehler 1 make[1]: Leaving directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' This is on Suse 11.1, x86-64. I have not seens this reported before. Any hints for fixing (perhaps my setup)? -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Status of "USB device support in wine"
Hallo, I tried to run Alexander Morozov's patches against wine-git with libusb and ftd2x devices. Two remarks: - The files from ftp://ftp.etersoft.ru/pub/people/amorozov/usb/current/ miss lines in configure.ac to trigger the Makefile generation for usbd.sys and usbhub.sys. - The HardwareID in the registry is the end of the Registry key http://msdn.microsoft.com/en-us/library/dd568018.aspx You can use the string itself in the win registry. This helps, if you don't have the devices installed on a windows machine available. Both dll/drivers pair (libusb0.dll/libusb0.sys and ftd2xx.dll/ftdibus.sys) work an a lot devices and so must scan the bus for matching devices. I didn't get wine with the patches to do anything sensible in that case. Alexander, could you perhaps have a look (ftd2xx at http://www.ftdichip.com/Drivers/D2XX.htm and libusb-win32 at sourceforge) Thanks -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Loading of Mingw Provided .sys files
>>>>> "Alexander" == Alexander Morozov writes:
>> trying to use the supplied or the mingw (cross) compiled libusb0.sys
>> from sourceforge with the USB enabled tree from
>> http://git.etersoft.ru/people/lav/packages/wine.git
>>
>> loading libusb0.sys fails:
Alexander> Drivers built with WinDDK is not page-aligned and
Alexander> (nt->OptionalHeader.SectionAlignment <= page_mask) is true
Alexander> for them. But libusb0.sys is page-aligned: $ winedump
Alexander> libusb0.sys | grep section section align 0x1000 4096
Alexander> See map_image() in dlls/ntdll/virtual.c:
Alexander> /* check for non page-aligned binary */
Alexander> if (nt->OptionalHeader.SectionAlignment <= page_mask) {
Alexander> /* unaligned sections, this happens for native subsystem
Alexander> binaries */ /* in that case Windows simply maps in the whole
Alexander> file */ ... goto done; }
The libusb-win32 Makefile sets the -shared Linker option, This results in
the DLL attribute set:
(from i386-mingw32msvc-objdump -x)
Characteristics 0x230e
executable
line numbers stripped
symbols stripped
32 bit words
debugging information removed
DLL
and DriverEntry being called as DllMain without the storage for the
DriverObject.
Removing the -shared Linker option from the Makefile lets libusb0.sys at
least load. No time fort further tests yet.
Bye
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Loading of Mingw Provided .sys files
Hello,
trying to use the supplied or the mingw (cross) compiled libusb0.sys from
sourceforge with the USB enabled tree from
http://git.etersoft.ru/people/lav/packages/wine.git
loading libusb0.sys fails:
trace:winedevice:ServiceMain starting service L"libusb0"
trace:winedevice:load_driver loading driver
L"c:\\windows\\system32\\drivers\\libusb0.sys"
trace:winedevice:load_driver_module name
L"c:\\windows\\system32\\drivers\\libusb0.sys" module (nil)
trace:winedevice:ServiceMain driver L"libusb0" failed to load
trace:winedevice:ServiceMain service L"libusb0" stopped
Using some other USB driver instead of libusb0.sys at least loads:
trace:winedevice:load_driver loading driver
L"c:\\windows\\system32\\drivers\\ezusb.sys"
trace:winedevice:load_driver_module name
L"c:\\windows\\system32\\drivers\\ezusb.sys" module 0x8134
trace:winedevice:load_driver_module
L"c:\\windows\\system32\\drivers\\ezusb.sys": relocating from 0x1 to
0x8134
trace:winedevice:load_driver_module name L"NTOSKRNL.EXE" module 0x84b7
trace:winedevice:load_driver_module name L"HAL.DLL" module 0x8459
trace:winedevice:load_driver_module name L"USBD.SYS" module 0x8458
trace:winedevice:init_driver
trace:winedevice:init_driver init done for L"libusb0" obj 0x84c0a560
The failure happens in program/winedevices/devices.c:
static HMODULE load_driver_module( const WCHAR *name )
{
IMAGE_NT_HEADERS *nt;
const IMAGE_IMPORT_DESCRIPTOR *imports;
size_t page_size = getpagesize();
int i, delta;
ULONG size;
--> HMODULE module = LoadLibraryW( name );
if (!module) return NULL;
LoadLibraryW loads the file and then calls the DriverEntry of libusb0:
NTSTATUS DDKAPI DriverEntry(DRIVER_OBJECT *driver_object,
UNICODE_STRING *registry_path)
{
int i;
DEBUG_MESSAGE("DriverEntry(): loading driver");
/* initialize global variables */
debug_level = LIBUSB_DEBUG_MSG;
/* initialize the driver object's dispatch table */
for(i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
{
driver_object->MajorFunction[i] = dispatch;
}
driver_object->DriverExtension->AddDevice = add_device;
driver_object->DriverUnload = unload;
return STATUS_SUCCESS;
}
While loading, the protection is set to
0014:trace:virtual:VIRTUAL_DumpView 0x6864 - 0x68640fff c-r--
and driver_object is in the 0x6864 pages and so writing to
driver_object->MajorFunction[i] through an exception and the function fails.
I guess libusb0.sys works on WIN32, so here our loader does something wrong
or perhaps is not bug-to-bug compatible.
Any fixes?
Thanks
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Status of "USB device support in wine"
Hello, Alexander Morozov did a large redesign after Alexandre's remarks from 07 October 2008. What is still needed to include this functionality? Thanks -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Status of USB driver support?
>>>>> "Alexander" == Alexander Morozov writes: Alexander> Minor updated patches: Alexander> ftp://ftp.etersoft.ru/pub/people/amorozov/usb/1.1.15/0001-Add-support-of-native-Windows-drivers-for-USB-tokens.txt Alexander> ftp://ftp.etersoft.ru/pub/people/amorozov/usb/1.1.15/0002-Re-generate-some-files.txt Please, be more verbose. What should we expect to work with your patch now? What kind of applications can be get to work with your modifications when completed? What application did you test? Anything more needed? E.g. I have FTDI devices, using ftd2xx.dll. Can I expect to get them working? Thanks -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Fully automated bisecting with "git bisect run" [LWN.net]
>>>>> "Ben" == Ben Klein writes: Ben> 2009/2/11 nn : >> Fully automated bisecting with "git bisect run" [LWN.net]: >> http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/ >> >> Would this be useful to add to the instructions on the wine wiki. >> Ben> If I understand this correctly, this is only useful when the Ben> regression is something that can be tested without human Ben> interaction. This makes it virtually useless for Wine, as most Ben> regressions involve loss of functionality some application. Ben> However, it could theoretically be useful for regressions that Ben> cause a complete crash of the application early on. Would it be any Ben> faster? Probably not. Fewer commands to type, since you wouldn't Ben> need to run "git bisect bad" or "git bisect good" every time you Ben> test the app. It should work it there is a test in the test suite too -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: include: Change some DWORD to DWORD_PTR in msacm.h.
>>>>> "Michael" == Michael Stefaniuc writes: Michael> The change is for Win64 compatibility and it matches the DDK. -MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD dwInstance, DWORD fdwEnum) +MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD_PTR dwInstance, DWORD fdwEnum) Is the spec aentry then still right? ./dlls/msacm32/msacm32.spec:@ stdcall acmDriverDetailsW(long ptr long) -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: MSVCRT: Still problems in ASCII Mode
>>>>> "Dan" == Dan Kegel writes:
Dan> Thanks. Please don't use rand() in testcases, though. Would a
Dan> constant 'a' suffice in this case?
Dan> Which app did you find this in, btw?
It the application that can be downloaded for free after registration on
http://forms.analog.com/form_pages/rfcomms/adisimpll.asp?ref=ASC-PR-067
running the tutorial
Appended a changed test case, writing one single line. It starts to fail
when the file, including CR and LF gets bigger then 512 bytes. This hits
probably
/* in text mode, strip \r if followed by \n.
* BUG: should save state across calls somehow, so CR LF that
* straddles buffer boundary gets recognized properly?
*/
It is not clear, if this is the real cause for the simpll.exe failure.
Bye
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
diff --git a/dlls/msvcrt/tests/file.c b/dlls/msvcrt/tests/file.c
index 9032e51..cd377af 100644
--- a/dlls/msvcrt/tests/file.c
+++ b/dlls/msvcrt/tests/file.c
@@ -306,7 +306,7 @@ static void test_asciimode(void)
{
FILE *fp;
char buf[64];
-int c, i, j;
+int c, i, j, done, count1, count2;
/* Simple test of CR CR LF handling. Test both fgets and fread code
paths, they're different! */
fp = fopen("ascii.tst", "wb");
@@ -372,6 +372,44 @@ static void test_asciimode(void)
ok((c = fgetc(fp)) == '1', "fgetc fails to read next char when positioned
on \\r\n");
fclose(fp);
+fp= fopen("ascii.tst","wb");
+for (i=0; i<511; i++)
+ {
+ fputc('a', fp);
+ }
+fputs("\r\n", fp);
+fclose(fp);
+
+done = 0;
+count1 = 0;
+
+fp = fopen("ascii.tst", "r");
+while (!done)
+ {
+ c= fgetc(fp);
+ if (c == EOF)
+ done = 1;
+ else if (isgraph(c))
+ count1 ++;
+ }
+fclose(fp);
+
+done = 0;
+count2 = 0;
+
+fp = fopen("ascii.tst", "r");
+while (!done)
+ {
+ c= fgetc(fp);
+ fseek(fp, 0, SEEK_CUR);
+ if (c == EOF)
+ done = 1;
+ else if (isgraph(c))
+ count2 ++;
+ }
+fclose(fp);
+todo_wine ok((count1 == count2), "fseek caused short read %d vs %d\n",
count2, count1);
+
unlink("ascii.tst");
}
Another MSVCRT problem, perhaps __RTDynamicCast()
Hello,
after registering at
http://forms.analog.com/form_pages/rfcomms/adisimpll.asp?ref=ASC-PR-067
you can download ADIsimPLL Version 3.1 for free. Running the program (with
richedit from winetricks) it offers to run a tutorial. In the course of
clicking next in this tutorial, at some point some form gets filled with \
nonsense double values. This doesn't happen with native msvcrt.
I have instrumented msvcrt._ecvt() to print out the number. The number
printed is the nonsens number in the form.
Appended +relay,+msvcrt looks fishy:
0023:Call msvcrt.__RTDynamicCast(006f7a58,,00543030,00544838,)
ret=0044019e
trace:msvcrt:MSVCRT___RTDynamicCast obj: 0x6f7a58 unknown: 0 src: 0x543030
{vtable=0x521568 name=.?AVYASymbol@@ ()} dst: 0x544838 {vtable=0x521568
name=.?AVLibDouble@@ ()} do_throw: 0)
trace:msvcrt:dump_obj_locator 0x524218: sig= base_offset=
flags= type=0x544838 {vtable=0x521568 name=.?AVLibDouble@@ ()}
hierarchy=0x524208
trace:msvcrt:dump_obj_locator hierarchy: sig= attr= len=3
base classes=0x5241f8
trace:msvcrt:dump_obj_locator base class 0x5241e0: num 2 off 0,-1,0 attr
type 0x544838 {vtable=0x521568 name=.?AVLibDouble@@ ()}
trace:msvcrt:dump_obj_locator base class 0x524190: num 1 off 0,-1,0 attr
type 0x544818 {vtable=0x521568 name=.?AVLibVariable@@ ()}
trace:msvcrt:dump_obj_locator base class 0x5234d8: num 0 off 0,-1,0 attr
type 0x543030 {vtable=0x521568 name=.?AVYASymbol@@ ()}
0023:Ret msvcrt.__RTDynamicCast() retval=006f7a58 ret=0044019e
0023:Call msvcrt._ecvt(0001,5f40255f,000a,00328dd4,00328ddc)
ret=0040a952
0023:Call KERNEL32.TlsGetValue() ret=7ec3e471
0023:Ret KERNEL32.TlsGetValue() retval=001b0678 ret=7ec3e471
trace:msvcrt:_ecvt num
6606512752554031389059083466263841847175093544956949844249843220093860018640324866\
420498348423671822060046924282328257865959227190774155226910868635648.00,
digits 10
0023:Call ntdll.RtlAllocateHeap(0011,,0050) ret=7ec2de07
0023:Ret ntdll.RtlAllocateHeap() retval=006e4550 ret=7ec2de07
0023:Ret msvcrt._ecvt() retval=006e4550 ret=0040a952
I suspect __RTDynamicCast() to cause the error. Having not much C++
understanding, I don't feel like writing a sensible testcase. Can anybody
perhaps have a look?
Thanks
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode
>>>>> "Dan" == Dan Kegel writes:
Dan> That's how we used to do it, but tests showed that _filbuf really
Dan> has to do the cr removal.
Dan> On Jan 25, 2009 10:57 AM, "Uwe Bonnes" <
Dan> b...@elektron.ikp.physik.tu-darmstadt.de> wrote:
>>>>> "Dan" == Dan Kegel writes:
Dan> I'll have a look...
Dan> For me it looks like our whole black magic handling for the CR
Dan> removal in read_i() is wrong. Probably _filbuf() should fill the
Dan> buffer as is, only fget(w)c() should skip CR in text mode and
Dan> fread() in binary mode should use unaltered chunks of _filbuf() in
Dan> binary mode and iterate through _filbuf() in text mode, skipping
Dan> CR.
Could it be that _filbuf also skips CR as return value in text mode?
B.t.w., for a file like "\\r\\r\\r\\nEOF", native _filbuf returns 0x0d...
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Serial Fixes
Hello Wolfgang, nice findings and fixes around the serial driver! What application do you test against? Bye -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Serial port support in wine-1.0: What to do to make it working ?
>>>>> "Pavel" == Pavel Troller <[EMAIL PROTECTED]> writes: Pavel> Hi! I have really BIG problems running any application, which Pavel> needs to comm over a serial port: - My ham TCVR - My GPS - My Pavel> multimeter - A lot of my mobiles - A lot of devices used in my Pavel> work (special telco equipment, comms varying from simple AT-style Pavel> commands up to complex proprietary binary protocols). In all the Pavel> cases there are very similar problems - either the program Pavel> doesn't detect the device properly, or the device doesn't Pavel> respond, or in some cases the device does, what the program Pavel> wants, but it then can't read it back. It looks that some Pavel> archaic wine versions are better, for example I have to use Pavel> wine-0.9.40 to communicate with a device in my work (simple Pavel> text-based command-reply communication), any wine newer than say Pavel> 0.9.50 doesn't work, the communication times out. Because I'm a Pavel> telco engineer and serial comm is my daily work, and there are Pavel> only windows versions of many tools I have to use, proper and Pavel> mature serial port support is essential for me. So, what can I Pavel> do to help fixing these problems ? Should I open a bug for every Pavel> such a program ? Or just open one bug and state all the programs Pavel> there ? I think that bugzilla contains a lot of bugs related to Pavel> serial port; is it good to add a new ones ? I'm afraid I can't Pavel> bisect a problem between 0.9.40 and current wine, but I can make Pavel> a serial trace for both of them and look at the difference. Would Pavel> it help to find at least this one particular problem ? Or what Pavel> more can I do to make the serial port working ? I can code in C Pavel> in the Linux environment, but I know NOTHING about windows... Pavel> With regards, Pavel Troller Pavel, perhaps compile wine yourself and instrument the serial code with debugging output. Try to see what's going wrong. Look at the codes where this happens and read the old changelogs, where somebody fiddled witrh the code. Ask about what people thought (or smoked) when implementing or offer a better implementation. There is a big problem with those special devices, as only few if any wine developpers have it... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Implementation of D3DXGetFVFVertexSize with tests
>>>>> "David" == David Adam <[EMAIL PROTECTED]> writes: ... David> What is the purpose of the line David> + ok(TRUE,"prueba"); ? "prueba" could be spanish for test. David> David Hello,to keep the code readable, you should put Please, no HTML in mails -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
OUTB() and friends on Win32 and .sys files(Resent)
Hallo, some programm with source uses giveio.sys to access the parallel port. You can find the source for giveio.sys e.g. in the avrdude package. We have code in dlls/winedos/ppdev.c to emulate the directed access on the parallel port to accesses to /dev/ppdev. However this code is not called for WIN32 code. So after starting giveio with loaddrv.exe supplied with giveio > wine loaddrv.exe start giveio starting giveio... ok. > wine javr.exe crashes when the outb access happens: javr [] [-p] [-f] [-e] [-L] [-V] Allocated flash buffer of 128K Using giveio.sys to gain port access to 0x378 trace:seh:raise_exception code=c096 flags=0 addr=0x4014b6 trace:seh:raise_exception eax= ebx= ecx=0378 edx=0378 esi=0378 edi=00110388 trace:seh:raise_exception ebp=0072fe50 esp=0072fe50 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7eddc5bc code=c096 flags=0 trace:seh:MSVCRT_signal (4, (nil)) wine: Unhandled privileged instruction at address 0x4014b6 (thread 0011), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 16 56" trace:seh:call_stack_handlers handler at 0x7eddc5bc returned 1 Unhandled exception: privileged instruction in 32-bit code (0x004014b6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:004014b6 ESP:0072fe50 EBP:0072fe50 EFLAGS:00010246( - 00 -RIZP1) EAX: EBX: ECX:0378 EDX:0378 ESI:0378 EDI:00110388 Stack dump: 0x0072fe50: 0072fe58 0040151a 0072fe88 00406ccf 0x0072fe60: 0378 00403411 0x0072fe70: 0001 00110388 0072fe88 0040a3ef 0x0072fe80: 0040a3ef 0001 0072fec8 004025e4 0x0072fe90: 0378 0378 00110048 0040255c 0x0072fea0: 7ed5ff48 7ffdf000 0072fec8 7ed30f5c Backtrace: =>1 0x004014b6 outb+0x6(value=0x0, port=0x378) [/spare/bon/jtagprog/win/javr-2.8/ppiwin.c:311] in javr (0x0072fe50) MS msvcrt.dll also supplies outb(). What is the policy to handle outb() and friends? Thanks -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
OUTB() and friends on Win32 and .sys files
Hallo, some programm with source uses giveio.sys to access the parallel port. You can find the source for giveio.sys e.g. in the avrdude package. We have code in dlls/winedos/ppdev.c to emulate the directed access on the parallel port to accesses to /dev/ppdev. However this code is not called for WIN32 code. So after starting giveio with loaddrv.exe supplied with giveio > wine loaddrv.exe start giveio starting giveio... ok. > wine javr.exe crashes when the outb access happens: javr [] [-p] [-f] [-e] [-L] [-V] Allocated flash buffer of 128K Using giveio.sys to gain port access to 0x378 trace:seh:raise_exception code=c096 flags=0 addr=0x4014b6 trace:seh:raise_exception eax= ebx= ecx=0378 edx=0378 esi=0378 edi=00110388 trace:seh:raise_exception ebp=0072fe50 esp=0072fe50 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7eddc5bc code=c096 flags=0 trace:seh:MSVCRT_signal (4, (nil)) wine: Unhandled privileged instruction at address 0x4014b6 (thread 0011), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 16 56" trace:seh:call_stack_handlers handler at 0x7eddc5bc returned 1 Unhandled exception: privileged instruction in 32-bit code (0x004014b6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:004014b6 ESP:0072fe50 EBP:0072fe50 EFLAGS:00010246( - 00 -RIZP1) EAX: EBX: ECX:0378 EDX:0378 ESI:0378 EDI:00110388 Stack dump: 0x0072fe50: 0072fe58 0040151a 0072fe88 00406ccf 0x0072fe60: 0378 00403411 0x0072fe70: 0001 00110388 0072fe88 0040a3ef 0x0072fe80: 0040a3ef 0001 0072fec8 004025e4 0x0072fe90: 0378 0378 00110048 0040255c 0x0072fea0: 7ed5ff48 7ffdf000 0072fec8 7ed30f5c Backtrace: =>1 0x004014b6 outb+0x6(value=0x0, port=0x378) [/spare/bon/jtagprog/win/javr-2.8/ppiwin.c:311] in javr (0x0072fe50) MS msvcrt.dll also supplies outb(). What is the policy to handle outb() and friends? Thanks -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: gitignore: ignore files generated by the Visual C++ compiler.
>>>>> "Dmitry" == Dmitry Timoshkov <[EMAIL PROTECTED]> writes: Dmitry> "Reece Dunn" <[EMAIL PROTECTED]> wrote: >> This patch ignores any files generated by the Visual C++ compiler to >> make it easier to generate patches when using the VCExpress family of >> compilers on Windows. Dmitry> There is no point in that, patches should be generated after Dmitry> testing in Wine under a supported platform. That sounds like a Microsoft requirement... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: advapi32/service.c -- remove untriggerable check
>>>>> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
Gerald> n is of type DWORD which is unsigned, so n < 0 always will
Gerald> evaluate to false.
Gerald> Gerald
Gerald> ChangeLog: Remove untriggerable check.
Gerald> Index: dlls/advapi32/service.c
Gerald> ===
Gerald> RCS file: /home/wine/wine/dlls/advapi32/service.c,v retrieving
Gerald> revision 1.160 diff -u -3 -p -r1.160 service.c ---
Gerald> dlls/advapi32/service.c 15 Oct 2007 16:29:59 - 1.160 +++
Gerald> dlls/advapi32/service.c 18 Nov 2007 06:01:28 - @@ -2107,9
Gerald> +2107,6 @@ QueryServiceConfigW( SC_HANDLE hService, n -=
Gerald> sizeof(WCHAR); }
Gerald> - if( n < 0 ) - ERR("Buffer overflow!\n"); - TRACE("Image path =
Gerald> %s\n", debugstr_w(lpServiceConfig->lpBinaryPathName) );
Gerald> TRACE("Group = %s\n",
Gerald> debugstr_w(lpServiceConfig->lpLoadOrderGroup) );
Gerald> TRACE("Dependencies = %s\n",
Gerald> debugstr_w(lpServiceConfig->lpDependencies) );
Is dropping the check the right answer? Shouldn't the check test for high
values like > 0xff00 and report a possible problem?
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: server: Make timer id allocation algorithm conform to the Windows one
>>>>> "Dmitry" == Dmitry Timoshkov <[EMAIL PROTECTED]> writes: Dmitry> Hello, this patch should fix the problem reported in the bug Dmitry> 10343. My test which calls SetTimer in an infinite loop shows Dmitry> that XP starts to allocate timer ids at 0x7fff and goes Dmitry> backwards to 0x101, then restarts from 0x7fff. Isn't this worth a test suite case? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
RE: icmp states I need to be running wine as root
>>>>> "EA" == EA Durbin <[EMAIL PROTECTED]> writes: ... EA> I can ping in linux without being a superuser? Isn't there another EA> way to do this than with SOCK_RAW, or having to run wine as root? > ls -l /bin/ping -rwsr-xr-x 1 root root 39496 25. Nov 2006 /bin/ping ping is suid root. Can we perhaps translate a lot of icmp.dll calls via ping? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
WOAFONT needed
Hello, http://dmt.mhilfe.de/ is a tool to read out DSL-line parameters. The windows version knows about a lot of DSL Modems, while a linux rewrite only knows of a small amount of modems. Running as root, because of an ICMP call in the program to find the DSL modem in the network, the program runs fine. However the font is unreadable small. The author uses the app850.fon font, which seems to cause a lot of trouble in windows too. However the cures given in the webpage (put the font into windows/fonts and add [386enh] [woafont=app850.FON]) don't help for me. wine/dlls/gdi32/freetype.c also talks about the app850 font, however neither gives a hint usefull for me. Any ideas? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
re: nhelp, Vector NTI, molecular biologists
>>>>> "Dan" == Dan Kegel <[EMAIL PROTECTED]> writes: Dan> Misha wrote: >> and even my version of Windows 98 is bundled with mfc42.dll, so wine >> really should provide it too... [our own version, not Microsoft's.] Dan> Well, sure. Same goes for a lot of things. But since mfc42.dll is Dan> a Visual C++ runtime file that has very liberal redistribution Dan> terms and is in fact bundled with many apps, we can get away Dan> without it for a long time. And it's not currently a showstopper Dan> as far as I can tell; I'm more interested in the bugs that keep Dan> e.g. Photoshop from running flawlessly. Dan> So one of these days it might become a priority. Until then, it's Dan> merely important but not urgent. - Dan Missing MFC42 and other redistributable DLLs is a showstopper for winelib and running windows code on non i386 archtecture... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: mapi32: Add DebugInfo to critical sections.
>>>>> "Jan" == Jan Zerebecki <[EMAIL PROTECTED]> writes: Jan> --- If this patch is rejected from inclusion, please tell me why, Jan> as I would have to ask anyway. Nice disclaimer ;-) I wonder if it works? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Memory checking?
>>>>> "Giles" == Giles Cameron <[EMAIL PROTECTED]> writes: Giles> Ok. I am just entering the WINE development crowd, and have very Giles> very little experiance with the Windows API (The first time I saw Giles> it, I was terrifyed!) Anywho. It would appear that some programs Giles> decide there isn't enough free memory available for their tasks Giles> (EG, Train Simulator's CAB extaction process, I have yet to look Giles> further into this to see if I even have the slightest clue what I Giles> am talking about, however) so I was wondering if we could hack in Giles> an option to allow the API to tell a little fib on the free Giles> memory, since (From what I understand) Linux is so much better Giles> with memory. This is an old issue. Some programs find _some_error and decide to report it as "out-of-memory" error. Mostly totally misleading... Look for the first error and cure it. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: wine.inf: Update the timezone information.
>>>>> "Francois" == Francois Gouget <[EMAIL PROTECTED]> writes: Francois> --- I have used two sources to update Wine's timezone data: ... Francois> The display name was set to the Olson database ids and I have Francois> kept it that way as it seems to match what is displayed on Francois> Linux. Wherever we used old names I switched to the new names Francois> as specified in the Olson database. Francois> We still have a few differences with the Windows data and in a Francois> few instances I diverged from the CLDR mapping to tzids. I Francois> will now summarize all these differences in bug 7295. How do internaltional version of Windows get the localized names of the pletora of timezones? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Error in ntdll/module.c?
>>>>> "Christian" == Christian Iversen <[EMAIL PROTECTED]> writes: Christian> (Please CC me, I'm not on the list) Christian> According to: Christian> http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Executable%20Images/LdrGetProcedureAddress.html Christian> The parameter order for LdrGetProcedureAddress is (Handle, Christian> Function, Ordinal, Address) Christian> The file dlls/ntdll/module.c has the order as (Handle, Christian> Ordinal, Function, Address) Christian> This of course works well because kernel32.dll is the only Christian> caller (and it indeed uses, if not the correct, then at least Christian> the same order). Christian> I haven't attached a patch, because I'm not actually sure Christian> which version is right. Anyone? Write a test for our test suite and run the test on wine and a windows machine. Send at least the test. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: direct access to IO space [Was: kernel level drivers - next try]
>>>>> "James" == James Courtier-Dutton <[EMAIL PROTECTED]> writes: James> This feature is being ask for by people who don't understand what James> most hardware requires from a "driver". 1) IO ports or memory James> mapped IO. 2) DMA handler 3) IRQ handler James> Getting IO port access in wine really is not going to help a James> whole lot! For a lot of programms used to program electronic devices, IO port access under wine would help a lot! -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: wine and serial port - again
>>>>> "Pavel" == Pavel Troller <[EMAIL PROTECTED]> writes: Pavel> Hi! From time to time, complaints can be heard about Pavel> functionality of the serial port implementation in wine. Just now Pavel> I have one of examples of the serial communication problem. Pavel> There is a very simple program, called ft or softjump, intended ... Pavel> My Linux variant is attached to this mail. Sorry for the lengthy Pavel> mail, but I hope that it can really help to improve the serial Pavel> communication support in wine. With regards, Pavel Troller Pavel, do you have a scope? Can you look what physically happens on the serial line? Does the program via wine actually write out the challange? Does the the device react to the challange? Whats the delay between challange and response? I suspect something with our wait implementation to go wrong. The program immediate does a read after the write, and doesn't repeat the read if 0 characters are read. So if the device reacts slow, the read will be to early. Can you try to put a Sleep() between the Readfile() and the Writefile() in the windows program? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: msvcrt[2/3]: add initial tests for dlls/msvcrt/data.c [try 2]
>>>>> "Andrew" == Andrew Ziem <[EMAIL PROTECTED]> writes: Andrew> because tests yield inconsistent results */ +#if 0 + /* address #if 0 in a patch is depreciated. If the test fails on wine, butt succeeds in windows, use todo_wine(). If there are other conditions that must be met, tell these conditions, perhaps like #define SOME_SPECIAL_TEST 0 #ifdef SOME_SPECIAL_TEST so that others can decipher what you mean. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: How are we doing?
>>>>> "Michael" == Michael Stefaniuc <[EMAIL PROTECTED]> writes: Michael> P.S.: Let the flame war begin. ;) Isn't it already raginh ;-) -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: comdlg32: Janitorial: write-strings warning fix
>>>>> "Michael" == Michael Stefaniuc <[EMAIL PROTECTED]> writes: Michael> Uwe Bonnes wrote: >>>>>>> "Andrew" == Andrew Talbot <[EMAIL PROTECTED]> >>>>>>> writes: >> Andrew> Changelog: Janitorial: Fix a write-strings compiler warning in Andrew> dlls/comdlg32/printdlg.c >> What is a "white-string" warning? Michael> Where have you seen the wHite-string? I see only wRite-string Michael> in his email. Argh, I have to clean my glasses ;-) -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: comdlg32: Janitorial: write-strings warning fix
>>>>> "Andrew" == Andrew Talbot <[EMAIL PROTECTED]> writes: Andrew> Changelog: Janitorial: Fix a write-strings compiler warning in Andrew> dlls/comdlg32/printdlg.c What is a "white-string" warning? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Still missing glyph
Hallo, even with a recent fontforge, I get "Missing glyph for": fontforge -script ../fonts/genttf.ff small_fonts.sfd small_fonts.ttf Copyright (c) 2000-2006 by George Williams. Executable based on sources from 19:18 13-Apr-2006. ../tools/widl/widl -I. -I. -I../include -I../include-h -H amstream.h amstream.idl LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt system.ttf 16 932 96 128 7 LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt small_fonts.ttf 11 1252 96 128 5 LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt small_fonts.ttf 11 1250 96 128 5 LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt small_fonts.ttf 11 1253 96 128 5 Missing glyph for char 0385 Missing glyph for char 0386 ... Is this expected behaviour? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
[0.9.13]Dynamic drive configuration using HAL?
Hallo, I don't find any explanation or usage hints on wine-devel. Thanks -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: [Wine] Wine + serial port basically hangs system
>>>>> "Eric" == Eric Pouech <[EMAIL PROTECTED]> writes: Eric> Uwe Bonnes wrote: >> Hallo, >> >> this is a thread from wine-users. I think further discussion of this >> issue is better done on wine-devel. >> >> In short, Dan Armbrust notices some application (heavy weather.exe) >> accessing the serial port causing a high system load. As the >> application uses WaitCommEvent, I fear that my implementation of >> WaitCommEvent is inappropriate. In my last posting, I ask Dan to >> count the calls to WaitcommEvent by counting the number of lines >> containing WaitCommEvent in a relay log. His results are: Eric> the preferred way is of course to do the wait operation in the Eric> server (or at least the trigger in the server, and the handling of Eric> the trigger can be done on client side) A+ But the server is always at the limit of capabilities. I don't feel like I am to implement that capabilities.. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
What arguments to use to call winemenubuilder by hand?
Hallo, the error > err:menubuilder:extract_icon32 LoadLibraryExW\ > (L"C:\\altera\\quartus60\\win\\quartus.exe") failed, error 126 with varying file targets seems to be a common one. The one above happened with the current 0.9.12 and Altera's quartusii_60_web_edition.exe, running with XP-native ole32,oleaut32 and rpcrt4. Without these native dlls, installation hangs at an early stage. "Error 126" is > include/winerror.h:#define ERROR_MOD_NOT_FOUND 126 so I guess that winemenubuilder is invoked in an too early stage where the executables are not already deployed. I tried to decipher, what is calling winemenubuilder and when, but did't succeed. Google also wasn't a big help. Can anyone give a short explanation? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: [Wine] Wine + serial port basically hangs system
Hallo, this is a thread from wine-users. I think further discussion of this issue is better done on wine-devel. In short, Dan Armbrust notices some application (heavy weather.exe) accessing the serial port causing a high system load. As the application uses WaitCommEvent, I fear that my implementation of WaitCommEvent is inappropriate. In my last posting, I ask Dan to count the calls to WaitcommEvent by counting the number of lines containing WaitCommEvent in a relay log. His results are: >>>>> "Dan" == Dan Armbrust <[EMAIL PROTECTED]> writes: Dan> I let the app run for about 2 minutes, at the standard priority - Dan> basically until the system was about ready to take a dive :) Dan> Data was coming in to the program and being displayed before I Dan> killed it. Dan> The count on WaitCommEvent was 15051 - so I guess we would have Dan> 7526 calls to WaitCommEvent in < 2 minutes. It probably took the Dan> first 30 seconds just to get the app up and running, so that was Dan> maybe 90 seconds of actually accessing the serial port. As Dan's machine is not a "big iron one", I guess these about 7500 thread creation/termination in about 90 seconds could explain the high system load. In the moment, my implementation of WaitCommEvent creates a thread in the context of the running program for every call. Any ideas how to do it better? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Who is responsible to start up a Wineconsole
>>>>> "Eric" == Eric Pouech <[EMAIL PROTECTED]> writes:
Eric> Uwe Bonnes wrote:
>> Hallo,
>>
>> on XP, Program->Execute->(../system32/)telnet.exe starts up a
>> Console. "wine telnet.exe" on the command line however silently
>> terminates, as the call to GetConsoleScreenBufferInfo returns an
>> empty LPCONSOLE_SCREEN_BUFFER_INFO structure.
>>
>> Shouldn't wine start up some wineconsole in that circumstances as XP
>> does?
Eric> never guess what windows explorer does in your back... - the
Eric> right test sequence would be from a program where we know how
Eric> CreateProcess is called - wine behaves AFAIK as windows: it only
Eric> creates a console when it's asked to (either because of a specific
Eric> flag in CreateProcess(), or by calling AllocConsole()).
MSDN tells for AllocConsole that Console Application (CUI) are initialized
with a console (preloaded), unless they are created as a detached process.
If I understand the wine loader right, and didn't overlook something in the
relay log, the initial wine process doesn't start the first process by a
CreateProcess call. So no chance to fiddle withe the flags.
Shouldn't something like appended patch be comitted? The loader will check
for the CUI flag and allocate a Console, if needed.
Eric> your issue could also from a bad error / return value from
Eric> GetConsoleScreenBufferInfo() when no console is attached
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Index: wine/dlls/kernel/process.c
===
RCS file: /home/wine/wine/dlls/kernel/process.c,v
retrieving revision 1.137
diff -u -5 -r1.137 process.c
--- wine/dlls/kernel/process.c 7 Apr 2006 10:05:39 - 1.137
+++ wine/dlls/kernel/process.c 8 May 2006 15:16:12 -
@@ -760,10 +760,12 @@
if (!params->hStdError)
params->hStdError = INVALID_HANDLE_VALUE;
else if (VerifyConsoleIoHandle(console_handle_map(params->hStdError)))
params->hStdError = console_handle_map(params->hStdError);
+/* The starting process should get a new console, if it is a CUI
application*/
+params->ConsoleHandle = (HANDLE)1; /*FIXME*/
return TRUE;
}
/***
Re: Who is responsible to start up a Wineconsole
>>>>> "Andreas" == Andreas Mohr <[EMAIL PROTECTED]> writes: Andreas> Hi, On Mon, May 08, 2006 at 02:27:53PM +0200, Uwe Bonnes wrote: >> Hallo, >> >> on XP, Program->Execute->(../system32/)telnet.exe starts up a >> Console. "wine telnet.exe" on the command line however silently >> terminates, as the call to GetConsoleScreenBufferInfo returns an >> empty LPCONSOLE_SCREEN_BUFFER_INFO structure. >> >> Shouldn't wine start up some wineconsole in that circumstances as XP >> does? Andreas> Most likely telnet.exe has some console app PE header flag set Andreas> (as opposed to Win32 GUI app flag). > winedump dump -f telnet.exe | grep -i cui Subsystem 0x3 (Windows CUI) Andreas> Probably the Wine loader needs to actually handle this flag and Andreas> launch wineconsole in this case if it's not already started Andreas> within a console. Yes. I am just fiddling around with the loader... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Who is responsible to start up a Wineconsole
Hallo, on XP, Program->Execute->(../system32/)telnet.exe starts up a Console. "wine telnet.exe" on the command line however silently terminates, as the call to GetConsoleScreenBufferInfo returns an empty LPCONSOLE_SCREEN_BUFFER_INFO structure. Shouldn't wine start up some wineconsole in that circumstances as XP does? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Linuxtag06/Wiesbaden/Germany
Hallo, Stefan Maunz, Micheal Jung and me will present Wine at Linuxtag06/Wiesbaden/Germany. As a project we can send out invitations. If anybody is interested to receive an invitation, please let me know. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
RE: Using msvcmon to debug
>>>>> "Ryan" == Ryan Miller <[EMAIL PROTECTED]> writes: Ryan> I'm using Redhat ES 4. The wine version is: Wine 20050830. Does Ryan> this message typically get followed by an exception? 20050830 is _ages_ old. Try a recent version and report again. ... Ryan> Ryan> Please, no HTML in Mail. And please, no full quote neither... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Using msvcmon to debug
>>>>> "Ryan" == Ryan Miller <[EMAIL PROTECTED]> writes: Ryan> Hi, I've been using msvcmon previously to remote debug application Ryan> in Visual Studio on Wine. It's great to have an IDE to debug Wine Ryan> with the breakpoints and watch windows and all. I'm now using Ryan> Crossover Office Pro 5.0.1-1rc2 and msvcmon is no longer working. Ryan> I'm getting the log message (which is new): Ryan> epoll_ctl: Operation not permitted What distribution are you using? What wine version is involved? The "epoll_ctl: Operation not permitted" problem appeared now and then, but mostly only Suse Distribution was involved. If I remember right, the dll/kernel/test directory provoked such an error for me, but does not now, with a nearly up-to-date CVS wine on Suse 10.0 Ryan> Please, no HTML in Mail. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: AutoCAD in Linux
>>>>> "Richardson" == Richardson <[EMAIL PROTECTED]> writes: Richardson> Hello! Richardson> My name is Richardson and I am from Brazil and I am needing Richardson> to know how I can install the AutoCAD r14 and AutoCAD 2000 Richardson> in a machine turning Fedora 3. he/she would Like to know Richardson> which the versions of Wine and the links to lower, and also Richardson> as I will proceed with the installation of CAD's. I await Richardson> answers soon. Autocad is copy protexted software. There are no easy and legal ways to run those software in wine Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI
>>>>> "H" == H Verbeet <[EMAIL PROTECTED]> writes: ... >> Appended patch lets me circumvent that problem. H> I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are H> interchangeable, but more importantly it makes the same kind of H> assumptions about what's going to be defined. I said "circumvent" not "solve"... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
[Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI
Hallo,
compiling a recent CVS checkout, I go a failure with GL_STENCIL_BACK_FAIL
etc undefined. It seems that a patch from Vitaly regarding wined3d_gl.h from
yesterday evening as notor only partial applied.
Appended patch lets me circumvent that problem.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Index: wine/dlls/wined3d/device.c
===
RCS file: /home/wine/wine/dlls/wined3d/device.c,v
retrieving revision 1.145
diff -u -r1.145 device.c
--- wine/dlls/wined3d/device.c 4 Mar 2006 17:10:57 - 1.145
+++ wine/dlls/wined3d/device.c 5 Mar 2006 14:47:13 -
@@ -3773,9 +3773,9 @@
GLint action = StencilOp(Value);
-glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail);
-glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail);
-glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass);
+glGetIntegerv(GL_STENCIL_BACK_FAIL_ATI, &stencilFail);
+glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL_ATI, &depthFail);
+glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS_ATI, &stencilPass);
if(WINED3DRS_CCW_STENCILFAIL == State) {
stencilFail = action;
Design Decision? Code, Clone or Translate
Hallo, as stated by some bug entries, the msvcrt implementation of strtod() understands 'd' and 'D' in addition to 'e' and 'E'. I have stumbled apon places, where this is needed. The gnu implementation doesn't understand 'd' and 'D', so we need out own implemenation in msvcrt. I see three possibilities. Which is best suited? - Code it ourself - Clone the implemention from glibc or another open source libc with suitable license and make this cloned code understand d/D - Or clone the string, substitute d/D for e/E and call standard libc Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: NTDLL/loader.c: Remove spaces at end of name in import_dll
>>>>> "Vitaliy" == Vitaliy Margolen <[EMAIL PROTECTED]> writes:
Vitaliy> Saturday, February 18, 2006, 11:16:10 AM, Uwe Bonnes wrote:
>> Changelog: ntdll/loader.c import_dll() Remove spaces at end of name
>> retrieved with get_rva( module,
descr-> Name )
>> +/* Overwrite spaces at end of buffer with NULL */ +inline static
>> void skip_spaces(WCHAR *buffer, size_t len) +{ + while (buffer[len
>> -2] == (WCHAR)' ') + { + buffer[len -2] = 0; + len --; + } +}
Vitaliy> This is wrong (number of errors). It should look something like
Vitaliy> this:
Vitaliy> while (len > sizeof(WCHAR)&& buffer[len/sizeof(WCHAR) - 1]
Vitaliy> == ' ') { len -= sizeof(WCHAR); buffer[len/sizeof(WCHAR)] = 0;
Vitaliy> }
Vitaly,
I disagree with your objection.
"len" is the number of chars in name and is also number of WCHARs in buffer.
So accessing buffer[len/sizeof(WCHAR)] will go astray.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: [RESENT] Don't duplicate handles for _get_osfhandle
>>>>> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes: Alexandre> Uwe Bonnes <[EMAIL PROTECTED]> writes: >> Changelog: wine/dlls/msvcrt/file.c: _get_osfhandle Don't duplicate >> handles, otherwise they leak >> >> This time with test case that fails without the patch (but succeed >> with native msvcrt). Alexandre> It would be nice to also add a test for the case that the Alexandre> DuplicateHandle was supposed to fix, so that we can avoid Alexandre> reintroducing that bug. I will try to write more test this weekend. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
error: length() does not define an explicit binding handle!
Hello, a recent CVS checkout gives ../tools/widl/widl -I. -I. -I../include -I../include-h \ -H mshtml.h mshtml.idl error: length() does not define an explicit binding handle! make[1]: *** [mshtml.h] Fehler 2 Any hints? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: New developer
>>>>> "Segin" == Segin <[EMAIL PROTECTED]> writes: Segin> Hello! I am new to developing Wine, however, I am not new to Segin> using it (I know quite a bit about it already). I want to know Segin> what resources would I want to look at, please nothing obvious Segin> (bugzilla, MSDN, etc.), and what I can do to contribute. Thanks. Look around on www.winehq.org. You will find a lot of things, like poibter to documents, fun projects etc. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
[Corrected] Fix (w)strto(l)d family and test for atof
(I forgot some fix in wcstod)
Changelog:
/home/wine/wine/dlls/msvcrt/wcs.c, string.c, test/string.c:
Fix wcstod, implement strtod and atof on top of an adapted
copy of wcsto(l)d. Add tests for atof and strtod.
This supercedes the patch adding atof todo_wines. Maybe strtod should be
implemented by translating the string to a wide string and calling
wcstod. Few other msvcrt ascii functions however use MultiByteToWideChar
and call the wcs counterpart...
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Index: wine/dlls/msvcrt/wcs.c
===
RCS file: /home/wine/wine/dlls/msvcrt/wcs.c,v
retrieving revision 1.35
diff -u -r1.35 wcs.c
--- wine/dlls/msvcrt/wcs.c 14 Jan 2006 17:00:58 - 1.35
+++ wine/dlls/msvcrt/wcs.c 22 Jan 2006 23:35:23 -
@@ -108,13 +108,13 @@
}
/*
- * wcstod (MSVCRT.@)
+ * wcstold (internal)
*/
-double MSVCRT_wcstod(const MSVCRT_wchar_t* lpszStr, MSVCRT_wchar_t** end)
+long double MSVCRT_wcstold(const MSVCRT_wchar_t* lpszStr, MSVCRT_wchar_t** end)
{
const MSVCRT_wchar_t* str = lpszStr;
int negative = 0;
- double ret = 0, divisor = 10.0;
+ long double ret = 0L, divisor = 1L;
TRACE("(%s,%p) semi-stub\n", debugstr_w(lpszStr), end);
@@ -134,27 +134,32 @@
while (isdigitW(*str))
{
-ret = ret * 10.0 + (*str - '0');
+ret = ret * 10L + (*str - '0');
str++;
}
if (*str == '.')
str++;
while (isdigitW(*str))
{
-ret = ret + (*str - '0') / divisor;
-divisor *= 10;
+ret = ret + (*str - '0');
+divisor *= 10L;
str++;
}
+ ret /= divisor;
if (*str == 'E' || *str == 'e' || *str == 'D' || *str == 'd')
{
int negativeExponent = 0;
int exponent = 0;
-if (*(++str) == '-')
+str++;
+if (*str == '-')
{
negativeExponent = 1;
str++;
}
+else
+ if (*str == '+')
+ str++;
while (isdigitW(*str))
{
exponent = exponent * 10 + (*str - '0');
@@ -163,9 +168,9 @@
if (exponent != 0)
{
if (negativeExponent)
-ret = ret / pow(10.0, exponent);
+ret = ret / powl(10L, exponent);
else
-ret = ret * pow(10.0, exponent);
+ret = ret * powl(10L, exponent);
}
}
@@ -175,10 +180,16 @@
if (end)
*end = (MSVCRT_wchar_t*)str;
- TRACE("returning %g\n", ret);
+ TRACE("returning %Lg\n", ret);
return ret;
}
-
+/*
+ * wcstod (MSVCRT.@)
+ */
+double MSVCRT_wcstod(const MSVCRT_wchar_t* lpszStr, MSVCRT_wchar_t** end)
+{
+return (double) MSVCRT_wcstold(lpszStr, end);
+}
typedef struct pf_output_t
{
Index: wine/dlls/msvcrt/string.c
===
RCS file: /home/wine/wine/dlls/msvcrt/string.c,v
retrieving revision 1.15
diff -u -r1.15 string.c
--- wine/dlls/msvcrt/string.c 14 Jan 2006 17:01:19 - 1.15
+++ wine/dlls/msvcrt/string.c 22 Jan 2006 23:35:23 -
@@ -22,6 +22,7 @@
*/
#include
+#include
#include "msvcrt.h"
#include "wine/debug.h"
@@ -138,19 +139,104 @@
}
/*
- * atof (MSVCRT.@)
+ * strtold (internal)
*/
-double MSVCRT_atof( const char *str )
+long double MSVCRT_strtold( const char *lpszStr, char **end )
{
-return atof( str );
+ const char* str = lpszStr;
+ int negative = 0;
+ long double ret = 0L, divisor = 1L;
+
+ TRACE("(%s,%p) semi-stub\n", debugstr_a(lpszStr), end);
+
+ /* FIXME:
+ * - Should set errno on failure
+ * - Should fail on overflow
+ * - Need to check which input formats are allowed
+ */
+ while (isspace(*str))
+str++;
+
+ if (*str == '-')
+ {
+negative = 1;
+str++;
+ }
+
+ while (isdigit(*str))
+ {
+ret = ret * 10L + (*str - '0');
+str++;
+ }
+ if (*str == '.')
+str++;
+ while (isdigit(*str))
+ {
+ret = ret*10L + (*str - '0');
+divisor *= 10L;
+str++;
+ }
+
+ ret /= divisor;
+ if (*str == 'E' || *str == 'e' || *str == 'D' || *str == 'd')
+ {
+int negativeExponent = 0;
+int exponent = 0;
+str++;
+if (*str == '-')
+{
+ negativeExponent = 1;
+ str++;
+}
+else
+ if (*str == '+')
+ str++;
+while (isdigit(*str))
+{
+ exponent = exponent * 10 + (*str - '0');
+ str++
Re: StartServiceCtrlDispatcher/
>>>>> "Vitaliy" == Vitaliy Margolen <[EMAIL PROTECTED]> writes:
Vitaliy> Now we have other thread waking up and continuing on with
Vitaliy> error?! Did you skipped something? Because I haven't seen why
Vitaliy> it ends up here.
>> 0009: get_console_input_info( handle=(nil) ) 0009:
>> get_console_input_info() = INVALID_PARAMETER { history_mode=0,
>> history_size=0, history_index=0, edition_mode=0, title=L"" }
>> 0009:Call ntdll.RtlNtStatusToDosError(c00d) ret=7fc1f699 0009:Ret
>> ntdll.RtlNtStatusToDosError() retval=0057 ret=7fc1f699
Vitaliy> And 87 is ERROR_INVALID_PARAMETER.
The startup sequence of quartus is quite complicated, when trying to
reproduce I probably missed some arguments. The behaviour of that test
looked like the behaviour in the quartus startus, so I posted that (wrong)
run.
May I send you the log of a run with hopefully the right arguments? It
still hangs in a call to ConnectNamedPipe.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Wine and DJGPP sources
Hallo, while looking at problems with wine's msvcrt (_sys_errlist, atof), pieces from DJ Delorie DJGPP source code, like used in the REACTOS sources would come handy. Is copying.dj compatible with our license? Also not explicie telling LPGL, copying.dj says: * objects and libraries linked into an application may be distributed without sources. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: bug in atof
>>>>> "Louis" == Louis Lenders <[EMAIL PROTECTED]> writes: Louis> Uwe Bonnes elektron.ikp.physik.tu-darmstadt.de> writes: >> >>>>> "Peter" == Peter Beutner gmx.net> writes: >> Peter> Uwe Bonnes schrieb: >> >>>>>>> "Peter" == Peter Beutner gmx.net> writes: >> >> Peter> Which means that '7.8912654773d210' is the same as Peter> '7.8912654773e210'. >> >> Running the test with native msvcrt doesn't give me >> 7.8912654773e210 >> neither... The test linked libc atof and not >> msvcrt atof. I don't know if this is a bug in our headers or >> something else. I will post a corrected patch for the test suite ... Louis> Hi, looks like bug 4337 wasn't really related to the bug in the Louis> simple test app i submitted (Hey , i'm just a poor debugging noob Louis> :) ). Bug 4337 is already fixed by a patch from Julliard (thx) ) Louis> Should i file a bug report for the bug in the simple test app Louis> (ripped from from msdn) or is it a known problem? It's now a know problem. I will try ti fix.. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
StartServiceCtrlDispatcher/
Hallo,
jtagserver.exe from the Altera Quartus suite hangs in a call to
ConnectNamedPipe (as a result of a call to StartServiceCtrlDispatcherA())
Anybody an idea what is going wrong?
Appended a +relay,+snoop,+ntdll,+file,+server,+advapi log from the point
where the main process is started.
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
0009:Starting process L"C:\\altera\\quartus51\\bin\\jtagserver.exe"
(entryproc=0x41a49a)
0009:Call msvcrt.__set_app_type(0001) ret=0041a4cc
0009:Ret msvcrt.__set_app_type() retval=7fa6f018 ret=0041a4cc
0009:Call msvcrt.__p__fmode() ret=0041a4e1
0009:Ret msvcrt.__p__fmode() retval=7fa6efe8 ret=0041a4e1
0009:Call msvcrt.__p__commode() ret=0041a4ef
0009:Ret msvcrt.__p__commode() retval=7fa6eff0 ret=0041a4ef
0009:Call msvcrt._controlfp(0001,0003) ret=0041a5dd
0009:Ret msvcrt._controlfp() retval=0009001f ret=0041a5dd
0009:Call msvcrt._initterm(00420020,00420024) ret=0041a531
0009:Ret msvcrt._initterm() retval= ret=0041a531
0009:Call msvcrt.__getmainargs(7fb9feec,7fb9fedc,7fb9fee8,,7fb9fee0)
ret=0041a555
0009:Ret msvcrt.__getmainargs() retval= ret=0041a555
0009:Call msvcrt._initterm(0042,0042001c) ret=0041a564
0009:Call msvcrt._onexit(00402740) ret=0041a202
0009:Call kernel32.InitializeCriticalSection(7fa6e9d0) ret=7fa3b76e
0009:Call ntdll.RtlInitializeCriticalSection(7fa6e9d0) ret=7fc6007c
0009:Ret ntdll.RtlInitializeCriticalSection() retval= ret=7fc6007c
0009:Ret kernel32.InitializeCriticalSection() retval= ret=7fa3b76e
0009:Call ntdll.RtlAllocateHeap(7fce,0008,0080) ret=7fa3a5fe
0009:Ret ntdll.RtlAllocateHeap() retval=7fcfe888 ret=7fa3a5fe
0009:Ret msvcrt._onexit() retval=00402740 ret=0041a202
0009:Call msvcrt._onexit(0040875c) ret=0041a202
0009:Ret msvcrt._onexit() retval=0040875c ret=0041a202
0009:Call msvcrt._onexit(00409850) ret=0041a202
0009:Ret msvcrt._onexit() retval=00409850 ret=0041a202
0009:Call msvcrt._onexit(0040988b) ret=0041a202
0009:Ret msvcrt._onexit() retval=0040988b ret=0041a202
0009:Call msvcrt._onexit(004166b3) ret=0041a202
0009:Ret msvcrt._onexit() retval=004166b3 ret=0041a202
0009:Ret msvcrt._initterm() retval= ret=0041a564
0009:Call msvcrt.__p___initenv() ret=0041a56a
0009:Ret msvcrt.__p___initenv() retval=7fa5a614 ret=0041a56a
0009:Call kernel32.GetVersionExA(7fb9fdec) ret=00414a0b
0009:Call ntdll.RtlGetVersion(7fb9fc24) ret=7fc6cf3d
0009:Ret ntdll.RtlGetVersion() retval= ret=7fc6cf3d
0009:Ret kernel32.GetVersionExA() retval=0001 ret=00414a0b
0009:Call advapi32.StartServiceCtrlDispatcherA(00420078) ret=00413a3e
trace:advapi:StartServiceCtrlDispatcherA 0x420078
0009:Call kernel32.MultiByteToWideChar(,,00420088 "Altera JTAG
Server",,,) ret=7f99ad13
0009:Ret kernel32.MultiByteToWideChar() retval=0013 ret=7f99ad13
0009:Call ntdll.RtlAllocateHeap(7fce,0008,005e) ret=7f99ad2f
0009:Ret ntdll.RtlAllocateHeap() retval=7fcfe910 ret=7f99ad2f
0009:Call kernel32.MultiByteToWideChar(,,00420088 "Altera JTAG
Server",,7fcfe944,0013) ret=7f99ad48
0009:Ret kernel32.MultiByteToWideChar() retval=0013 ret=7f99ad48
trace:advapi:service_run_threads starting 1 pipe listener threads
0009:Call ntdll.RtlAllocateHeap(7fce,,0004) ret=7f99ab83
0009:Ret ntdll.RtlAllocateHeap() retval=7fcfe630 ret=7f99ab83
0009:Call
kernel32.CreateThread(,,7f99c9a0,7fcfe910,,)
ret=7f99abb8
0009:Call ntdll.RtlAllocateHeap(7fce,,0008) ret=7fc6740b
0009:Ret ntdll.RtlAllocateHeap() retval=7fcfe3a8 ret=7fc6740b
0009:Call
ntdll.RtlCreateUserThread(,,0001,,,,7fc672e0,7fcfe3a8,7fb9fc78,7fb9fc6c)
ret=7fc67451
0009: *fd* 9 <- 30
0009: new_thread( access=001f03ff, attributes=, suspend=1, request_fd=9
)
0009: new_thread() = 0 { tid=000a, handle=0x44 }
0009:Ret ntdll.RtlCreateUserThread() retval= ret=7fc67451
0009:Call ntdll.NtResumeThread(0044,7fb9fc74) ret=7fc674b5
0009: resume_thread( handle=0x44 )
0009: resume_thread() = 0 { count=1 }
0009:Ret ntdll.NtResumeThread() retval= ret=7fc674b5
0009:Ret kernel32.CreateThread() retval=0044 ret=7f99abb8
0009:Call
kernel32.WaitForMultipleObjectsEx(0001,7fcfe630,0001,,)
ret=7f99ac24
0009:Call
ntdll.NtWaitForMultipleObjects(0001,7fb9fba0,0001,,)
ret=7fc604d9
0009: select( flags=5, cookie=0x7fb9fa54, signal=(nil), timeout=0,
handles={0x44} )
0009: select() = PENDING
000a: *fd* 11 <- 31
000a: *fd* 13 <- 32
000a: init_thread( unix_pid=3608, unix_tid=3615, teb=0xb7f6,
peb=0x7ffdf6e0, entry=0x7fc672e0, ldt_copy=0xb7f71860, reply_fd=11, wait_fd=13,
debug_level=1 )
000a: init_thread() = 0 { pid=000
Re: bug in atof
>>>>> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: Peter> Uwe Bonnes schrieb: >>>>>>> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: >> Peter> Which means that '7.8912654773d210' is the same as Peter> '7.8912654773e210'. >> Running the test with native msvcrt doesn't give me 7.8912654773e210 >> neither... The test linked libc atof and not msvcrt atof. I don't know if this is a bug in our headers or something else. I will post a corrected patch for the test suite ... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: bug in atof
>>>>> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: Peter> Which means that '7.8912654773d210' is the same as Peter> '7.8912654773e210'. Running the test with native msvcrt doesn't give me 7.8912654773e210 neither... Peter> But on linux we have(quoted from 'man strtod'): - A decimal Peter> number consists of a nonempty sequence of decimal digits pos- Peter> sibly containing a radix character (decimal point, locale Peter> dependent, usually ``.''), optionally followed by a decimal Peter> exponent. A decimal exponent consists of an ``E'' or ``e'', Peter> followed by an optional plus or minus sign, followed by a Peter> non-empty sequence of decimal digits, and indicates Peter> multiplication by a power of 10. Peter> It doesn't parse 'd' or 'D' as exponent. Seems to be a "MS-only Peter> extension" to the standard :p Could you please check '7.8912654773d210' gives the expected result on windows? Peter> [1] Peter> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_atof.2c_.atoi.2c_._atoi64.2c_.atol.asp -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: bug in atof
>>>>> "Louis" == Louis Lenders <[EMAIL PROTECTED]> writes:
Louis> Hi, i filed a bug ( bug 4337) and looks like there's a bug in
Louis> atof. Is there a difference between linux' atof and msvcrt's one?
Louis> Even following simple program (from msdn) yields wrong results:
Louis> // crt_atof.c #include #include
Louis> int main( void ) { char *s; double x; int i; long l;
Louis>s = " -2309.12E-15"; /* Test of atof */ x = atof( s ); printf(
Louis> "atof test: \"%s\"; float: %e\n", s, x );
Louis>s = "7.8912654773d210"; /* Test of atof */ x = atof( s );
Louis> printf( "atof test: \"%s\"; float: %e\n", s, x );
Louis>s = " -9885 pigs"; /* Test of atoi */ i = atoi( s ); printf(
Louis> "atoi test: \"%s\"; integer: %d\n", s, i );
Louis>s = "98854 dollars"; /* Test of atol */ l = atol( s ); printf(
Louis> "atol test: \"%s\"; long: %ld\n", s, l ); } the exponent value in
Louis> float x are wrong. Thanks
Not atof() is the cause of your bug, but printf().
I entered your sample into the test suite to show the correct behaviour of
wine's implementation of atof. The printf() test has already a todo for the
incorrect exponent output.
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Linuxtag 2006
Hallo, has anybody interest in activly participating in a Wine booth in Linuxtag 2006 (http://www.linuxtag.org/2006/de/home/cfpro.html) in Wiesbaden from May 3 to May 6? Please let me know. Projects should have applied before Feb. 3. 2006. If needed, I can provide a place to sleep here in my flat in Darmstadt. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: JDK
>>>>> "Robert" == Robert Shearman <[EMAIL PROTECTED]> writes: Robert> Curro Amores wrote: >> I get this error when trying to install j2se with wine, i think is >> PE 0x004d-00522000 Deferred rpcrt4 PE 0x0068-0086c000 >> Deferred msi PE 0x65f0-65fc2000 Deferred ole32 >> Robert> This isn't a user's list, but you might want to start by setting Robert> the above three DLLs to builtin. I can't fix bugs in native Robert> DLLs, but I can in Wine's. Robert, as we are on the devel list, can you tell what bug in what native library you see? Thanks -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: MSI patch getting some installer working thx deformat_environment did cut off string at beign of it.
> "Magnus" == Magnus Olsen <[EMAIL PROTECTED]> writes: Magnus> in function deformat_environment did cut of one letter of Magnus> GetEnvironmentVariableW at beigner in second call. it try found Magnus> example LLUSERSPROFILE but it mean ALLUSERSPROFILE. fixed by me Magnus> and hpussin. in ReactOS Magnus Olsen [EMAIL PROTECTED] Magnus> begin 666 format.c.patch Magnus> [EMAIL PROTECTED](&1L;',O;7-I+V9O
Re: Create new mailing list wine-isv?
>>>>> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: Peter> Michael Jung schrieb: >> On Friday 16 December 2005 15:41, Peter Beutner wrote: >>> Don't get me wrong I still think it is perfectly valid that wine is >>> doing that sort of hack to get existing windows applications working >>> but you really shouldn't advertise it as a solution to platform >>> independence and encourage developers to go this way. >> If someone plans to do a new multi-platform project, I'm pretty sure >> no one in their right mind would suggest wine to do it. But there is >> a whole lot of legacy applications for which the only economically >> feasible way to port them to linux might be via wine. Peter> Agreed. This sums up quite well what I wanted to say ;) Any new project with multi platform target in mind would probably be created on a more "library like" library than Wine(lib). However I guess few projects are created that way. Projects have often a long history, and for the last year Windows was the only target was windows... So getting winelib in a more mature fashion will help all those legacy projects... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: LoadImage (4bpp) / CopyImage() crashing
>>>>> "Cyril" == Cyril Margorin <[EMAIL PROTECTED]> writes: Cyril> 2005/12/10, Mike McCormack <[EMAIL PROTECTED]>: >> > Unfortunately, problem is that GetBitmapBits function in wine is > >> incorrect, and may causes a buffer overflow, but the GetDIBits isn't. >> >> Great. Then we need to fix it, not try avoid it. Cyril> Yes, but I'm out of ideas how to fix it. The problem is that it Cyril> takes in to account only physical pixmap (as it was called in Cyril> x11drv/bitmap.c) but it should take pair physical pixmap/logical Cyril> bitmap, and make pixels conversion from one to another. If you look in the archives, you will see that I also stumbles about crashes in CopyImage. My patches (by far not as elaborated as yours) where also not applied. I also was out of ideas and hoped somebody else would pick up the problem... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: msvcrt incompatibility in Origin 6.0 when saving documents
>>>>> "Olaf" == Olaf Leidinger <[EMAIL PROTECTED]> writes:
...
Olaf> By the way... what is the difference between "retval" and "ret"?
Olaf> It sounds the same.
ret means the address of the piece of code calling the function
retval is the actual return value of the function returning to the
caller. With a void function (like ftime
time.c: * _ftime (MSVCRT.@)
time.c:void _ftime(struct MSVCRT__timeb *buf)
)
it doesn't make sense.
B.t.w., vararg functions (look in msvcrt.spec) don't appear in the relay
trace.
Olaf> There are still some megs in front of me... Perhaps you could
Olaf> comment my discoveries so far. Personally I think they aren't very
Olaf> important, but I really don't know much about the win32 api, so I
Olaf> can't tell...
The difference in the cipow seems of importance (
math.c:double _CIpow(void)
).
I am not sure about a double as retval. Perhaps you can instrument
dll/msvcrt/math.c with the patch below and run with (additional or
exclusive) WINEDEBUG=+msvrt and look if the arguments and result look
right.
Happy bughunting
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Index: wine/dlls/msvcrt/math.c
===
RCS file: /home/wine/wine/dlls/msvcrt/math.c,v
retrieving revision 1.24
diff -u -w -r1.24 math.c
--- wine/dlls/msvcrt/math.c 25 Jun 2004 01:19:15 - 1.24
+++ wine/dlls/msvcrt/math.c 30 Nov 2005 16:55:52 -
@@ -168,8 +168,10 @@
{
double z;
FPU_DOUBLES(x,y);
+ TRACE("x %f y %f\n", x,y);
/* FIXME: If x < 0 and y is not integral, set EDOM */
z = pow(x,y);
+ TRACE("z %f \n", z);
if (!finite(z)) *MSVCRT__errno() = MSVCRT_EDOM;
return z;
}
Re: Problem with serial port
>>>>> "Félix" == Félix Ortega <[EMAIL PROTECTED]> writes: Félix> I'm starting to thing that there is a problem with the way the Félix> serial port is initialized, but I don't have any proof of that. Didn't Cihan already found some mismatches in initialization. Perhaps there is more mismatch lingering around. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Problem with serial port
>>>>> "Félix" == Félix Ortega <[EMAIL PROTECTED]> writes: Félix> Sorry, with my desesperation I forgot to tell you the version of Félix> wine I'm running is the 0.9.2 version. I have tried 0.9.0 and Félix> 0.9.1, with the same result. The strange thing is the driver does Félix> not use the WaitCommEvent call, tha I think is work in progress Félix> now. No, most WaitCommEvent functionality is there. Maybe heavy use of threads and some special case still cause trouble. Félix> I have another driver for a similar printer that does use Félix> this call, and doesn't work neither. I'm studying the windows Félix> source code of this second driver (I have access to it) to make a Félix> linux program that at least initialize the printer. I will keep Félix> you informed on this second project. Look at the test directories and try to create tests mimicing your error. Félix> For the olivetti printer, I Félix> don't know what is the problem, and I don't know where to look Félix> for :(. Perpaps some serial spy would be of help. Capture the communication of the windows program with the device, do the same under wine and compare. However I don't have a suggestion for a serial caputure program for you :-( -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Problem with serial port
>>>>> "Félix" == Félix Ortega <[EMAIL PROTECTED]> writes: Félix> Quoting Cihan Altinay <[EMAIL PROTECTED]>: >> Quoting Félix Ortega <[EMAIL PROTECTED]>: >> >>> I'm trying to make work a driver for a financial printer (Olivetti >>> Pr20) on wine. I'm having problems with the serial port, it seems >>> that no data is written to the device. I have tried everything I >>> have thinked, searched on >> Please try the attached patch with the latest cvs. It is a >> workaround for a symptom where data is flushed away in wine but not >> in Windows. It would be interesting to know if that works for you as >> well. >> Félix, just to make things sure, are you running a recent wine? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: msvcrt incompatibility in Origin 6.0 when saving documents
>>>>> "Olaf" == Olaf Leidinger <[EMAIL PROTECTED]> writes: Olaf> Hello again! >> Try running the application with the debugger and builtin >> msvcrt. Perhaps you get a backtrace of the crash. Otherwise try in >> the relay trace (builtin msvcrt, showing the messagebox but not the >> crash) to find where the messagebox is called. You can seach for the >> message text. Now work up the log and try to find why the program >> decides to emit the messagebox. >> Olaf> Well, the debugger doesn't tell me anything, as the backtrace is Olaf> only one line long and it doesn't contain any information. I Olaf> digged a bit deeper in the relay-log. After the save-file dialog I Olaf> found this: If it is a heap overwrote, try running with WINEDEBUG=+heap. This will check the heap with each heap operation and will immediately tell you when something hag gone wrong (but not where). Otherwise perhaps try running with WINEDEBUG=+snoop,+relay and compare each msvcrt call. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: [msvcrt] how to handle msvcr*.dll ?
>>>>> "Raphael" == Raphael <[EMAIL PROTECTED]> writes: Raphael> On Monday 28 November 2005 19:46, Daniel Remenak wrote: >> >> . Windows does not and will not distribute them, and neither >> should wine. What about winelib on non-X86? Raphael> I know that but many application expect they are already there Raphael> (and they are usually installed with microsoft Raphael> patches/packages/...) -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: msvcrt incompatibility in Origin 6.0 when saving documents
>>>>> "Olaf" == Olaf Leidinger <[EMAIL PROTECTED]> writes: Olaf> Hello List! I'm testing Origin 6.0 using wine-0.9.1 and Olaf> everything is really fine except saving documents. I'm getting a Olaf> crash here. Just before that crash there is a dialog telling me: Olaf> "File not saved. Please ensure that the disk isn't full" (roughly Olaf> translated). Using a native version of msvcrt everything works Olaf> fine. So I suppose that the problem lies in the builtin msvcrt ;-) Olaf> Running origin60.exe using +relay, I also get the message dialog, Olaf> but the app doesn't crash. (Timing problem?) Olaf> Perhaps anybody could tell me where to start looking for the Olaf> problem. Going trough the +relay-logs I can't find anything Olaf> suspect. But I'm not very familliar with the win32 api ;-( Try running the application with the debugger and builtin msvcrt. Perhaps you get a backtrace of the crash. Otherwise try in the relay trace (builtin msvcrt, showing the messagebox but not the crash) to find where the messagebox is called. You can seach for the message text. Now work up the log and try to find why the program decides to emit the messagebox. Hope this helps! -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: powerpoint: images upside down
>>>>> "Cihan" == Cihan Altinay <[EMAIL PROTECTED]> writes: Cihan> Hi, When using MS Powerpoint 2003 images are drawn upside down in Cihan> fullscreen (presentation) mode but not in design mode. Also, Cihan> text is drawn correctly as seen on the attachments. Cihan> I would appreciate a hint on what traces/logs to provide for more Cihan> info as the dc & win output is quite long. Is the error reproducable with the downloadable powerpoint viewer? Can you perhaps put a small powerpoint file online, showing that error? This will make things easier for others to pick up. Also perhaps pit these files and description in the bugs database. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: [MSVCRT]: undname tests.
>>>>> "Eric" == Eric Pouech <[EMAIL PROTECTED]> writes: Eric> ChangeLog: As some people tend to toy with __UnDName, this patch Eric> provides a sample of the joy of MSC symbol mangling Eric, the biggest problem I encountered with undname was that native msvcrt always returns something, at least the original input if nothing is understood. Wine undname however returned nothing when something was unknown to out implementation, resulting in a crash when the application dereferenced the NULL buffer returned... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: usb driver proxy
>>>>> "Marcus" == Marcus Meissner <[EMAIL PROTECTED]> writes: ... Marcus> We have some work going on on hooking new devices (openable by Marcus> CreateFile() from the make-safedisc-work crowd). Are these patches available somewhere? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: kernel/comm.c - page fault in thread
>>>>> "Cihan" == Cihan Altinay <[EMAIL PROTECTED]> writes: Cihan> Uwe Bonnes wrote: >> If you need input into the serial port, consider using some kind of >> loopback. Either use the plug with the appropriate pins shorted , or >> use two serial lines with a crossover cable. >> >> Where do you live. I could consider sending you the plug.. Cihan> I am currently in Australia so I guess it wouldn't be possible Cihan> although it would help a lot. It's only a RS232 9 pin connector with 3 solder blobs. If you have a solder iron, easily done yourself. Cihan> I found in the documentation that the PARMRK flag duplicates 0xff Cihan> in the stream to avoid confusion with the actual error Cihan> character. I verified that by inspecting the stream with/without Cihan> flag set. Can we simply clear the PARMRK flag in wine or is Cihan> there something similar under windows? >> Clear all those offending flags and write a comment that somebody >> looking in the code can understand. Cihan> Can I just do that around line 1106 where c_iflag is initialized? Cihan> I will send a patch out shortly. Looks reasonable Cihan> I am still trying to figure out what the problem might be when Cihan> using purge to clear the output buffer. When G-Ware writes Cihan> subsequently to the port it looks like this: Cihan> 1) Purge (input/output) Cihan> 2) Write Cihan> 3) SetWaitMask (RXCHAR|RXFLAG|CTS|DSR|RLSD|BRK|ERR) Cihan> 4) WaitCommEvent Cihan> (4a) Read input if there's something) Cihan> Goto 1) Cihan> As you can see there is no TXEMPTY flag so G-Ware seems to rely Cihan> on the buffers to be emptied beforehand and then just calls Purge Cihan> before writing again. Just to make sure I wrote a short program Cihan> that does the following: Cihan> 1) Write command Cihan> 2) Purge Cihan> 3) Write Cihan> another command (Without any delay). Obviously some bytes from Cihan> the first command are flushed away and thus the device indeed Cihan> returns the same error value I get under G-Ware. Here you forgot the behaviour of the actual device. It probably only reacts when a complete command is written and terminated in some way, perhaps a CR or something like that. If G-Ware send this "magic" byte as the last command, no need fot tcdrain or such Cihan> I can prevent it Cihan> by using tcdrain() or insert a sleep with a large enough value. Cihan> I also tried to _see_ it by using a tty instead of the serial Cihan> port but interestingly that does work, ie. no bytes are lost. Cihan> Uwe, could you try and see what happens when you use the loopback Cihan> and do a Write-Purge-Write sequence under both, wine and windows? I am sure that bytes will get lost without any kind of line dicipline... Cihan> One more thing regarding the page fault in the EventService: We Cihan> obviously have to set the buffer to 0 when the event mask changes Cihan> because that's what the API spec says. But maybe we have to Cihan> monitor which threads exist and wake them up when SetCommMask is Cihan> called so that they finish their work before SetCommMask returns. Cihan> MSDN says: "...WaitCommEvent returns immediately" Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: GetQueueStatus: unknown flag 0x4000
>>>>> "Cihan" == Cihan Altinay <[EMAIL PROTECTED]> writes: Cihan> Hi, When running G-Ware[1] I get a lot of these: Cihan> fixme:key:GetQueueStatus QS_ flags (4000) are not handled Cihan> Interestingly I couldn't find any information about what the flag Cihan> 0x4000 is meant to be. Could that be another undocumented flag Cihan> like QS_SMRESULT? The program works so it can't be that important Cihan> :-) but I thought it's worth mentioning... I get this only when running with native ole32/oleaut32/rpcrt4 (XP ) -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: privileged instruction in 32-bit code
>>>>> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes: Peter> Tyler Nielsen schrieb: >> Ivan Leo Puoti wrote: Yeah, the safedisc patch didn't seem to help >> the issue at all. I really hope this isn't debugger checks failing, >> but I still wonder why a seemingly valid command (movaps) is >> returning a privileged instruction exception. Peter> google says: movaps will cause an exception when trying to access Peter> data not aligned to 16-byte boundary. Peter> though i don't really know what you can do about that :( Perhaps that some Wine memory layout has some weak spots in i't 16-bit range.. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: kernel/comm.c - page fault in thread
>>>>> "Cihan" == Cihan Altinay <[EMAIL PROTECTED]> writes: ... Cihan> I studied the test cases in tests/comm.c but I am not sure how to Cihan> implement a test that requires input from the serial port. I saw Cihan> the loopback possibility but I cannot test it. Do I need to Cihan> write a test case for the first issue as well (where Cihan> *commio->buffer is written to after it is already freed)? It Cihan> seems quite obvious that the thread may still be running after Cihan> the client frees its buffers. If you need input into the serial port, consider using some kind of loopback. Either use the plug with the appropriate pins shorted , or use two serial lines with a crossover cable. Where do you live. I could consider sending you the plug.. Cihan> I found in the documentation that the PARMRK flag duplicates 0xff Cihan> in the stream to avoid confusion with the actual error Cihan> character. I verified that by inspecting the stream with/without Cihan> flag set. Can we simply clear the PARMRK flag in wine or is Cihan> there something similar under windows? Clear all those offending flags and write a comment that somebody looking in the code can understand. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
