May 2007 - Wine-Devel - list.winehq.org

Re: [wine.inf] move explorer to the windows directory

by Detlef Riekenberg

On Mo, 2007-05-07 at 08:28 +0200, Damjan Jovanovic wrote: > * Moved explorer.exe to the windows directory, because that's where > some apps expect to find it. You should also modify GetDesktopWindow in "dlls/user32/win.c": GetSystemDirecoryW => GetWindowsDirectoryW -- By by ... Detlef

May 7, 2007

Re: [PATCH] Adds NET START to net.exe

by Dmitry Timoshkov

"Tim Schwartz" <tim(a)sanityinternet.com> wrote: > +int net_service(char *operation, char *service_name) Please add 'static' since it isn't used outside of this .c file. > +{ > + SC_HANDLE SCManager, serviceHandle; > + int result = 0; > + unsigned int *buffer_size = NULL; > + char *service_display_name = NULL; ... > + GetServiceDisplayName(SCManager, service_name, NULL, buffer_size); > + if(!buffer_size) How buffer_size is supposed to become not NULL here? Also please follow parameter types used by win32 APIs (in this case GetServiceDisplayName). > + if(!strcasecmp(operation, "start")) > + { > + printf("The %s service is starting.\n", service_display_name); > + result = StartService(serviceHandle,0,NULL); > + CloseServiceHandle(serviceHandle); > + if(!result) printf("The %s service failed to start.\n", > service_display_name); > + else printf("The %s service was started successfully.\n", > service_display_name); > + > + HeapFree(GetProcessHeap(), 0, service_display_name); > + return result; > + } SCManager is still leaked. And The patch is wrapped again. -- Dmitry.

May 7, 2007

Re: Winscard support (for smart cards)

by Detlef Riekenberg

On Mo, 2007-04-30 at 00:58 +0200, Mounir IDRASSI wrote: > +#define SCARD_S_SUCCESS 0x00000000 > +#define SCARD_F_INTERNAL_ERROR 0x80100001 /**< An internal > consistency check failed. */ > +#define SCARD_E_CANCELLED 0x80100002 /**< The > action was cancelled by an SCardCancel request. */ > +#define SCARD_E_INVALID_HANDLE 0x80100003 /**< The supplied > handle was invalid. */ > +#define SCARD_E_INVALID_PARAMETER 0x80100004 /**< One or more of > the supplied parameters could not be properly interpreted. */ I have no Idea about the Code, but your idention is broken (SPACE and TAB). Wine is using 4 Space, when possible. SCARD_SCOPE/STATE/SHARE to SCARD_PROTOCOL_* as more Examples after a quick view. Thanks for helping Wine. -- By by ... Detlef

May 7, 2007

Re: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam

by Detlef Riekenberg

On Sa, 2007-05-05 at 19:16 +0200, Mounir IDRASSI wrote: > --- a/include/wincrypt.h > +++ b/include/wincrypt.h > +/* Values returned by CryptGetProvParam of PP_KEYSTORAGE */ > +#define CRYPT_SEC_DESCR 0x00000001 > +#define CRYPT_PSTORE 0x00000002 > +#define CRYPT_UI_PROMPT 0x00000004 I have no Idea about the code, but the missing defines should be a seperate patch. Your idention looks broken. Wine is using 4 Space, when possible. -- By by ... Detlef

May 7, 2007

Re: Winscard support (for smart cards)

by Mounir IDRASSI

Hi all, We have noticed that our first patch for winscard containing only the headers have not been applied yet. Is this a normal delay? Is there any pending issues? Should we send the remaining list of patches to complete the winscard implementation? Any comments/remarks are welcomed. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr

May 7, 2007

Re: dbghelp[2]: Speed up vector_add. Remove no longer needed pool_realloc.

by Detlef Riekenberg

On Mo, 2007-05-07 at 05:46 +0200, Markus Amsler wrote: > + /* Don't even try to resize memory. Memory gain would be > minimal > + but speed hit significant with big vecotrs. * I have no Idea about the code, but found this Typo: vecotrs => vectors -- By by ... Detlef

May 7, 2007

Re: volume names of mounted iso images

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > I have a patch ready to go that fixes a problem with the media > switching code in msi. According to tests and msdn, the presence of a > required media (usually a CD or DVD) is confirmed using only the > volume name listed in the Media table of the msi file. The patch > simplifies the existing media checking code and also fixes a few > installers. The problem is that, on my system at least, the volume > name and serial of mounted ISO files (using a loopback device) are not > available, and any call to GetVolumeInformation returns an empty > string for the volume name. Because of this, I'm hesitant to get the > patch committed for fear of restricting installs to only using > physical media. That would include me, because my CD drive is borked. > Setting the volume name in winecfg doesn't work, probably because of > permissions and the fact that the mount is read only. 'Autodetect > from Device' is apparently not implemented. Can someone enlighten me > on the situation and possible solutions? Autodetect from device is the default behavior, and it should work fine for ISO images. Probably Wine cannot open the corresponding iso file for some reason. -- Alexandre Julliard julliard(a)winehq.org

May 7, 2007

rsaenh: fix critical bug in read_key_container

by Mounir IDRASSI

Hi, We have found a critical bug in rsaenh dll. This bug prevents CryptAcquireContext from correctly loading the key associated with the container from the registry, and thus CryptGetUserKey become unusable. This bug is located in the internal function read_key_container. Attached with this email is a patch correcting this bug and adding a test that demonstrate it. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From 8da78d912c0a709a641ae4082ee6df270f644a08 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Mon, 7 May 2007 17:04:46 +0200 Subject: rsaenh: fix critical bug in read_key_container --- dlls/rsaenh/rsaenh.c | 11 +++++++---- dlls/rsaenh/tests/rsaenh.c | 19 +++++++++++++++++++ 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/dlls/rsaenh/rsaenh.c b/dlls/rsaenh/rsaenh.c index 2ace2d5..7723157 100644 --- a/dlls/rsaenh/rsaenh.c +++ b/dlls/rsaenh/rsaenh.c @@ -1050,6 +1050,7 @@ static HCRYPTPROV read_key_container(PCHAR pszContainerName, DWORD dwFlags, PVTa KEYCONTAINER *pKeyContainer; HCRYPTPROV hKeyContainer; DATA_BLOB blobIn, blobOut; + HCRYPTKEY hCryptKey; sprintf(szRSABase, RSAENH_REGKEY, pszContainerName); @@ -1089,8 +1090,9 @@ static HCRYPTPROV read_key_container(PCHAR pszContainerName, DWORD dwFlags, PVTa if (CryptUnprotectData(&blobIn, NULL, NULL, NULL, NULL, (dwFlags & CRYPT_MACHINE_KEYSET) ? CRYPTPROTECT_LOCAL_MACHINE : 0, &blobOut)) { - RSAENH_CPImportKey(hKeyContainer, blobOut.pbData, blobOut.cbData, 0, 0, - &pKeyContainer->hKeyExchangeKeyPair); + if(RSAENH_CPImportKey(hKeyContainer, blobOut.pbData, blobOut.cbData, 0, 0, + &hCryptKey)) + pKeyContainer->hKeyExchangeKeyPair = hCryptKey; HeapFree(GetProcessHeap(), 0, blobOut.pbData); } } @@ -1113,8 +1115,9 @@ static HCRYPTPROV read_key_container(PCHAR pszContainerName, DWORD dwFlags, PVTa if (CryptUnprotectData(&blobIn, NULL, NULL, NULL, NULL, (dwFlags & CRYPT_MACHINE_KEYSET) ? CRYPTPROTECT_LOCAL_MACHINE : 0, &blobOut)) { - RSAENH_CPImportKey(hKeyContainer, blobOut.pbData, blobOut.cbData, 0, 0, - &pKeyContainer->hSignatureKeyPair); + if(RSAENH_CPImportKey(hKeyContainer, blobOut.pbData, blobOut.cbData, 0, 0, + &hCryptKey)) + pKeyContainer->hSignatureKeyPair = hCryptKey; HeapFree(GetProcessHeap(), 0, blobOut.pbData); } } diff --git a/dlls/rsaenh/tests/rsaenh.c b/dlls/rsaenh/tests/rsaenh.c index fe27f4b..0832e0f 100644 --- a/dlls/rsaenh/tests/rsaenh.c +++ b/dlls/rsaenh/tests/rsaenh.c @@ -1603,6 +1603,25 @@ static void test_null_provider(void) CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, CRYPT_DELETEKEYSET); + + + /* test for the bug in accessing the user key in a container + */ + result = CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, + CRYPT_NEWKEYSET); + ok(result, "CryptAcquireContext failed: %08x\n", GetLastError()); + result = CryptGenKey(prov, AT_KEYEXCHANGE, 0, &key); + ok(result, "CryptGenKey with AT_KEYEXCHANGE failed with error %08x\n", GetLastError()); + CryptDestroyKey(key); + CryptReleaseContext(prov,0); + result = CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL,0); + ok(result, "CryptAcquireContext failed: 0x%08x\n", GetLastError()); + result = CryptGetUserKey(prov, AT_KEYEXCHANGE, &key); + ok (result, "CryptGetUserKey failed with error %08x\n", GetLastError()); + CryptDestroyKey(key); + + CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, + CRYPT_DELETEKEYSET); } START_TEST(rsaenh) -- 1.4.4.2

May 7, 2007

Re: "Installer already running"

by Tom Spear

On 5/7/07, Pavel Troller <patrol(a)sinus.cz> wrote: > Dear Vitaliy, > I'm very sorry for my total stupidity, ignorance and maybe even debility, > but I can't find nothing common between Bug# 219 and my question. > The PhysX installer doesn't check for any *ICE components present in the > system, doesn't output any strings to wine console, which are described in > the bug desc, and the message "The installer is already running", which is > typical for my problem, is not mentioned in the bug description at all. > So please be patient with me and explain me in the deeper detail, why are > you thinking that I'm asking for #219. > With regards, Pavel Troller I agree, this is not an issue with Copy Protection, this is an issue where the installer thinks that the installer is already running. A couple of questions -Have you tried running the PhysX installer manually, after the game is installed? -Have you tried running wineboot to make sure any run entries are cleared and then running the PhysX installer manually? -Any idea what brand of installer it is (InstallShield, MSI, WISE, or some other)? If you aren't sure, I can always take a look at the installer, if you will bzip and send to me (less than 10mb). -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 7, 2007

Re: crypt32: fix a wrong test

by Laurent Vromman

> - ok(info->dwKeySpec == AT_SIGNATURE, > + ok(info->dwKeySpec == (AT_SIGNATURE|AT_KEYEXCHANGE), > "Expected AT_SIGNATURE, got %d\n", info->dwKeySpec); It could be a good idea to correct the error text "Expected AT_SIGNATURE" to add AT_KEYEXCHANGE in it. Laurent Vromman On Mon, 07 May 2007 16:05:35 +0200, Mounir IDRASSI <mounir.idrassi(a)idrix.fr> wrote: > Hi, > This patch corrects a test in crypt32 that was incorrectly written to > accommodate the bug in rsaenh dll we corrected in our previous patch. > > Mounir IDRASSI > IDRIX - Cryptography and IT Security Experts > http://www.idrix.fr > > >

May 7, 2007

crypt32: fix a wrong test

by Mounir IDRASSI

Hi, In the tests of the crypt32 dll, a test was written in a way that accommodates the bug we have corrected previously in the patch for rsaenh dll. The attached small patch corrects the value expected from this test to be consistent with the correct output. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From b2059ab820a37ef3129cd52c4a4048c9081d3bb9 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Mon, 7 May 2007 15:33:36 +0200 Subject: crypt32: fix a wrong test --- dlls/crypt32/tests/cert.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/crypt32/tests/cert.c b/dlls/crypt32/tests/cert.c index 345c9f5..bec65de 100644 --- a/dlls/crypt32/tests/cert.c +++ b/dlls/crypt32/tests/cert.c @@ -1212,7 +1212,7 @@ static void testCreateSelfSignCert(void) "Unexpected key container\n"); ok(!lstrcmpW(info->pwszProvName, MS_DEF_PROV_W), "Unexpected provider\n"); - ok(info->dwKeySpec == AT_SIGNATURE, + ok(info->dwKeySpec == (AT_SIGNATURE|AT_KEYEXCHANGE), "Expected AT_SIGNATURE, got %d\n", info->dwKeySpec); } HeapFree(GetProcessHeap(), 0, info); -- 1.4.4.2

May 7, 2007

Re: "Installer already running"

by Pavel Troller

Dear Vitaliy, I'm very sorry for my total stupidity, ignorance and maybe even debility, but I can't find nothing common between Bug# 219 and my question. The PhysX installer doesn't check for any *ICE components present in the system, doesn't output any strings to wine console, which are described in the bug desc, and the message "The installer is already running", which is typical for my problem, is not mentioned in the bug description at all. So please be patient with me and explain me in the deeper detail, why are you thinking that I'm asking for #219. With regards, Pavel Troller > I'm not so sure why are you reporting a long long long known problem > with Safedisk here, on the mailing list? See the bug 219 and add your > comments there. > > Pavel Troller wrote: > > Hi! > > I was trying to install the Joint Task Force game, which was packaged as > > a bonus with my new graphics card. The game itself seems to install well > > using the standard InstallShield, but then it tries to install a PhysX > > driver/library, which is necessary to run it. The PhysX package is provided > > as a single executable on the CD. When the executable (called > > PhysX_2.5.1_SystemSoftware.exe) is run by wine, it immediately pops a dialog > > saying "The installer is already running" and pressing its OK button > > terminates the installation. The game then complains that the PhysX driver > > is not installed and requires reinstallation (for anybody who would like to > > try this too, the game itself has to be patched by nocd crack first, otherwise > > it chokes on SECDRV.SYS). > > The dialog appears not only when the PhysX installer is launched from the > > game installer, but also when the executable is run directly from the > > command line. > > Intuitively I was trying to discover more about it by running wine with > > WINEDEBUG=+file, and it has shown that the installer created some files in > > c:\windows\temp first, then it played with explorer.exe (tried to run it ?), > > there was a search for a lot of fonts, libs etc., win.ini was consulted several > > times, and the dialog then appeared. Possibly all the stuff starting with > > explorer.exe was there to display the dialog box ? After accepting the box, > > it just deleted the stuff in the temp directory and terminated. > > I didn't find anything related to this in bugzilla. > > I would like to find the real cause of the problem, but I don't know exactly, > > how to proceed. Any hints ? > > It's the current git wine, but the same is observed on 0.9.33 or so. > > > > With regards, Pavel Troller > > > > > > > >

May 7, 2007

Re: "Installer already running"

by Vitaliy Margolen

I'm not so sure why are you reporting a long long long known problem with Safedisk here, on the mailing list? See the bug 219 and add your comments there. Pavel Troller wrote: > Hi! > I was trying to install the Joint Task Force game, which was packaged as > a bonus with my new graphics card. The game itself seems to install well > using the standard InstallShield, but then it tries to install a PhysX > driver/library, which is necessary to run it. The PhysX package is provided > as a single executable on the CD. When the executable (called > PhysX_2.5.1_SystemSoftware.exe) is run by wine, it immediately pops a dialog > saying "The installer is already running" and pressing its OK button > terminates the installation. The game then complains that the PhysX driver > is not installed and requires reinstallation (for anybody who would like to > try this too, the game itself has to be patched by nocd crack first, otherwise > it chokes on SECDRV.SYS). > The dialog appears not only when the PhysX installer is launched from the > game installer, but also when the executable is run directly from the > command line. > Intuitively I was trying to discover more about it by running wine with > WINEDEBUG=+file, and it has shown that the installer created some files in > c:\windows\temp first, then it played with explorer.exe (tried to run it ?), > there was a search for a lot of fonts, libs etc., win.ini was consulted several > times, and the dialog then appeared. Possibly all the stuff starting with > explorer.exe was there to display the dialog box ? After accepting the box, > it just deleted the stuff in the temp directory and terminated. > I didn't find anything related to this in bugzilla. > I would like to find the real cause of the problem, but I don't know exactly, > how to proceed. Any hints ? > It's the current git wine, but the same is observed on 0.9.33 or so. > > With regards, Pavel Troller > > >

May 7, 2007

Re: [try 2] Move console input/output codepages to server - what's wrong?

by Kirill K. Smirnov

В сообщении от 30 апреля 2007 16:26 вы написали: > Hi, > A week ago I've sent a patch which fixes console input/output codepages > handling. > http://www.winehq.org/pipermail/wine-patches/2007-April/038429.html > It is still not applied, so please, explain, what is wrong with it? It even > fixes 2 tests: > $wine kernel32_test.exe.so process > before: > process: 510 tests executed (0 marked as todo, 6 failures), 0 skipped. > after: > process: 510 tests executed (0 marked as todo, 4 failures), 0 skipped. While writing tests for console screen buffer I've found this patch buggy. Please, ignore it. -- Kirill

May 7, 2007

Re: Can we catch access violation exceptions in tests?

by Marcus Meissner

On Mon, May 07, 2007 at 12:31:02PM +0200, Mikołaj Zalewski wrote: > I'm trying to write a tests for invalid cbSize in Shell_NotifyIcon. > The behaviour under Windows XP is to assume in such a case that the size > is NOTIFYICONDATA_V1_SIZE. AFAIK Shell_NotifyIcon doesn't provide a way > to read icon data to check that the data introduced after Win95 is not > modified. So I'm using VirtualAlloc+VirtualProtect to make > Shell_NotifyIcon fail if it tries to access this data. > I'd like to catch the exception to make a tests fail if something goes > wrong instead of crashing the testsuite. However __try doesn't work > under gcc and using wine/exception.h gives an unresolved symbol > '__wine_handle_exception'. Is it possible to catch exceptions in tests? Of course. Check dlls/ntdll/tests/exception.c::run_exception_test() Ciao, Marcus

May 7, 2007

Re: Can we catch access violation exceptions in tests?

by Damjan Jovanovic

On 5/7/07, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > I'm trying to write a tests for invalid cbSize in Shell_NotifyIcon. > The behaviour under Windows XP is to assume in such a case that the size > is NOTIFYICONDATA_V1_SIZE. AFAIK Shell_NotifyIcon doesn't provide a way > to read icon data to check that the data introduced after Win95 is not > modified. So I'm using VirtualAlloc+VirtualProtect to make > Shell_NotifyIcon fail if it tries to access this data. > I'd like to catch the exception to make a tests fail if something goes > wrong instead of crashing the testsuite. However __try doesn't work > under gcc and using wine/exception.h gives an unresolved symbol > '__wine_handle_exception'. Is it possible to catch exceptions in tests? > > Mikolaj Zalewski #include "wine/exception.h" __TRY { /* code that can segfault */ } __EXCEPT_PAGE_FAULT { /* actions to take on segfault */ } __ENDTRY I'm not sure which library you have to link with. Enjoy Damjan

May 7, 2007

Can we catch access violation exceptions in tests?

by Mikołaj Zalewski

I'm trying to write a tests for invalid cbSize in Shell_NotifyIcon. The behaviour under Windows XP is to assume in such a case that the size is NOTIFYICONDATA_V1_SIZE. AFAIK Shell_NotifyIcon doesn't provide a way to read icon data to check that the data introduced after Win95 is not modified. So I'm using VirtualAlloc+VirtualProtect to make Shell_NotifyIcon fail if it tries to access this data. I'd like to catch the exception to make a tests fail if something goes wrong instead of crashing the testsuite. However __try doesn't work under gcc and using wine/exception.h gives an unresolved symbol '__wine_handle_exception'. Is it possible to catch exceptions in tests? Mikolaj Zalewski

May 7, 2007

Re: Implements NET START to control system services

by Dmitry Timoshkov

"Tim Schwartz" <tim(a)sanityinternet.com> wrote: > #include <stdio.h> > #include <string.h> > +#include <windows.h> > + > +int net_service(char *operation, char *service_name); It's better to properly arrange the code to avoid forward declarations. > +int net_service(char *operation, char *service_name) > +{ > + SC_HANDLE SCManager, serviceHandle; > + int result = 0; > + char service_display_name[4096]; service_display_name should be queried and dynamically allocated. > + > + SCManager = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS); > + if(!SCManager) > + { > + printf("Couldn't get handle to SCManager.\n"); > + return 0; > + } > + serviceHandle = OpenService(SCManager, service_name, > SC_MANAGER_ALL_ACCESS); > + if(!serviceHandle) > + { > + printf("Couldn't get handle to service.\n"); > + return 0; > + } You are leaking SCManager handle here. > + > + if(!GetServiceDisplayName(SCManager, service_name, > service_display_name, NULL)) Are you sure that last parameter can be NULL here? MSDN seems to disagree. Also did you test your code under Windows? This kind of application can be and should be IMO developed/tested in Windows. > + if(!strcasecmp(operation, "start")) > + { > + printf("The %s service is starting.\n", service_display_name); > + result = StartService(serviceHandle,0,NULL); > + CloseServiceHandle(serviceHandle); > + if(!result) printf("The %s service failed to start.\n", > service_display_name); > + else printf("The %s service was started successfully.\n", > service_display_name); > + return result; > + } > + > + return 0; > } You are leaking the SCManager handle here as well, and both serviceHandle and SCManager are leaked if operation is not "start". Also the patch was wrapped by your mailer. -- Dmitry.

May 7, 2007

"Installer already running"

by Pavel Troller

Hi! I was trying to install the Joint Task Force game, which was packaged as a bonus with my new graphics card. The game itself seems to install well using the standard InstallShield, but then it tries to install a PhysX driver/library, which is necessary to run it. The PhysX package is provided as a single executable on the CD. When the executable (called PhysX_2.5.1_SystemSoftware.exe) is run by wine, it immediately pops a dialog saying "The installer is already running" and pressing its OK button terminates the installation. The game then complains that the PhysX driver is not installed and requires reinstallation (for anybody who would like to try this too, the game itself has to be patched by nocd crack first, otherwise it chokes on SECDRV.SYS). The dialog appears not only when the PhysX installer is launched from the game installer, but also when the executable is run directly from the command line. Intuitively I was trying to discover more about it by running wine with WINEDEBUG=+file, and it has shown that the installer created some files in c:\windows\temp first, then it played with explorer.exe (tried to run it ?), there was a search for a lot of fonts, libs etc., win.ini was consulted several times, and the dialog then appeared. Possibly all the stuff starting with explorer.exe was there to display the dialog box ? After accepting the box, it just deleted the stuff in the temp directory and terminated. I didn't find anything related to this in bugzilla. I would like to find the real cause of the problem, but I don't know exactly, how to proceed. Any hints ? It's the current git wine, but the same is observed on 0.9.33 or so. With regards, Pavel Troller

May 7, 2007

volume names of mounted iso images

by James Hawkins

Hi all, I have a patch ready to go that fixes a problem with the media switching code in msi. According to tests and msdn, the presence of a required media (usually a CD or DVD) is confirmed using only the volume name listed in the Media table of the msi file. The patch simplifies the existing media checking code and also fixes a few installers. The problem is that, on my system at least, the volume name and serial of mounted ISO files (using a loopback device) are not available, and any call to GetVolumeInformation returns an empty string for the volume name. Because of this, I'm hesitant to get the patch committed for fear of restricting installs to only using physical media. That would include me, because my CD drive is borked. Setting the volume name in winecfg doesn't work, probably because of permissions and the fact that the mount is read only. 'Autodetect from Device' is apparently not implemented. Can someone enlighten me on the situation and possible solutions? Thanks, James Hawkins

May 7, 2007

Re: [New]: Added wrapper dll for ct-api (CardTerminal API)

by Steven Edwards

I forgot to mention the inclusion of config.h and port.h should come before other headers in your source. Thanks Steven On 5/6/07, Christian Eggers <ceggers(a)gmx.de> wrote: > Hello, > > this wrapper dll permits access to chipcard readers which provides a ct-api (CardTerminal > API). > -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 7, 2007

Re: [New]: Added wrapper dll for ct-api (CardTerminal API)

by Steven Edwards

On 5/6/07, Christian Eggers <ceggers(a)gmx.de> wrote: > Hello, > > this wrapper dll permits access to chipcard readers which provides a ct-api (CardTerminal It looks really good. A couple of quick comments for future patches. Please use a standard LGPL license header in your patch for the header, don't use C++ comments and you don't have to add a Changelog entry. Alexandre's patch tools automatically adds it from your email/changeset. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 6, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Dmitry Timoshkov

"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > As I explained previously, this algorithm makes no assumptions about the > data that is being queried. Just because in this case (patch 3) we are > working with RGB colour data doesn't mean it is limited to only that. It > will work with *any* values, as long as you can provide an appropriate > distance function. For this reason, I do not think that limiting the > distances to integer values makes much sense. Getting rid of the square > root has some benefit because it is generally an expensive operation. I > do not think that getting rid of floats would give any noticeable > performance improvements. I undrestand that the algorithm might be used for any data, but there is very slim chance that Wine will need that flexibility. At least so far it's proposed for use only for color/palette data, which is integer by its nature. -- Dmitry.

May 6, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Vitaly Budovski

Dmitry Timoshkov wrote: > "Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > >>> Now that you got rid of sqrt calls usage of float numbers internally >>> doesn't look justified (to me) anymore. >>> >> >> Only because in this instance it is used with integer data. It >> doesn't need to be limited to just integer values. Besides, what >> would be gained by changing it to integers as you suggest? > > What would be gained is an additional speed. Since this code is supposed > to be used to handle palette/color data there is no need to use floats at > all. > As I explained previously, this algorithm makes no assumptions about the data that is being queried. Just because in this case (patch 3) we are working with RGB colour data doesn't mean it is limited to only that. It will work with *any* values, as long as you can provide an appropriate distance function. For this reason, I do not think that limiting the distances to integer values makes much sense. Getting rid of the square root has some benefit because it is generally an expensive operation. I do not think that getting rid of floats would give any noticeable performance improvements.

May 6, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Dmitry Timoshkov

"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: >> Now that you got rid of sqrt calls usage of float numbers internally >> doesn't look justified (to me) anymore. >> > > Only because in this instance it is used with integer data. It doesn't > need to be limited to just integer values. Besides, what would be gained > by changing it to integers as you suggest? What would be gained is an additional speed. Since this code is supposed to be used to handle palette/color data there is no need to use floats at all. -- Dmitry.

May 6, 2007

Re: msi [3/4]: Set the text limit of the edit control if the limit isgiven

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > + text = MSI_RecordGetString( rec, 10 ); > + if ( text ) > + { > + begin = strchrW( text, '{' ); > + end = strchrW( text, '}' ); Perhaps it would be cleaner to use end = strchrW( begin, '}' ); -- Dmitry.

May 6, 2007

Re: Fix keyboard focus issues

by Dmitry Timoshkov

"Bernhard Rosenkraenzer" <bero(a)arklinux.org> wrote: > The attached patch fixes bug #1798 (also known as 6986, 4042, 2819, 2149, and > 2926) -- some fullscreen applications not getting focus correctly. As I already pointed out in the bug using window/screen width in comparisons should allow to avoid that -1/+1 shift in left/top coordinate. -- Dmitry.

May 6, 2007

Re: Old Autocad trials?

by Dalai Felinto

Hi! Here in my University, we have original copies of educational version of AutoCAD (I don't remember the versions). I don't know the licence restrictions, but I can try autorization to share exclusively to wine developers some AutoCAD license (then I can send you a copy). I'm talking from Brazil, maybe someone more closest to you can try the same (to send a copied CD-ROM from post mail is not very easy here), else I can try to do that. How can we proceed? If should be necessary, may the Wine organization send-me a document with the request? Just to know, I study in "Escola de Arquitetura e Urbanismo da Universidade Federal Fluminense, Niterói/RJ - Brasil". Sorry the english, and I hope I can help. Regards, Dalai Felinto http://blendermaniacos.blogspot.com 2007/5/6, Dan Kegel <dank(a)kegel.com>: > > On 5/5/07, L. Rahyen <research(a)science.su> wrote: > > [The worst problem with supporting Autocad is going to be the copy > protection.] > > Yeah, probably. It looks like they used C-Dilla (aka safecast) from 2000 > or > so to 2005 or so. http://wiki.winehq.org/SafeDisc gives hope that Wine > will support safedisc one of these days. Until then, at least I can make > sure there aren't any installer bugs in the free trials. > > > > Before I go wild buying old autocad books from Amazon, > > > does anyone out there have old copies of Autocad > > > (full or trial) they'd be willing to send me for testing? > > > > I recommend you to search these programs in file sharing > systems. > > I'd rather not; running high-value commercial software from strangers > gives me the willies. I'd rather get it from an authoritative source. > - Dan > > >

May 6, 2007

Re: shell32: check cbSize in Shell_NotifyIconW to make apps sending garbage work (fixes bug #7940)

by Mikołaj Zalewski

Dmitry Timoshkov wrote: > "Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > >> + /* The validation is also done in explorer. However we must also >> do it >> + * on the client size so that WM_COPYDATA doesn't crash the >> application >> + */ >> + if (nid->cbSize != NOTIFYICONDATAW_V1_SIZE && >> + nid->cbSize != NOTIFYICONDATAW_V2_SIZE && >> + nid->cbSize != NOTIFYICONDATAW_V3_SIZE && >> + nid->cbSize != sizeof(NOTIFYICONDATAW)) >> + { >> + WARN("Invalid size\n"); >> + return FALSE; >> + } > > Do you have a test case for this? I was testing this but now I see my tests failed because the hWnd was invalid. With a valid hWnd this works even for an invalid cbSize, so this patch is wrong. I'll try to check tomorrow how that should be done correctly. Mikolaj Zalewski

May 6, 2007

Re: change generic.ppd file

by Detlef Riekenberg

On Fr, 2007-05-04 at 17:15 -0300, Alisson Gomes wrote: > I do can recompile wine with change generic.ppd file? Not needed. > only change the generic.ppd? "generic.ppd" is used "as is", but only, when CUPS did not provide a ppd for your Printer and there was no ppd-override in the Registry. http://wiki.winehq.org/UsefulRegistryKeys What do you want to Change? > Or exist a version of wine i can configure? You should use the ppd from your Printer, when Possible. -- By by ... Detlef

May 6, 2007

Re: Console output with different codepages - the result.

by Kirill K. Smirnov

> just a dummy question... does the different fonts your tests refer to > have all the glyphs required ? (or said differently, isn't this a font > issue about the required glyphs for russian ?) > A+ By default (in 866 OEM codepage) wine console renderer behaves just like windows does, the difference appears iff I change codepage to 1251 ANSI. So it is not missing glyphs problem - I do not change font while changing codepage. -- Kirill

May 6, 2007

Re: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam

by Mounir IDRASSI

Hi, Thanks Maarte for your comment. Please find attached the patch augmented with some tests that illustrate what has been corrected. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Maarten Lankhorst wrote: > I don't see any tests added in this patch so it is hard to verify. Please also update dlls/rsaenh/tests with some simple tests if possible, it will make it more likely that the code will be accepted. > > Cheers, > Maarte >From 33a9a1f1573299c9b83c2d699dd4ac31f097a682 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Sun, 6 May 2007 21:36:08 +0200 Subject: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam --- dlls/rsaenh/rsaenh.c | 32 ++++++++++++++++++++++- dlls/rsaenh/tests/rsaenh.c | 61 ++++++++++++++++++++++++++++++++++++++++--- include/wincrypt.h | 5 +++ 3 files changed, 92 insertions(+), 6 deletions(-) diff --git a/dlls/rsaenh/rsaenh.c b/dlls/rsaenh/rsaenh.c index 2ace2d5..488b90c 100644 --- a/dlls/rsaenh/rsaenh.c +++ b/dlls/rsaenh/rsaenh.c @@ -1473,7 +1473,13 @@ BOOL WINAPI RSAENH_CPAcquireContext(HCRYPTPROV *phProv, LPSTR pszContainer, SetLastError(NTE_BAD_KEYSET_PARAM); return FALSE; } else { - if (!RegDeleteKeyA(HKEY_CURRENT_USER, szRegKey)) { + HKEY hRootKey; + if (dwFlags & CRYPT_MACHINE_KEYSET) + hRootKey = HKEY_LOCAL_MACHINE; + else + hRootKey = HKEY_CURRENT_USER; + + if (!RegDeleteKeyA(hRootKey, szRegKey)) { SetLastError(ERROR_SUCCESS); return TRUE; } else { @@ -2899,6 +2905,7 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv, DWORD dwParam, BYTE *pbData, switch (dwParam) { case PP_CONTAINER: + case PP_UNIQUE_CONTAINER:/* MSDN says we can return the same value as PP_CONTAINER */ return copy_param(pbData, pdwDataLen, (CONST BYTE*)pKeyContainer->szName, strlen(pKeyContainer->szName)+1); @@ -2906,6 +2913,29 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv, DWORD dwParam, BYTE *pbData, return copy_param(pbData, pdwDataLen, (CONST BYTE*)pKeyContainer->szProvName, strlen(pKeyContainer->szProvName)+1); + case PP_PROVTYPE: + dwTemp = PROV_RSA_FULL; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSPEC: + dwTemp = AT_SIGNATURE | AT_KEYEXCHANGE; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSET_TYPE: + dwTemp = pKeyContainer->dwFlags & CRYPT_MACHINE_KEYSET; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSTORAGE: + dwTemp = GetVersion(); + /* for Windows NT, 95,98, Me, return CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR + * for the others, return CRYPT_SEC_DESCR + */ + if(dwTemp < 0x80000000 && ((dwTemp & 0x000000FF) != 0x00000004)) + dwTemp = CRYPT_SEC_DESCR; + else + dwTemp = CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + case PP_SIG_KEYSIZE_INC: case PP_KEYX_KEYSIZE_INC: dwTemp = 8; diff --git a/dlls/rsaenh/tests/rsaenh.c b/dlls/rsaenh/tests/rsaenh.c index fe27f4b..dd7013b 100644 --- a/dlls/rsaenh/tests/rsaenh.c +++ b/dlls/rsaenh/tests/rsaenh.c @@ -1480,7 +1480,8 @@ static void test_null_provider(void) HCRYPTPROV prov; HCRYPTKEY key; BOOL result; - DWORD keySpec, dataLen; + DWORD keySpec, dataLen,dwParam; + char szName[MAX_PATH]; result = CryptAcquireContext(NULL, szContainer, NULL, 0, 0); ok(!result && GetLastError() == NTE_BAD_PROV_TYPE, @@ -1513,10 +1514,23 @@ static void test_null_provider(void) CRYPT_VERIFYCONTEXT); ok(result, "CryptAcquireContext failed: %08x\n", GetLastError()); if (!result) return; + /* Test provider parameters getter */ + dataLen = sizeof(dwParam); + result = CryptGetProvParam(prov, PP_PROVTYPE, (LPBYTE)&dwParam, &dataLen, 0); + ok(result && dataLen == sizeof(dwParam) && dwParam == PROV_RSA_FULL, + "Expected PROV_RSA_FULL, got 0x%08X\n",dwParam); + dataLen = sizeof(dwParam); + result = CryptGetProvParam(prov, PP_KEYSET_TYPE, (LPBYTE)&dwParam, &dataLen, 0); + ok(result && dataLen == sizeof(dwParam) && dwParam == 0, + "Expected 0, got 0x%08X\n",dwParam); + dataLen = sizeof(dwParam); + result = CryptGetProvParam(prov, PP_KEYSTORAGE, (LPBYTE)&dwParam, &dataLen, 0); + ok(result && dataLen == sizeof(dwParam) && (dwParam & CRYPT_SEC_DESCR), + "Expected CRYPT_SEC_DESCR to be set, got 0x%08X\n",dwParam); + dataLen = sizeof(keySpec); result = CryptGetProvParam(prov, PP_KEYSPEC, (LPBYTE)&keySpec, &dataLen, 0); - if (result) - ok(keySpec == (AT_KEYEXCHANGE | AT_SIGNATURE), + ok(result && keySpec == (AT_KEYEXCHANGE | AT_SIGNATURE), "Expected AT_KEYEXCHANGE | AT_SIGNATURE, got %08x\n", keySpec); /* Even though PP_KEYSPEC says both AT_KEYEXCHANGE and AT_SIGNATURE are * supported, you can't get the keys from this container. @@ -1558,9 +1572,21 @@ static void test_null_provider(void) if (!result) return; dataLen = sizeof(keySpec); result = CryptGetProvParam(prov, PP_KEYSPEC, (LPBYTE)&keySpec, &dataLen, 0); - if (result) - ok(keySpec == (AT_KEYEXCHANGE | AT_SIGNATURE), + ok(keySpec == (AT_KEYEXCHANGE | AT_SIGNATURE), "Expected AT_KEYEXCHANGE | AT_SIGNATURE, got %08x\n", keySpec); + /* PP_CONTAINER parameter */ + dataLen = sizeof(szName); + result = CryptGetProvParam(prov, PP_CONTAINER, (LPBYTE)szName, &dataLen, 0); + ok(result && dataLen == strlen(szContainer)+1 && strcmp(szContainer,szName) == 0, + "failed getting PP_CONTAINER. result = %s. Error 0x%08X. returned length = %d\n", + (result)? "TRUE":"FALSE",GetLastError(),dataLen); + /* PP_UNIQUE_CONTAINER parameter */ + dataLen = sizeof(szName); + result = CryptGetProvParam(prov, PP_UNIQUE_CONTAINER, (LPBYTE)szName, &dataLen, 0); + ok(result && dataLen == strlen(szContainer)+1 && strcmp(szContainer,szName) == 0, + "failed getting PP_CONTAINER. result = %s. Error 0x%08X. returned length = %d\n", + (result)? "TRUE":"FALSE",GetLastError(),dataLen); + result = CryptGetUserKey(prov, AT_KEYEXCHANGE, &key); ok(!result && GetLastError() == NTE_NO_KEY, "Expected NTE_NO_KEY, got %08x\n", GetLastError()); @@ -1603,6 +1629,31 @@ static void test_null_provider(void) CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, CRYPT_DELETEKEYSET); + + /* test the machine key set */ + CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, + CRYPT_DELETEKEYSET|CRYPT_MACHINE_KEYSET); + result = CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, + CRYPT_NEWKEYSET|CRYPT_MACHINE_KEYSET); + ok(result, "CryptAcquireContext with CRYPT_MACHINE_KEYSET failed: %08x\n", GetLastError()); + /* check PP_KEYSET_TYPE parameter */ + dataLen = sizeof(dwParam); + result = CryptGetProvParam(prov, PP_KEYSET_TYPE, (LPBYTE)&dwParam, &dataLen, 0); + ok(result && dataLen == sizeof(dwParam) && dwParam == CRYPT_MACHINE_KEYSET, + "Expected CRYPT_MACHINE_KEYSET, got 0x%08X\n",dwParam); + CryptReleaseContext(prov, 0); + result = CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, + CRYPT_MACHINE_KEYSET); + ok(result, "CryptAcquireContext with CRYPT_MACHINE_KEYSET failed: %08x\n", GetLastError()); + CryptReleaseContext(prov,0); + result = CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, + CRYPT_DELETEKEYSET|CRYPT_MACHINE_KEYSET); + ok(result, "CryptAcquireContext with CRYPT_DELETEKEYSET|CRYPT_MACHINE_KEYSET failed: %08x\n", + GetLastError()); + result = CryptAcquireContext(&prov, szContainer, NULL, PROV_RSA_FULL, + CRYPT_MACHINE_KEYSET); + ok(!result && GetLastError() == NTE_BAD_KEYSET , + "Expected NTE_BAD_KEYSET, got %08x\n", GetLastError()); } START_TEST(rsaenh) diff --git a/include/wincrypt.h b/include/wincrypt.h index 2219bd5..2aaa89b 100644 --- a/include/wincrypt.h +++ b/include/wincrypt.h @@ -1613,6 +1613,11 @@ static const WCHAR MS_SCARD_PROV_W[] = { 'M','i','c','r','o','s','o',' #define PP_KEYSPEC 39 #define PP_ENUMEX_SIGNING_PROT 40 +/* Values returned by CryptGetProvParam of PP_KEYSTORAGE */ +#define CRYPT_SEC_DESCR 0x00000001 +#define CRYPT_PSTORE 0x00000002 +#define CRYPT_UI_PROMPT 0x00000004 + /* Crypt{Get/Set}KeyParam */ #define KP_IV 1 #define KP_SALT 2 -- 1.4.4.2

May 6, 2007

Re: dbghelp performance

by Markus Amsler

Eric Pouech schrieb: > Markus Amsler a écrit : >> No, performance is exactly the same as pool_heap :( . > even for memory consumption ??? Yes, it looks like HeapCreate has a default size of 64k. >> I analyzed why your original insert_first version was slower and >> memory hungrier then pool_heap. It turned out pool_realloc is the >> problem, not pool_alloc. First there's a memory leak, if the memory >> is moved the old one is not freed. Second pool_realloc is O(n) that's >> the reason for the speed hits. Directly using heap functions for >> reallocs solves both problems (but looks to hackish to get commited, >> perhaps you have a better idea). > we could try not to realloc the array of arrays but rather use a tree > of arrays which should solve most of the issues, but that would make > the code complicated > another way is to double the size of the bucket each time we need to > increase size (instead of adding one bucket) I'll have a look at duplicating bucket size. >> Here the results for pool_realloc on top of insert_first >> pool_realloc 4.5s 54M >> pool_realloc,r300 17s 104M The next problem is >> vector_iter_[up|down], because vector_position is O(n). Explicitly >> storing the current iter position speeds r300 up to 8s (from original >> 115s)! But I'm not sure how to implement it cleanly. Directly use >> for() instead of vector_iter_*(), use an iterator, ... > likely use an interator which keeps track of current position (as we > do for the hash tables) Iterator for an vector looks a bit like an overkill, I was in favor of for(i=0; i<vector_length(); i++). Either solution will add some code on the caller side. Markus

May 6, 2007

Re: Initial Mixer support on Mac OS X (1/7)

by Maarten Lankhorst

"Emmanuel Maillard" <mahanuu(a)free.fr> wrote: > Changelog : > - inital Mixer support on Mac OS X > - find all lines and initialize controls Looking through it you seemed to have used OSS as base, which means some of the comments on my earlier code also apply to your code: - 64 bits safety (use DWORD_PTR's) - the code that normalizes to 65535 should be changed by a MulDiv if possible. Also if coreaudio has a way to notify the sound driver that a mixer control has changed you might want to notify the program, see elem_callback in alsa's mixer, and alsa's mix_open. Cheers, Maarten

May 6, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

by Dmitry Timoshkov

"Vitaly Budovski" <vbudovski(a)gmail.com> wrote: > Make use of the Triangle Inequality Nearest Neighbour algorithm to find the > nearest colour more efficiently than a simple linear search. The improvements > are most noticeable with a palette of 256 colours. Testing shows approximately > 3-4x performance increase for 256 colours. Now that you got rid of sqrt calls usage of float numbers internally doesn't look justified (to me) anymore. -- Dmitry.

May 6, 2007

InternetCanonicalizeURLA / W - Missing some flags?

by Chris Howe

I noticed a FIXME cropping up in the logs when working on EQ2, related to InternetCanonicalizeURL not fully parsing the flags that it is called with. Looking a bit closer, it offloads the grunt work to UrlCanonicalize anyway, and the missing flags seem to have analogs defined for UrlCanonicalize to use, and adding support for them makes the message go away: no problems that I can see, either. However, I seem to be having trouble running the test for wininet, as it just hangs for me (before I made the alterations, that is)... would somebody care to check that the attatched patch is correct?

May 6, 2007

Re: dbghelp performance

by Eric Pouech

Markus Amsler a écrit : > Eric Pouech wrote: >> Markus Amsler a écrit : >>> Eric Pouech wrote: >>>> Markus Amsler a écrit : >>>>> I've played around with dbghelp performance. My test case was >>>>> breaking at an unknown symbol (break gaga) while WoW was loaded in >>>>> the debugger (wine winedbg WoW.exe). The time was hand stopped, >>>>> memory usage measured with ps -AF and looked at the RSS column. >>>>> >>>>> Test Time(s) Memory Usage(MB) >>>>> current git 4.5 54 >>>>> pool_heap.patch 4.5 63 >>>>> process_heap.patch 4.5 126 >>>>> insert_first.patch 4.5 54 >>>>> current git, r300 115 146 >>>>> pool_heap.patch, r300 17 119 >>>>> process_heap.patch, r300 17 260 >>>>> insert_first.patch, r300 27 167 >>>>> >>>>> insert_first is the patch from Eric Pouech. >>>>> r300 means with the debug version of Mesas r300_dri.so, which has >>>>> a total compilation unit size of around 9.2M (compared to the >>>>> second biggest Wines user32 with 1.1M). >> Hi Markus, >> does the slightly modified version of pool_heap improve your >> performances (it shouldn't modify the perf for large files(or just a >> bit), but should reduce memory consumption for small pools (from 1 to >> 2M depending on your configuration) >> >> A+ > No, performance is exactly the same as pool_heap :( . even for memory consumption ??? > I analyzed why your original insert_first version was slower and > memory hungrier then pool_heap. It turned out pool_realloc is the > problem, not pool_alloc. First there's a memory leak, if the memory is > moved the old one is not freed. Second pool_realloc is O(n) that's the > reason for the speed hits. Directly using heap functions for reallocs > solves both problems (but looks to hackish to get commited, perhaps > you have a better idea). we could try not to realloc the array of arrays but rather use a tree of arrays which should solve most of the issues, but that would make the code complicated another way is to double the size of the bucket each time we need to increase size (instead of adding one bucket) > > Here the results for pool_realloc on top of insert_first > pool_realloc 4.5s 54M > pool_realloc,r300 17s 104M > The next problem is vector_iter_[up|down], because vector_position is > O(n). Explicitly storing the current iter position speeds r300 up to > 8s (from original 115s)! But I'm not sure how to implement it cleanly. > Directly use for() instead of vector_iter_*(), use an iterator, ... likely use an interator which keeps track of current position (as we do for the hash tables) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 6, 2007

Re: dbghelp performance

by Markus Amsler

Eric Pouech wrote: > Markus Amsler a écrit : >> Eric Pouech wrote: >>> Markus Amsler a écrit : >>>> I've played around with dbghelp performance. My test case was >>>> breaking at an unknown symbol (break gaga) while WoW was loaded in >>>> the debugger (wine winedbg WoW.exe). The time was hand stopped, >>>> memory usage measured with ps -AF and looked at the RSS column. >>>> >>>> Test Time(s) Memory Usage(MB) >>>> current git 4.5 54 >>>> pool_heap.patch 4.5 63 >>>> process_heap.patch 4.5 126 >>>> insert_first.patch 4.5 54 >>>> current git, r300 115 146 >>>> pool_heap.patch, r300 17 119 >>>> process_heap.patch, r300 17 260 >>>> insert_first.patch, r300 27 167 >>>> >>>> insert_first is the patch from Eric Pouech. >>>> r300 means with the debug version of Mesas r300_dri.so, which has a >>>> total compilation unit size of around 9.2M (compared to the second >>>> biggest Wines user32 with 1.1M). > Hi Markus, > does the slightly modified version of pool_heap improve your > performances (it shouldn't modify the perf for large files(or just a > bit), but should reduce memory consumption for small pools (from 1 to > 2M depending on your configuration) > > A+ No, performance is exactly the same as pool_heap :( . I analyzed why your original insert_first version was slower and memory hungrier then pool_heap. It turned out pool_realloc is the problem, not pool_alloc. First there's a memory leak, if the memory is moved the old one is not freed. Second pool_realloc is O(n) that's the reason for the speed hits. Directly using heap functions for reallocs solves both problems (but looks to hackish to get commited, perhaps you have a better idea). Here the results for pool_realloc on top of insert_first pool_realloc 4.5s 54M pool_realloc,r300 17s 104M The next problem is vector_iter_[up|down], because vector_position is O(n). Explicitly storing the current iter position speeds r300 up to 8s (from original 115s)! But I'm not sure how to implement it cleanly. Directly use for() instead of vector_iter_*(), use an iterator, ... Markus

May 6, 2007

Re: Initial Mixer support on Mac OS X (1/7)

by Dmitry Timoshkov

"Emmanuel Maillard" <mahanuu(a)free.fr> wrote: > Changelog : > - inital Mixer support on Mac OS X > - find all lines and initialize controls Could you please while you are working on winecoreaudio.drv make all public entry points (CoreAudio_widMessage, CoreAudio_wodMessage, CoreAudio_midMessage, CoreAudio_modMessage) 64-bit safe (by using a proper DRVCALLBACK prototype for the driver callback, and using proper data types for passing in/out parameters around)? -- Dmitry.

May 6, 2007

RE: Initial Mixer support on Mac OS X (2/7)

by Amy Fox

oi >From: Emmanuel Maillard <mahanuu(a)free.fr> >Reply-To: wine-devel(a)winehq.org >To: wine-patches(a)winehq.org >Subject: Initial Mixer support on Mac OS X (2/7) >Date: Sun, 6 May 2007 11:53:48 +0200 > >Changelog : > - implement MIX_Open and MIX_GetNumDevs > ><< 0002-implement-MIX_Open-and-MIX_GetNumDevs.patch >> > _________________________________________________________________ Reserve your place in history - Email Britain! http://www.emailbritain.co.uk/

May 6, 2007

Re: winmm: Use a pipe for timer

by Amy Fox

i dnt understand wot ur on abwt m8 im only 15 and plus im blonde so i hav no idea????? >From: "Steven Edwards" <winehacker(a)gmail.com> >Reply-To: wine-devel(a)winehq.org >To: wine-devel(a)winehq.org >CC: wine-patches(a)winehq.org >Subject: Re: winmm: Use a pipe for timer >Date: Sat, 5 May 2007 16:59:26 -0400 > >Hi, > >On 5/5/07, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: >>This avoids expensive server calls in a time critical timer. >> >>Without priority patch it drops stddev in winmm timer tests to < 2 ms as >>compared to ~7 ms before. With priority patch it drops to < .20 ms. >> >>Backwards compatibility code is kept just in case. > >Even though backward compatibility is kept I worry about a couple of >things. A lot of work was done on WinMM to make it portable to windows >for testing and I don't like seeing new code to tie it back to unix >even with the old code left in place. Also shouldn't there be a way to >speed up the server performance instead? If this is accepted here then >what about other areas of wine such as directx where timers similar >may be used? Should we make this sort of patch global? I don't think >so but then I don't know enough to no what the proper fix would be. > >Thanks > >-- >Steven Edwards > >"There is one thing stronger than all the armies in the world, and >that is an idea whose time has come." - Victor Hugo > > _________________________________________________________________ Could you be the guest MSN Movies presenter? Click Here to Audition http://www.lightscameraaudition.co.uk

May 6, 2007

Re: shell32: check cbSize in Shell_NotifyIconW to make apps sending garbage work (fixes bug #7940)

by Dmitry Timoshkov

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > + /* The validation is also done in explorer. However we must also do it > + * on the client size so that WM_COPYDATA doesn't crash the application > + */ > + if (nid->cbSize != NOTIFYICONDATAW_V1_SIZE && > + nid->cbSize != NOTIFYICONDATAW_V2_SIZE && > + nid->cbSize != NOTIFYICONDATAW_V3_SIZE && > + nid->cbSize != sizeof(NOTIFYICONDATAW)) > + { > + WARN("Invalid size\n"); > + return FALSE; > + } Do you have a test case for this? -- Dmitry.

May 6, 2007

Re: Old Autocad trials?

by Dan Kegel

On 5/5/07, L. Rahyen <research(a)science.su> wrote: > [The worst problem with supporting Autocad is going to be the copy protection.] Yeah, probably. It looks like they used C-Dilla (aka safecast) from 2000 or so to 2005 or so. http://wiki.winehq.org/SafeDisc gives hope that Wine will support safedisc one of these days. Until then, at least I can make sure there aren't any installer bugs in the free trials. > > Before I go wild buying old autocad books from Amazon, > > does anyone out there have old copies of Autocad > > (full or trial) they'd be willing to send me for testing? > > I recommend you to search these programs in file sharing systems. I'd rather not; running high-value commercial software from strangers gives me the willies. I'd rather get it from an authoritative source. - Dan

May 6, 2007

Re: Old Autocad trials?

by L. Rahyen

On Saturday May 5 2007 13:42, Dan Kegel wrote: > http://wiki.winehq.org/LinuxApplicatonRequestSurvey > says that Autocad is the #2 most requested > application on Linux. The latest version might be > a challenge to support, since it depends on .net 2.0, > but we could start by supporting older versions. After a quick look (long ago) at the problem of running semi-old Autodesk products (which have new protection system but doesn't require .net 2.0) like AutoCAD and 3ds max I think main problem that makes them to not work is new protection system. For example Ihave seen reports about launching old AutoCAD and old 3ds max 3 and some other Autodesk products but all of them have old protection system. 3ds max 4 for example doesn't work at all because of this (program gives error about not working copy protection system). Of course there are some other bugs like some problems with installation of new versions (maybe solved, I didn't try for a long time) and others (for example support of .net 2.0 in case of most recent versions) but bug with copy protection system should be solved first because it prevent work of semi-old versions (and new versions as well but there are some other bugs need to be solved to make them work too) of AutoCAD, 3ds max and other Autodesk products. I didn't spend a lot of time trying to solve this bug and I didn't tried to install and run AutoCAD for a long time (because there is no reports about success and I havn't enough free time to fix this myself) so I'm not sure about current status of (semi-old and new) AutoCAD under wine. AutoCAD and 3ds max actually last 2 Windows programs I personally use and which doesn't work under Wine - I use VMWare to work with them. Not perfect solution of course but it is only real option for me because I need to work with Linux programs simultaneosly. I hope some day bugs which prevent work of recent AutoCAD and 3ds max under Wine will be fixed and I will be able to not use virtual machine any more. > Before I go wild buying old autocad books from Amazon, > does anyone out there have old copies of Autocad > (full or trial) they'd be willing to send me for testing? I recommend you to search these programs in file sharing systems. Personally I can't use them (due to some technical problems because of stupidity of my ISP) but I often ask some of my friends to download something from file sharing systems like BitTorrent and others. If you decide to use this approach you should install clients for each file sharing system (it is good idea to look for something in more than one file sharing system) then you probably find there both old and new versions of AutoCAD.

May 5, 2007

Writing an interactive test

by Andrew Riedi

I would like to know if there is a way to write an interactive test for my cursor code (will add it to dlls/d3d9/tests). The biggest problem I am having is trying to keep a window drawn. Of course I could use sleep(), but then that soft-freezes my computer. I would like to make it part of our test-suite if possible. Perhaps I should use some sort of loop? Anyhow, thanks for any response. -- Andrew Riedi

May 5, 2007

Re: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam

by Maarten Lankhorst

Mounir IDRASSI schreef: > We have found few bugs in the MS Enhanced CSP implementation in wine > (rsaenh.dll) and you'll find attached a patch that corrects them. Hello Mounir, Bug fixes are always welcome in wine. But fixing bugs is one thing, but it is also very recommended to add tests to verify the behavior is correct. I don't see any tests added in this patch so it is hard to verify. Please also update dlls/rsaenh/tests with some simple tests if possible, it will make it more likely that the code will be accepted. Cheers, Maarten

May 5, 2007

Re: winmm: Use a pipe for timer

by Maarten Lankhorst

Steven Edwards schreef: > Hi, > > Even though backward compatibility is kept I worry about a couple of > things. A lot of work was done on WinMM to make it portable to windows > for testing and I don't like seeing new code to tie it back to unix > even with the old code left in place. Also shouldn't there be a way to > speed up the server performance instead? If this is accepted here then > what about other areas of wine such as directx where timers similar > may be used? Should we make this sort of patch global? I don't think > so but then I don't know enough to no what the proper fix would be. > > Thanks Winmm has a generic timer interface that you could probably use in d3d as well. If windows doesn't have pipe.h and sys/pipe.h then we could change it so that this implementation is only used if sys/pipe.h or pipe.h is found. That should keep winmm portable while keeping speed on both platforms. As for making this patch global: I don't know. Maarten

May 5, 2007

Re: winmm: Use a pipe for timer

by Steven Edwards

Hi, On 5/5/07, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > This avoids expensive server calls in a time critical timer. > > Without priority patch it drops stddev in winmm timer tests to < 2 ms as > compared to ~7 ms before. With priority patch it drops to < .20 ms. > > Backwards compatibility code is kept just in case. Even though backward compatibility is kept I worry about a couple of things. A lot of work was done on WinMM to make it portable to windows for testing and I don't like seeing new code to tie it back to unix even with the old code left in place. Also shouldn't there be a way to speed up the server performance instead? If this is accepted here then what about other areas of wine such as directx where timers similar may be used? Should we make this sort of patch global? I don't think so but then I don't know enough to no what the proper fix would be. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 5, 2007

Re: Newbie question: WineLib DLLs

by Steven Edwards

On 5/5/07, Christian Eggers <ceggers(a)gmx.de> wrote: > Problem: > The dll is linked against an external (non-wine) shared lib. How can my dll be integrated in > wine without forcing other users to get the external library in order to compile wine? Look at how capi32 does delay loading of the native capi library or how mscms32 uses libcms. You can make it a soft dependancy so people can still still compile and use wine without your library. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 5, 2007

Newbie question: WineLib DLLs

by Christian Eggers

Hello, I've created a (very) simple wine dll as described in "Building WineLib DLLs". This dll is a wrapper for the "ct-api" interface used for chipcard readers [1]. With this dll it's possible to use HBCI chipcards (for german online banking, [2]) together with Windows homebanking applications (for example "StarMoney", [3]). Usage: card reader - ct-api driver (hw specific) - symlink (libctapi.so) - wine dll - Windows application Problem: The dll is linked against an external (non-wine) shared lib. How can my dll be integrated in wine without forcing other users to get the external library in order to compile wine? Regards Christian [1] https://www.secure.trusted-site.de/Download/CTAPI/CTAPI11EN.PDF [2] http://www.hbci-zka.de/english/index.htm [3] http://www.starmoney.de

May 5, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups.

by Jacek Caban

Vitaly Budovski wrote: > Vitaliy Margolen wrote: >> Vitaly Budovski wrote: >> >>> Vitaliy Margolen wrote: >>> Thanks for the tip. Unfortunately in this instance it will not >>> work as I >>> do in fact query more than a < b. See the nearest function in patch 2. >>> >> And what is so special about subtracting one from the other? >> >> > > A lot actually. As an example with squared distances: a^2 - b^2 <= c^2. > If a^2 = 27, b^2 = 16, c^2 = 9, then 27 - 16 <= 9 is false. However, > if we use the square root in distance calculations, sqrt(27) - 4 <= 3 > is true. As you can see, we get entirely different results. > I didn't really read your code, but answering on above, it's still possible in this case to avoid sqrt. A bit of math: You want to check if a-b <= c. Assuming a>=b (otherwise it's always true), it's equal to: (a-b)^2 <= c^2 is equal to a^2 + b^2 - 2ab <= c^2 is equal to a^2 + b^2 - c^2 <= 2ab is equal to (assuming a^2 + b^2 - c^2 >= 0) (a^2 + b^2 - c^2)^2 <= (2ab)^2 is equal to (a^2 + b^2 - c^2)^2 <= 4 a^2 b^2 so if you store a^2, b^2 and c^2 instead of a, b, c you may compare it using a few integer operations. In C it would look like: BOOL abccmp(int a2, int b2, int c2) { int tmp = a2+b2-c2; return a2 <= b2 || tmp <= 0 || tmp*tmp <= 4*a2*b2; } It may be not so easy in a real code, but in most cases it should be possible to use such tricks. Jacek

May 5, 2007

rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam

by Mounir IDRASSI

Hi, We have found few bugs in the MS Enhanced CSP implementation in wine (rsaenh.dll) and you'll find attached a patch that corrects them. Here is a description of the problems we found: - In RSAENH_CPAcquireContext : when specifying CRYPT_DELETEKEYSET, the function always deletes the container for the local user, while it should check the CRYPT_MACHINE_KEYSET flag to see if it should be deleted on the local machine or for the local user. - In RSAENH_CPGetProvParam: The following mandatory parameters were not supported : PP_UNIQUE_CONTAINER, PP_PROVTYPE, PP_KEYSPEC, PP_KEYSET_TYPE, PP_KEYSTORAGE. In order to support the PP_KEYSTORAGE parameter, we added three defined to wincrypt.h. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From a7240539a2e3c83291c7cf206d55f1e4e7e75803 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Sat, 5 May 2007 19:01:57 +0200 Subject: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam --- dlls/rsaenh/rsaenh.c | 32 +++++++++++++++++++++++++++++++- include/wincrypt.h | 5 +++++ 2 files changed, 36 insertions(+), 1 deletions(-) diff --git a/dlls/rsaenh/rsaenh.c b/dlls/rsaenh/rsaenh.c index 2ace2d5..9f55760 100644 --- a/dlls/rsaenh/rsaenh.c +++ b/dlls/rsaenh/rsaenh.c @@ -1473,7 +1473,13 @@ BOOL WINAPI RSAENH_CPAcquireContext(HCRYPTPROV *phProv, LPSTR pszContainer, SetLastError(NTE_BAD_KEYSET_PARAM); return FALSE; } else { - if (!RegDeleteKeyA(HKEY_CURRENT_USER, szRegKey)) { + HKEY hRootKey; + if (dwFlags & CRYPT_MACHINE_KEYSET) + hRootKey = HKEY_LOCAL_MACHINE; + else + hRootKey = HKEY_CURRENT_USER; + + if (!RegDeleteKeyA(hRootKey, szRegKey)) { SetLastError(ERROR_SUCCESS); return TRUE; } else { @@ -2899,6 +2905,7 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv, DWORD dwParam, BYTE *pbData, switch (dwParam) { case PP_CONTAINER: + case PP_UNIQUE_CONTAINER:/* MSDN says we can return the same value as PP_CONTAINER */ return copy_param(pbData, pdwDataLen, (CONST BYTE*)pKeyContainer->szName, strlen(pKeyContainer->szName)+1); @@ -2915,6 +2922,29 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv, DWORD dwParam, BYTE *pbData, dwTemp = CRYPT_IMPL_SOFTWARE; return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + case PP_PROVTYPE: + dwTemp = PROV_RSA_FULL; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSPEC: + dwTemp = AT_SIGNATURE | AT_KEYEXCHANGE; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSET_TYPE: + dwTemp = pKeyContainer->dwFlags & CRYPT_MACHINE_KEYSET; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSTORAGE: + dwTemp = GetVersion(); + /* for Windows NT, 95,98, Me, return CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR + * for the others, return CRYPT_SEC_DESCR + */ + if(dwTemp < 0x80000000 && ((dwTemp & 0x000000FF) != 0x00000004)) + dwTemp = CRYPT_SEC_DESCR; + else + dwTemp = CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + case PP_VERSION: dwTemp = 0x00000200; return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); diff --git a/include/wincrypt.h b/include/wincrypt.h index 2219bd5..c897e96 100644 --- a/include/wincrypt.h +++ b/include/wincrypt.h @@ -1613,6 +1613,11 @@ static const WCHAR MS_SCARD_PROV_W[] = { 'M','i','c','r','o','s','o',' #define PP_KEYSPEC 39 #define PP_ENUMEX_SIGNING_PROT 40 +/* Values returned by CryptGetProvParam of PP_KEYSTORAGE */ +#define CRYPT_SEC_DESCR 0x00000001 +#define CRYPT_PSTORE 0x00000002 +#define CRYPT_UI_PROMPT 0x00000004 + /* Crypt{Get/Set}KeyParam */ #define KP_IV 1 #define KP_SALT 2 -- 1.4.4.2

May 5, 2007

Old Autocad trials?

by Dan Kegel

http://wiki.winehq.org/LinuxApplicatonRequestSurvey says that Autocad is the #2 most requested application on Linux. The latest version might be a challenge to support, since it depends on .net 2.0, but we could start by supporting older versions. http://appdb.winehq.org/appview.php?iAppId=86 shows that R14 ran ok at one point, and I've seen a tutorial for how to run 2000 on wine, so there's hope. I couldn't find any source of Autocad R14 or '97, but looking on amazon.com I think books with trial CD-ROMs are available from autocad 2000 on (if only for LT and other hacked down variants, but I'm not picky). Before I go wild buying old autocad books from Amazon, does anyone out there have old copies of Autocad (full or trial) they'd be willing to send me for testing? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

May 5, 2007

Re: dbghelp performance

by Eric Pouech

Markus Amsler a écrit : > Eric Pouech wrote: >> Markus Amsler a écrit : >>> I've played around with dbghelp performance. My test case was >>> breaking at an unknown symbol (break gaga) while WoW was loaded in >>> the debugger (wine winedbg WoW.exe). The time was hand stopped, >>> memory usage measured with ps -AF and looked at the RSS column. >>> >>> Test Time(s) Memory Usage(MB) >>> current git 4.5 54 >>> pool_heap.patch 4.5 63 >>> process_heap.patch 4.5 126 >>> insert_first.patch 4.5 54 >>> current git, r300 115 146 >>> pool_heap.patch, r300 17 119 >>> process_heap.patch, r300 17 260 >>> insert_first.patch, r300 27 167 >>> >>> insert_first is the patch from Eric Pouech. >>> r300 means with the debug version of Mesas r300_dri.so, which has a >>> total compilation unit size of around 9.2M (compared to the second >>> biggest Wines user32 with 1.1M). >>> >>> Conclusions: >>> - current git wins with small debug files (<2M or so), pool_heap >>> wins with bigger files. insert_first, process_heap are out. >>> - small pools have less memory overhead than small heaps >>> - big pools have more memory overhead than big heaps. >>> - big pools are a lot slower than big heaps. >> thanks for the testings & timings ! >> >> you're also missing a couple of elements: >> - for the memory overhead, in the first case you consider 50 MB >> (roughly) over 10 or 20 modules while in your r300 case the impact >> (and memory difference) is only on a single module > I'm not sure what's your point is. >> - time to unload a module hasn't been computed (it's less used than >> loading a module) > Unloading is more or less instant in all cases. >> what's also strange is that the pool_heap gets lower memory >> consumption than the process heap one, which is rather not a natural >> result... I wonder if some data haven't been swapped out and aren't >> accounted for in RSS > The process_heap is the one I sent to wine-patches, which never frees > any memory. > I've also tested an improved process_heap, which stores the allocated > memory pointer in an array and frees it afterwards. Without luck, it's > slower and uses more memory the pool_heap. > > So I don't see a simple solution which only affects storage.c, is > equal or better than the current, and is significantly faster at big > debug files. Any ideas? > > Markus > > Hi Markus, does the slightly modified version of pool_heap improve your performances (it shouldn't modify the perf for large files(or just a bit), but should reduce memory consumption for small pools (from 1 to 2M depending on your configuration) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams) diff --git a/dlls/dbghelp/dbghelp_private.h b/dlls/dbghelp/dbghelp_private.h index a7f3235..5f8d1c4 100644 --- a/dlls/dbghelp/dbghelp_private.h +++ b/dlls/dbghelp/dbghelp_private.h @@ -35,13 +35,12 @@ /* #define USE_STATS */ -struct pool /* poor's man */ +struct pool { - struct pool_arena* first; - unsigned arena_size; + HANDLE heap; }; -void pool_init(struct pool* a, unsigned arena_size); +void pool_init(struct pool* a); void pool_destroy(struct pool* a); void* pool_alloc(struct pool* a, unsigned len); /* void* pool_realloc(struct pool* a, void* p, diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c index bf8435f..1364834 100644 --- a/dlls/dbghelp/dwarf.c +++ b/dlls/dbghelp/dwarf.c @@ -1960,7 +1960,7 @@ static BOOL dwarf2_parse_compilation_unit(const dwarf2_section_t* sections, return FALSE; } - pool_init(&ctx.pool, 65536); + pool_init(&ctx.pool); ctx.sections = sections; ctx.section = section_debug; ctx.module = module; diff --git a/dlls/dbghelp/elf_module.c b/dlls/dbghelp/elf_module.c index b844e59..75d0821 100644 --- a/dlls/dbghelp/elf_module.c +++ b/dlls/dbghelp/elf_module.c @@ -1131,7 +1131,7 @@ BOOL elf_load_debug_info(struct module* module, struct elf_file_map* fmap) return FALSE; } - pool_init(&pool, 65536); + pool_init(&pool); hash_table_init(&pool, &ht_symtab, 256); if (!fmap) diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c index 3093c58..adbdce0 100644 --- a/dlls/dbghelp/module.c +++ b/dlls/dbghelp/module.c @@ -138,7 +138,7 @@ struct module* module_new(struct process* pcs, const WCHAR* name, get_module_type(type, virtual), mod_addr, mod_addr + size, debugstr_w(name)); - pool_init(&module->pool, 65536); + pool_init(&module->pool); module->module.SizeOfStruct = sizeof(module->module); module->module.BaseOfImage = mod_addr; diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c index e196143..6ccac54 100644 --- a/dlls/dbghelp/storage.c +++ b/dlls/dbghelp/storage.c @@ -38,94 +38,25 @@ struct pool_arena char* current; }; -void pool_init(struct pool* a, unsigned arena_size) +void pool_init(struct pool* pool) { - a->arena_size = arena_size; - a->first = NULL; + pool->heap = HeapCreate(HEAP_NO_SERIALIZE, 0, 0); } void pool_destroy(struct pool* pool) { - struct pool_arena* arena; - struct pool_arena* next; - -#ifdef USE_STATS - unsigned alloc, used, num; - - for (alloc = used = num = 0, arena = pool->first; arena; arena = arena->next) - { - alloc += pool->arena_size; - used += arena->current - (char*)arena; - num++; - } - FIXME("STATS: pool %p has allocated %u kbytes, used %u kbytes in %u arenas,\n" - "\t\t\t\tnon-allocation ratio: %.2f%%\n", - pool, alloc >> 10, used >> 10, num, 100.0 - (float)used / (float)alloc * 100.0); -#endif - - for (arena = pool->first; arena; arena = next) - { - next = arena->next; - HeapFree(GetProcessHeap(), 0, arena); - } - pool_init(pool, 0); + HeapDestroy(pool->heap); + pool->heap = NULL; } void* pool_alloc(struct pool* pool, unsigned len) { - struct pool_arena** parena; - struct pool_arena* arena; - void* ret; - - len = (len + 3) & ~3; /* round up size on DWORD boundary */ - assert(sizeof(struct pool_arena) + len <= pool->arena_size && len); - - for (parena = &pool->first; *parena; parena = &(*parena)->next) - { - if ((char*)(*parena) + pool->arena_size - (*parena)->current >= len) - { - ret = (*parena)->current; - (*parena)->current += len; - return ret; - } - } - - arena = HeapAlloc(GetProcessHeap(), 0, pool->arena_size); - if (!arena) {FIXME("OOM\n");return NULL;} - - *parena = arena; - - ret = (char*)arena + sizeof(*arena); - arena->next = NULL; - arena->current = (char*)ret + len; - return ret; -} - -static struct pool_arena* pool_is_last(const struct pool* pool, const void* p, unsigned old_size) -{ - struct pool_arena* arena; - - for (arena = pool->first; arena; arena = arena->next) - { - if (arena->current == (const char*)p + old_size) return arena; - } - return NULL; + return HeapAlloc(pool->heap, 0, len); } -static void* pool_realloc(struct pool* pool, void* p, unsigned old_size, unsigned new_size) +static void* pool_realloc(struct pool* pool, void* p, unsigned new_size) { - struct pool_arena* arena; - void* new; - - if ((arena = pool_is_last(pool, p, old_size)) && - (char*)p + new_size <= (char*)arena + pool->arena_size) - { - arena->current = (char*)p + new_size; - return p; - } - if ((new = pool_alloc(pool, new_size)) && old_size) - memcpy(new, p, min(old_size, new_size)); - return new; + return p ? HeapReAlloc(pool->heap, 0, p, new_size) : HeapAlloc(pool->heap, 0, new_size); } char* pool_strdup(struct pool* pool, const char* str) @@ -181,7 +112,6 @@ void* vector_add(struct vector* v, struct pool* pool) if (ncurr == (v->num_buckets << v->shift)) { v->buckets = pool_realloc(pool, v->buckets, - v->num_buckets * sizeof(void*), (v->num_buckets + 1) * sizeof(void*)); v->buckets[v->num_buckets] = pool_alloc(pool, v->elt_size << v->shift); return v->buckets[v->num_buckets++];

May 5, 2007

Re: msi automation IDL parameter names

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > This obviously won't work if the parameter names are different. > > However, the procedure to cleanly implement an IDL file with > compatible parameter names isn't clear to me. I would think we would > need legal advice as to how to do this. It's no different from the other elements of the interface, if the parameters are required for compatibility then there's no room for creativity and thus no copyright violation, you can look up the names in oleview and use the same ones when writing your IDL. -- Alexandre Julliard julliard(a)winehq.org

May 5, 2007

Fedora Packages

by Andreas Bierfert

Hi, here is some news/status update on the fedora packages: As people have been complaining about the link on the winehq webpage I have taken the time to make a summary page[1] on the fedora wiki which is easier for me to maintain and keep up-to-date and is probably more helpful. I would request that the link in the download section is changed to that page. I have good news for users of RHEL/Centos: After collaborating with some other maintainers from the fedora project I finally got all dependencies for wine into the EPEL[2] repository (which is something like Fedora Extras but for RHEL/Centos). This means that there now is a wine version for users of RHEL/Centos 5 (it may take a couple of hours or a day till it is published to the repository and all mirrors have synced it). It will probably take a couple of days but I finished testing these changes for RHEL/Centos 4 as well so there should also be a version out soon. Comments and suggestions are (like always) very much welcome. Regards, Andreas [1] - http://fedoraproject.org/wiki/AndreasBierfert/Wine [2] - http://fedoraproject.org/wiki/EPEL -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

May 5, 2007

Re: Console output with different codepages - the result.

by Eric Pouech

Kirill K. Smirnov a écrit : >> В сообщении от 23 апреля 2007 16:11 вы написали: >> >>> "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: >>> >>>>>>> The written strings in 866 and 1251 code pages are only readable >>>>>>> when output console code page matches the string encoding. >>>>>>> >>>>>> This is in wine. >>>>>> In windows only cp866 is readable regardless of ConsoleOutputCP. >>>>>> >>>>> As I said I tested under Windows (XP) only, and SetConsoleOutputCP >>>>> does change the behaviour of WriteConsoleA for me. If it wouldn't >>>>> I'd call it a bug. >>>>> >>>> I tested under Windows 2003 and SetConsoleOutputCP does NOT change the >>>> behaviour of WriteConsoleA for me. >>>> Does Windows play us a trick? >>>> >>> No the difference in observed behaviour was caused by the fact that I ran >>> the test under FAR, once I run it under cmd.exe I see what you do. >>> >> Ahhh, I understood!!! >> >> You test does not return codepage back to 866. My version of your test does >> it. >> Far Manager somehow checks codepage and converts characters accordingly. >> I've removed the last convertion back to cp866 and observed the same >> behaviur as you. >> >> Thus, I can proclaim WriteConsoleA buggy. >> > > The final result: > 1) WriteConsoleA is OK - while preparing the tests the truth was revealed. > 2) The main issue is hidden in Windows console renderer. I've tried three > different ways: windowed with TrueType font (lucida), windowed with Fixedsys > font and fullscreen mode. > a) Lucida Console font: the behaviour in wine and windows the same. (Dmitry > observed this). > b) Fixedsys: > wine - the same as with Lucida Console font - nothing changed. > windows - only cp866 is OK. (I observed this) > c) Fullscreen. In this case font codepage is changed immediately: previously > written text is changed. This behaviour in unique for fullscreen mode. > > Thus I can conclude that console codepages are used by console renderer too, > not just by WriteConsoleA. > Should this windows behaviour be implemented in wine? I think no, it is too > insane and needless. But this should be kept in mind, maybe update docs? > just a dummy question... does the different fonts your tests refer to have all the glyphs required ? (or said differently, isn't this a font issue about the required glyphs for russian ?) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 5, 2007

Re: wine.inf: Add AllUsersProfile and associated entries to the registry [try 2].

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Why should it go into shell32? It only setting up user related stuff, > not the all user's / global. That part belongs in kernel32. And since > you didn't like it there, it should go into registry during the install. Yes, but the way to put it in the registry is to do that in the shell32 registration, where all the user profile stuff is done. -- Alexandre Julliard julliard(a)winehq.org

May 5, 2007

Re: USB device support in wine

by Damjan Jovanovic

On 5/5/07, Jon Burgess <jkburges(a)gmail.com> wrote: > > > > > 4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to > > NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably > > through libusb), and modify ntdll to forward the appropriate reads, > > writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file > > can handle them. This is the only way that works with .SYS files > > out-of-the-box, the others all require a rewrite of the .SYS driver's > > functionality. Architecturally, this is the best way, you wouldn't > > need to change any code in wine to add a new driver. > > > > Way 4 is probably the best and I hope it works at some stage, but it's > > still a long way off seeing as how NTOSKRNL.EXE itself still isn't in > > wine. > > Correct me if I'm wrong, but you're saying that this approach would enable > wine to work with (almost?) any USB device, which has a vendor specific, > kernel-mode driver, using the vendor's supplied driver out-of-the-box. Yes. > Sounds like the best approach to me too. > > Maybe there are other people out there with the same problem as me, (or > simply a desire to get better USB support in to wine) who would be > interested in working on this too? But it's a lot of work, and very few people know how to write Windows drivers. NTOSKRNL.EXE has been around for a year or 2 now, and it still hasn't been accepted into wine. On a brighter note, NDISWRAPPER already works with some USB drivers, so it can't be that hard to do. > Jono Damjan

May 5, 2007

Re: USB device support in wine

by Jon Burgess

> > > 4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to > NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably > through libusb), and modify ntdll to forward the appropriate reads, > writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file > can handle them. This is the only way that works with .SYS files > out-of-the-box, the others all require a rewrite of the .SYS driver's > functionality. Architecturally, this is the best way, you wouldn't > need to change any code in wine to add a new driver. > > Way 4 is probably the best and I hope it works at some stage, but it's > still a long way off seeing as how NTOSKRNL.EXE itself still isn't in > wine. Correct me if I'm wrong, but you're saying that this approach would enable wine to work with (almost?) any USB device, which has a vendor specific, kernel-mode driver, using the vendor's supplied driver out-of-the-box. Sounds like the best approach to me too. Maybe there are other people out there with the same problem as me, (or simply a desire to get better USB support in to wine) who would be interested in working on this too? Jono

May 5, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups.

by Vitaly Budovski

Vitaliy Margolen wrote: > Vitaly Budovski wrote: > >> Vitaliy Margolen wrote: >> >> Thanks for the tip. Unfortunately in this instance it will not work as I >> do in fact query more than a < b. See the nearest function in patch 2. >> > And what is so special about subtracting one from the other? > > A lot actually. As an example with squared distances: a^2 - b^2 <= c^2. If a^2 = 27, b^2 = 16, c^2 = 9, then 27 - 16 <= 9 is false. However, if we use the square root in distance calculations, sqrt(27) - 4 <= 3 is true. As you can see, we get entirely different results. >> The qsort function I use internally takes that particular function pointer. >> > And the problem is what? Any pointer is compatible with void* (not other > way around). > > Vitaliy Margolen. > > I get a warning from gcc: passing argument 4 of ‘qsort’ from incompatible pointer type.

May 4, 2007

Re: wine.inf: Add AllUsersProfile and associated entries to the registry [try 2].

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> Anything wrong with this 3 liner? > > This should go in shell32. Why should it go into shell32? It only setting up user related stuff, not the all user's / global. That part belongs in kernel32. And since you didn't like it there, it should go into registry during the install. Vitaliy.

May 4, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups.

by Vitaliy Margolen

Vitaly Budovski wrote: > Vitaliy Margolen wrote: >> Vitaly Budovski wrote: >> >>> Make use of the Triangle Inequality Nearest Neighbour algorithm to >>> find the >>> nearest colour more efficiently than a simple linear search. The >>> improvements >>> are most noticeable with a palette of 256 colours. Testing shows >>> approximately >>> 3-4x performance increase for 256 colours. >>> --- >>> >> >> Overall idea looks good, however the big problem with it is use of float >> point numbers. Fortunately you can get rid of them and use integers >> instead. Because you never use the distance in the calculations, but >> only to compare against other distances, you can skip "sqrt" and just >> compare squares, as the original code does. That will give you even more >> speed improvements. > > Thanks for the tip. Unfortunately in this instance it will not work as I > do in fact query more than a < b. See the nearest function in patch 2. And what is so special about subtracting one from the other? >> Few more nitpicks about this and other patches in the series: >> >>> +static int compare_distance(const void *left, const void *right) >>> +{ >>> + const struct tinn *l = left; >>> + const struct tinn *r = right; >>> >> >> Please don't use void pointers. Use typed pointers, especially that you >> cast them to a hard-coded type. > > The qsort function I use internally takes that particular function pointer. And the problem is what? Any pointer is compatible with void* (not other way around). Vitaliy Margolen.

May 4, 2007

Re: Linuxworld San Francisco?

by Tom Spear

On 5/4/07, Dan Kegel <dank06(a)kegel.com> wrote: > I was thinking of volunteering, too. > > On 5/4/07, Scott Ritchie <scott(a)open-vote.org> wrote: > > Oooh, I'll do it! > > > > Now I just need to come up with a specific topic other than "Wine" > > > > Thanks, > > Scott Ritchie > > > > On Fri, 2007-05-04 at 10:30 -0500, Jeremy White wrote: > > > Well, we'll be there with a booth. > > > > > > I think I've given enough Wine talks through the years at LinuxWorld > > > that they're tired of me :-/. But, to be honest, I don't think I submitted > > > a proposal this year. I think if someone else wanted to give the talk, > > > they'd probably appreciate a fresh face. > > > > > > Cheers, > > > > > > Jeremy > > > > > > > -----Original Message----- > > > > From: wine-devel-bounces(a)winehq.org > > > > [mailto:wine-devel-bounces(a)winehq.org] On Behalf Of Dan Kegel > > > > Sent: Friday, May 04, 2007 10:13 AM > > > > To: wine-devel(a)winehq.org > > > > Subject: Linuxworld San Francisco? > > > > > > > > Is anyone going to Linuxworld, August 6-9 in San Francisco? > > > > A guy working on a possible large migration > > > > said he'd be there, and was wondering if there's > > > > going to be a Wine BOF. > > > > I might go just to chat with him. > > > > > > > > Also, I see no Wine-related talks on the program. > > > > http://www.linuxworldexpo.com/live/12/events/12SFO07A/conferen > > > > ce/tracks > > > > If all the great stuff I expect actually happens > > > > this summer, there's going to be a lot to talk about, > > > > seems like a good year for a Wine talk there...? > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > > > I'd like to try to be there to listen to the talk, but it depends on finances and if work would let me off.. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 4, 2007

Re: Linuxworld San Francisco?

by Dan Kegel

I was thinking of volunteering, too. On 5/4/07, Scott Ritchie <scott(a)open-vote.org> wrote: > Oooh, I'll do it! > > Now I just need to come up with a specific topic other than "Wine" > > Thanks, > Scott Ritchie > > On Fri, 2007-05-04 at 10:30 -0500, Jeremy White wrote: > > Well, we'll be there with a booth. > > > > I think I've given enough Wine talks through the years at LinuxWorld > > that they're tired of me :-/. But, to be honest, I don't think I submitted > > a proposal this year. I think if someone else wanted to give the talk, > > they'd probably appreciate a fresh face. > > > > Cheers, > > > > Jeremy > > > > > -----Original Message----- > > > From: wine-devel-bounces(a)winehq.org > > > [mailto:wine-devel-bounces(a)winehq.org] On Behalf Of Dan Kegel > > > Sent: Friday, May 04, 2007 10:13 AM > > > To: wine-devel(a)winehq.org > > > Subject: Linuxworld San Francisco? > > > > > > Is anyone going to Linuxworld, August 6-9 in San Francisco? > > > A guy working on a possible large migration > > > said he'd be there, and was wondering if there's > > > going to be a Wine BOF. > > > I might go just to chat with him. > > > > > > Also, I see no Wine-related talks on the program. > > > http://www.linuxworldexpo.com/live/12/events/12SFO07A/conferen > > > ce/tracks > > > If all the great stuff I expect actually happens > > > this summer, there's going to be a lot to talk about, > > > seems like a good year for a Wine talk there...? > > > > > > > > > > > > > > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

May 4, 2007

change generic.ppd file

by Alisson Gomes

Mrs, I do can recompile wine with change generic.ppd file? only change the generic.ppd? Or exist a version of wine i can configure? thanks, Alisson Gomes

May 4, 2007

RE: Linuxworld San Francisco?

by Scott Ritchie

Oooh, I'll do it! Now I just need to come up with a specific topic other than "Wine" Thanks, Scott Ritchie On Fri, 2007-05-04 at 10:30 -0500, Jeremy White wrote: > Well, we'll be there with a booth. > > I think I've given enough Wine talks through the years at LinuxWorld > that they're tired of me :-/. But, to be honest, I don't think I submitted > a proposal this year. I think if someone else wanted to give the talk, > they'd probably appreciate a fresh face. > > Cheers, > > Jeremy > > > -----Original Message----- > > From: wine-devel-bounces(a)winehq.org > > [mailto:wine-devel-bounces(a)winehq.org] On Behalf Of Dan Kegel > > Sent: Friday, May 04, 2007 10:13 AM > > To: wine-devel(a)winehq.org > > Subject: Linuxworld San Francisco? > > > > Is anyone going to Linuxworld, August 6-9 in San Francisco? > > A guy working on a possible large migration > > said he'd be there, and was wondering if there's > > going to be a Wine BOF. > > I might go just to chat with him. > > > > Also, I see no Wine-related talks on the program. > > http://www.linuxworldexpo.com/live/12/events/12SFO07A/conferen > > ce/tracks > > If all the great stuff I expect actually happens > > this summer, there's going to be a lot to talk about, > > seems like a good year for a Wine talk there...? > > > > > > > > >

May 4, 2007

Re: [1/5] WineD3D: Software vertex blending

by Stefan Dösinger

Am Freitag 04 Mai 2007 17:42 schrieb H. Verbeet: > On 04/05/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > This patch makes a copy of the strided data from the device if needed, > > and it explicitly fixes the fixed function data. > > I still think messing with the strided data like that is rather hacky :-/ My idea is to keep the needs of software emulation out of the state management and vertex buffer code. It is not a nice thing to mess with the strided data this way, if its too messy I'm fine with dropping this patch altogether.

May 4, 2007

Re: [PATCH 2/3] Implement TINN algorithm.

by Stefan Dösinger

> The algorithm is quite generic really. It basically exists to solve the > nearest neighbour problem, so anywhere that such a solution is needed > this algorithm could be used. I had a bit of a look and I think there > are another few sections that this could be used. WineD3D may have use for it too, but I haven't checked yet. It does 256 bit palette <-> A8R8G8B8 conversion

May 4, 2007

Re: msi automation IDL parameter names

by Robert Shearman

Misha Koshelev wrote: > So I am thinking of implementing some more OLE automation functions and > just wanted to clarify one thing before I start doing this. > Specifically, parameter names can be arbitrary as far as OLE automation > in general is concerned, however for MSI in particular when you use the > incorrect parameters for a method/property (for example one instead of > two) it throws an exception whose description is > "Methodname,Param1Name,Param2Name,etc". I had to make a todo_wine in my > conformance test in this because our parameter names are currently > different (intentionally as per instructions reference above). > > I doubt that any application would depend on the exact description of > such an exception, but nonetheless it might be confusing to get > different parameter names, say, for a developer who is making an MSI (on > Wine???) and is trying to debug his MSI script. In any case, I doubt it > matters much but I just wanted to make sure if we should stick with > using different parameter names or switch to the same ones (I don't know > what kind of copyright issues this really raises or avoids). Otherwise, > it would be a pain to change this later on if we already have everything > implemented and we find that it is necessary to have the same exception > string for some reason. > Actually, I forgot that with typelibs parameter names are part of the interface. For example, in some scripting languages (including VBScript and JScript I think) you can do the following: Methodname(Param1Name=1, Param2Name=2) This obviously won't work if the parameter names are different. However, the procedure to cleanly implement an IDL file with compatible parameter names isn't clear to me. I would think we would need legal advice as to how to do this. -- Rob Shearman

May 4, 2007

msi automation IDL parameter names

by Misha Koshelev

On Thu, 2007-04-05 at 09:35 +0200, Alexandre Julliard wrote: > That would be fine, anything that is required by the interface can be > the same, so that would mean essentially everything except parameter > names and help strings. I don't think you need to change the order of > attributes from what oleview shows. > So I am thinking of implementing some more OLE automation functions and just wanted to clarify one thing before I start doing this. Specifically, parameter names can be arbitrary as far as OLE automation in general is concerned, however for MSI in particular when you use the incorrect parameters for a method/property (for example one instead of two) it throws an exception whose description is "Methodname,Param1Name,Param2Name,etc". I had to make a todo_wine in my conformance test in this because our parameter names are currently different (intentionally as per instructions reference above). I doubt that any application would depend on the exact description of such an exception, but nonetheless it might be confusing to get different parameter names, say, for a developer who is making an MSI (on Wine???) and is trying to debug his MSI script. In any case, I doubt it matters much but I just wanted to make sure if we should stick with using different parameter names or switch to the same ones (I don't know what kind of copyright issues this really raises or avoids). Otherwise, it would be a pain to change this later on if we already have everything implemented and we find that it is necessary to have the same exception string for some reason. Thank you all for your comments and all your help with my code. Misha

May 4, 2007

Re: [1/5] WineD3D: Software vertex blending

by H. Verbeet

On 04/05/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This patch makes a copy of the strided data from the device if needed, and it > explicitly fixes the fixed function data. > I still think messing with the strided data like that is rather hacky :-/

May 4, 2007

RE: Linuxworld San Francisco?

by Jeremy White

> said he'd be there, and was wondering if there's > going to be a Wine BOF. > I might go just to chat with him. Oh, and sorry; we also do try to run a BOF (we often bring a few bottles of Wine to share at them :-/). Those tend to be somewhat adhoc; I seem to recall that we sign up for them on the spot, rather than ahead of time, but perhaps that's changed. Cheers, Jeremy

May 4, 2007

RE: Linuxworld San Francisco?

by Jeremy White

Well, we'll be there with a booth. I think I've given enough Wine talks through the years at LinuxWorld that they're tired of me :-/. But, to be honest, I don't think I submitted a proposal this year. I think if someone else wanted to give the talk, they'd probably appreciate a fresh face. Cheers, Jeremy > -----Original Message----- > From: wine-devel-bounces(a)winehq.org > [mailto:wine-devel-bounces(a)winehq.org] On Behalf Of Dan Kegel > Sent: Friday, May 04, 2007 10:13 AM > To: wine-devel(a)winehq.org > Subject: Linuxworld San Francisco? > > Is anyone going to Linuxworld, August 6-9 in San Francisco? > A guy working on a possible large migration > said he'd be there, and was wondering if there's > going to be a Wine BOF. > I might go just to chat with him. > > Also, I see no Wine-related talks on the program. > http://www.linuxworldexpo.com/live/12/events/12SFO07A/conferen > ce/tracks > If all the great stuff I expect actually happens > this summer, there's going to be a lot to talk about, > seems like a good year for a Wine talk there...? > > >

May 4, 2007

Linuxworld San Francisco?

by Dan Kegel

Is anyone going to Linuxworld, August 6-9 in San Francisco? A guy working on a possible large migration said he'd be there, and was wondering if there's going to be a Wine BOF. I might go just to chat with him. Also, I see no Wine-related talks on the program. http://www.linuxworldexpo.com/live/12/events/12SFO07A/conference/tracks If all the great stuff I expect actually happens this summer, there's going to be a lot to talk about, seems like a good year for a Wine talk there...?

May 4, 2007

Re: Implement MsiBreak Feature - Bug 8243

by Dan Kegel

On 5/3/07, Dan Kegel <dank(a)kegel.com> wrote: > > Do we really need to write out unix pid? > > AFAIK Winedbg can attach to windows process IDs just fine. > ... > Hey, Anastasius, do you really need the unix pid? A.F. replied "if winedbg works with windows PIDs then its ok to print out/use windows PIDs only. Just modify the format string buildup and remove the two extra headers which got pulled in due to getpid()."

May 4, 2007

Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups.

by Vitaly Budovski

Vitaliy Margolen wrote: > Vitaly Budovski wrote: > >> Make use of the Triangle Inequality Nearest Neighbour algorithm to find the >> nearest colour more efficiently than a simple linear search. The improvements >> are most noticeable with a palette of 256 colours. Testing shows approximately >> 3-4x performance increase for 256 colours. >> --- >> > > Overall idea looks good, however the big problem with it is use of float > point numbers. Fortunately you can get rid of them and use integers > instead. Because you never use the distance in the calculations, but > only to compare against other distances, you can skip "sqrt" and just > compare squares, as the original code does. That will give you even more > speed improvements. > Thanks for the tip. Unfortunately in this instance it will not work as I do in fact query more than a < b. See the nearest function in patch 2. > Few more nitpicks about this and other patches in the series: > >> +static int compare_distance(const void *left, const void *right) >> +{ >> + const struct tinn *l = left; >> + const struct tinn *r = right; >> > > Please don't use void pointers. Use typed pointers, especially that you > cast them to a hard-coded type. > > The qsort function I use internally takes that particular function pointer. >> +const void *init_tinn(struct tinn *dest, const void *buf, size_t num, >> + size_t size, float (*distance)(const void *, const void *)) >> +{ >> + size_t i; >> + size_t ref = rand() % num; >> > I'm not so sure using random reference point really necessary. > > This is actually very important. By randomly selecting a reference point, the chance that we get worst-case linear performance out of the algorithm becomes extremely small. >> +static struct tinn tinnPalette[256]; >> + >> > > This won't work well with multi-threaded apps. You probably should make > it on the stack for each X11DRV_DIB_SetImageBits_* function. Especially > that some need only 2 elements. Btw, how big of the gain/loss whill > there be for 1-bit and 4-bit DIBs? > > I'm sure you are right. I'll change the array allocation as you suggest. I'm sure you mean the X11DRV_DIB_GetImageBits_* though. As a percentage probably quite significant, linear would be reasonably fast for small sized palettes though. Although this algorithm will never really be any slower. >> + q.rgbRed = srcval.peRed; >> + q.rgbGreen = srcval.peGreen; >> + q.rgbBlue = srcval.peBlue; >> > > Looks much better, if written as: > q = srcval; > I guess it does. I had to do a lot of copy+paste though so I kept the format the same throughout, since colors are not always retrieved in that way. > >> - ((srcval >> 7) & 0xf8) | /* r */ >> - ((srcval >> 12) & 0x07), >> - ((srcval >> 2) & 0xf8) | /* g */ >> - ((srcval >> 7) & 0x07), >> - ((srcval << 3) & 0xf8) | /* b */ >> - ((srcval >> 2) & 0x07) ) << (7-(x&7)) ); >> + >> + q.rgbRed = ((srcval >> 7) & 0xf8) | >> + ((srcval >> 12) & 0x07); >> + q.rgbGreen = ((srcval >> 2) & 0xf8) | >> + ((srcval >> 7) & 0x07); >> + q.rgbBlue = ((srcval << 3) & 0xf8) | >> + ((srcval >> 2) & 0x07); >> > What happened to the comments and alignment? > > Vitaliy Margolen. > > > The comments are not really needed now. First of all they weren't very descriptive, and also I'm now assigning the colors to individual bytes which are named appropriately so it is easy to see what they refer to. The code looks to be aligned I think.

May 4, 2007

Re: wine.inf: Add AllUsersProfile and associated entries to the registry [try 2].

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Anything wrong with this 3 liner? This should go in shell32. -- Alexandre Julliard julliard(a)winehq.org

May 4, 2007

Re: [PATCH 2/3] Implement TINN algorithm.

by Vitaly Budovski

Michael Stefaniuc wrote: > Vitaly Budovski wrote: > >> Implement the Triangle Inequality Nearest Neighbour algorithm as >> described in >> http://post.queensu.ca/~greensm/papers/tinn.pdf >> --- >> include/wine/tinn.h | 154 >> > Do you need that somewhere else then in the X driver? If not putting > that directly into dlls/winex11.drv/ makes more sense. > > >> +++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 154 insertions(+), 0 deletions(-) >> > > bye > michael > The algorithm is quite generic really. It basically exists to solve the nearest neighbour problem, so anywhere that such a solution is needed this algorithm could be used. I had a bit of a look and I think there are another few sections that this could be used.

May 4, 2007

Re: Testing and VarBstrFromDate (was Re: OLE2A)

by Bill Medland

On Fri, 2007-04-05 at 13:34 +0200, Michael Stefaniuc wrote: > Bill Medland wrote: > > On Thu, 2007-03-05 at 07:29 -0700, Bill Medland wrote: > > > >>On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote: > >> > >>>On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote: > >>> > >>>>Does anyone know where a call to OLE2A is going to enter wine? > >>>>Presumably OLE2A returning null means that the thread ran out of stack > >>>>space? > >>> > >>>What is OLE2A? I do not see it mentioned anyewhere in the Wine source. > >>> > >>>Any more debugging output? > >>> > >>>Ciao, Marcus > >> > >>Hi Marcus, thanks for taking interest. > >> > >>A little late now, I think. The problem is not where I thought it was. > >> > >>OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, > >>allocating memory on the stack and calling one of the wide-to-narrow > >>conversions. > >> > >>Our program was behaving quite strangely, throwing an exception from > >>some code that should not throw an exception. > >> > >>I traced it down to some code that did an OLE2A on a BSTR, called strlen > >>on the return and then passed the same narrow string to a function. > >>The problem occurred when the OLE2A returned a null pointer. Due to an > >>oversight I thought the BSTR was non-null and assumed that somehow the > >>underlying alloca must be returning null (i.e. was detecting out-of- > >>stack-space). > >> > >>Now I discover that the BSTR itself was also NULL so that makes sense. > >> > >>I presume what happens is all that magic that traps the segment > >>violation on strlen(0) didn't quite handle whatever optimised code was > >>being generated for our case. > >> > >>However what I am also investigating is where the original NULL BSTR > >>came from; possibly a defect in VariantChangeTypeEx. > >> > > > > > > Actually VariantChangeType was returning E_INVALIDPARAM and a VT_EMPTY > > and the caller wasn't checking the result. > > > > However I think VariantChangeType was wrong in this case. > > > > > >>Bill > >> > >> > >> > > > > > > So. > > > > 1. Am I misunderstanding something about the tests these days? > > > > (I am about to add two edge tests on SystemTimeToFileTime in time.c and > > GetDateFormatW in locale.c) > > > > I go into dlls/kernel32/tests and make tests and it fails (change.c, > > locale.c) > Did you try to run make test a second time? Sometimes that makes it go > further. Yes. Even make clean. > > > Should that disconcert me? > Yes and no. The theory says that the tests should run on everybodies > computer out of the box. The practice disagrees with this and afair only > on Alexandre's computer all tests succeed. We should fix that and from > time to time somebody tries to do it but it's no sexy work so that > effort dies pretty soon. > What i do is to run the tests on an origin Wine checkout and then on my > modified tree and see if i get any additional failures/successes. > That's what I figured. > > 2. How to fix the VarBstrFromDate? > > > > VarBstrFromDate(-657434.0 (DATE_MIN), 0x409, 0x80000000, wherever) > > fails because VariantTimeToSystemTime successfully converts that to > > 1/1/100 but then VarBstrFromDate tries to format that using > > GetDateFormat, which is not feasible because the SystemTime is out of > > range. > > > > Is there an existing low level routine that can handle the conversion > > for such a small date > Add a test for the VarBstrFromDate(-657434.0 ... call and see how > Windows handles that. When you know the outcome you'll know how to fix it. Invalid assumption. Knowing the problem doesn't automatically give us the answer. > I know the outcome; for the flags and lcid I was using it is 1/1/100 (n.b. 3 digit year). That is in the patch I submitted yesterday. What I am after is the most efficient way to implement the fix while maintaining compatibility and not messing up the code base. How does this sound? Add an argument to NLS_GetDateTimeFormatW/A to flag whether the systemtime should be constrained to >= 1/1/1601 and add a "wine" routine that calls it with that flag set to NO. and use that. In that way we can keep the formatting code in one place and still get the extended date range that oleaut32 needs. > bye > michael > Bill

May 4, 2007

RE: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups.

by Vitaliy Margolen

Vitaly Budovski wrote: > Make use of the Triangle Inequality Nearest Neighbour algorithm to find the > nearest colour more efficiently than a simple linear search. The improvements > are most noticeable with a palette of 256 colours. Testing shows approximately > 3-4x performance increase for 256 colours. > --- Overall idea looks good, however the big problem with it is use of float point numbers. Fortunately you can get rid of them and use integers instead. Because you never use the distance in the calculations, but only to compare against other distances, you can skip "sqrt" and just compare squares, as the original code does. That will give you even more speed improvements. Few more nitpicks about this and other patches in the series: > +static int compare_distance(const void *left, const void *right) > +{ > + const struct tinn *l = left; > + const struct tinn *r = right; Please don't use void pointers. Use typed pointers, especially that you cast them to a hard-coded type. > +const void *init_tinn(struct tinn *dest, const void *buf, size_t num, > + size_t size, float (*distance)(const void *, const void *)) > +{ > + size_t i; > + size_t ref = rand() % num; I'm not so sure using random reference point really necessary. > +static struct tinn tinnPalette[256]; > + This won't work well with multi-threaded apps. You probably should make it on the stack for each X11DRV_DIB_SetImageBits_* function. Especially that some need only 2 elements. Btw, how big of the gain/loss whill there be for 1-bit and 4-bit DIBs? > + q.rgbRed = srcval.peRed; > + q.rgbGreen = srcval.peGreen; > + q.rgbBlue = srcval.peBlue; Looks much better, if written as: q = srcval; > - ((srcval >> 7) & 0xf8) | /* r */ > - ((srcval >> 12) & 0x07), > - ((srcval >> 2) & 0xf8) | /* g */ > - ((srcval >> 7) & 0x07), > - ((srcval << 3) & 0xf8) | /* b */ > - ((srcval >> 2) & 0x07) ) << (7-(x&7)) ); > + > + q.rgbRed = ((srcval >> 7) & 0xf8) | > + ((srcval >> 12) & 0x07); > + q.rgbGreen = ((srcval >> 2) & 0xf8) | > + ((srcval >> 7) & 0x07); > + q.rgbBlue = ((srcval << 3) & 0xf8) | > + ((srcval >> 2) & 0x07); What happened to the comments and alignment? Vitaliy Margolen.

May 4, 2007

Re: [PATCH 2/3] Implement TINN algorithm.

by Michael Stefaniuc

Vitaly Budovski wrote: > > Implement the Triangle Inequality Nearest Neighbour algorithm as > described in > http://post.queensu.ca/~greensm/papers/tinn.pdf > --- > include/wine/tinn.h | 154 Do you need that somewhere else then in the X driver? If not putting that directly into dlls/winex11.drv/ makes more sense. > +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 154 insertions(+), 0 deletions(-) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

May 4, 2007

RE: wine.inf: Add AllUsersProfile and associated entries to the registry [try 2].

by Vitaliy Margolen

Anything wrong with this 3 liner? Vitaliy Margolen wrote: > --- > tools/wine.inf | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) >

May 4, 2007

Re: USB device support in wine

by Marcus Meissner

On Fri, May 04, 2007 at 07:43:00AM -0400, Kuba Ober wrote: > > There is no standard user-mode interface for accessing USB hardware - > > there is no equivalent of Linux's libusb on Windows > > But there is, just that most vendors don't use it. Lots of Windows driver vendors use the USBD.SYS (spelling?) driver abstraction though. Ciao, Marcus

May 4, 2007

Re: USB device support in wine

by Damjan Jovanovic

On 5/4/07, Kuba Ober <kuba(a)mareimbrium.org> wrote: > > There is no standard user-mode interface for accessing USB hardware - > > there is no equivalent of Linux's libusb on Windows > > But there is, just that most vendors don't use it. There is libusb-win32, but it uses its own kernel-mode driver. Vista has a user-space driver framework for some types of hardware. It supports USB drivers, and I think Microsoft did a backport to Windows XP as well. Hopefully vendors will start to use it instead of writing kernel-mode drivers, then we can easily use those drivers from wine :-). Damjan

May 4, 2007

Re: USB device support in wine

by Kuba Ober

On Friday 04 May 2007, you wrote: > > There is no standard user-mode interface for accessing USB hardware - > > there is no equivalent of Linux's libusb on Windows > > But there is, just that most vendors don't use it. http://libusb-win32.sourceforge.net/ It doesn't seem maintained, but it did work in WIN98 era at least (used it back then). > > (there is > > apparently some user-space USB stuff in mingw's headers, but I > > couldn't find any official docs on it, and it's not enough to write a > > user-space driver because there is no bulk/interrupt/isochronous pipe [...] Woopty, finger slipped on enter :) Kuba

May 4, 2007

Re: USB device support in wine

by Detlef Riekenberg

On Fr, 2007-05-04 at 10:37 +0800, Jon Burgess wrote: > (Serato Scratch Live: http://www.rane.com/scratch.html) for which the > software appears to run ok under wine (not that I am able to test much > of its functionality on the other hand), but is utterly useless > without support for its associated USB hardware device. The driver is here: http://www.rane.com/sslfix.html It looks, that you need to use the vendor-driver, and Windows Kernel Drivers do not work in wine. "winedump dump -j import SeratoUsb.sys" ntoskrnl.exe hal.dll wmilib.sys usbd.sys -- By by ... Detlef

May 4, 2007

Re: USB device support in wine

by Kuba Ober

> There is no standard user-mode interface for accessing USB hardware - > there is no equivalent of Linux's libusb on Windows But there is, just that most vendors don't use it. > (there is > apparently some user-space USB stuff in mingw's headers, but I > couldn't find any official docs on it, and it's not enough to write a > user-space driver because there is no bulk/interrupt/isochronous pipe > support, so I doubt anybody actually uses it). There is only > kernel-mode interfaces for talking to USB - and different kernel mode > drivers will export different user-mode interfaces (if any). > > So user-space software uses a kernel-mode driver. If that driver is > documented, like USBSCAN.SYS and USBPRINT.SYS, its interface can be > done in wine, and wine can be connected to USB in a number of ways > (which I'll discuss later). If that driver is undocumented, either you > have to document it by reverse-engineering (very hard) and continue > with the first way, or (the second way:) make wine's not-yet-existing > NTOSKRNL.EXE load that driver, *and* provide NTOSKRNL.EXE with all the > USB interfaces that Windows has. > > CONNECTING WINE TO USB: A HOW-TO GUIDE > > There is 4 ways to do it: > > 1. Make a kernel module in your OS (eg. a Linux kernel module) that > exports the same interface that the software expects and works the > same way as the Windows driver. Using USBSCAN.SYS as an example, > reading does a USB bulk read, writing does a USB bulk write, and 13 or > so i/o control codes do various other things, among them USB control > and interrupt tranfers. Change kernel32's CreateFileW() to open the > /dev device node used by the kernel module and send it to the wine > server using wine_server_fd_to_handle(), then reading and writing will > go to your kernel module, where you can implement them by doing USB > reads and writes. Change ntdll's file.c's NtDeviceIoControlFile to > capture i/o control codes used by your device, call > wine_server_handle_to_fd(), and do an ioctl() on that fd to send that > i/o control call to the kernel module, which then reacts > appropriately. This way has been tested by me, it works and it's fast, > but it's non-portable (eg. Linux-only, and Linux's USB interface keep > changing so an out-of-tree module will only work on some versions, the > usual problems...), difficult (kernel-mode code is hard to write), and > generally a royal PITA. > > 2. Like (1) but use a framework like FUSD (the xiph.org version works > on 2.6 kernels) to write the driver in user-space and then do USB I/O > using libusb. I'm currently testing this approach, I suspect it's slow > (how significantly remains to be seen), but at least it's more > portable between Linux versions and easier to write and maintain. > > 3. Integrate your device into wine directly the way eg. serial ports > have been done. This is hard, and requires introducing a new FD_TYPE, > changing ntdll's file.c's NtReadFile, NtWriteFile, and > NtDeviceIoControlFile (and asynchronous versions of those) to use > special behavior for that FD_TYPE, and managing global device state > (eg. i/o timeouts) in wineserver (look at server/serial.c). With a lot > of time, and some changes to both wine and libusb, you could get it to > work properly. This should IMO only be done for generally useful > drivers, not drivers for just 1 type of device. > > 4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to > NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably > through libusb), and modify ntdll to forward the appropriate reads, > writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file > can handle them. This is the only way that works with .SYS files > out-of-the-box, the others all require a rewrite of the .SYS driver's > functionality. Architecturally, this is the best way, you wouldn't > need to change any code in wine to add a new driver. > > Way 4 is probably the best and I hope it works at some stage, but it's > still a long way off seeing as how NTOSKRNL.EXE itself still isn't in > wine. > > > In the mean time, looks like I have some reading to do regarding USB > > spec, dbus and hal :-) > > There is only 1 or 2 chapters you need from the USB spec. DBus is just > an RPC framework, and HAL just lists devices and their properties, so > they won't help much. > > > Thanks for the help so far. > > > > Regards, > > Jono > > Damjan

May 4, 2007

Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS & incorrect GetLastError() codes fix

by Kirill K. Smirnov

> + > +/* adds glyphs to the string */ > +static inline void add_glyphs( WCHAR *str, unsigned int length ) > +{ > + unsigned int i; > + for (i=0; i!=length; i++) { > + if (str[i]<0x20) str[i]=glyph_xlat[str[i]]; > + } > +} > Page http://blogs.msdn.com/michkap/archive/2005/02/26/381020.aspx claims that symbol 0x7F should be converted too, but I did not check it. -- Kirill

May 4, 2007

Re: Testing and VarBstrFromDate (was Re: OLE2A)

by Michael Stefaniuc

Bill Medland wrote: > On Thu, 2007-03-05 at 07:29 -0700, Bill Medland wrote: > >>On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote: >> >>>On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote: >>> >>>>Does anyone know where a call to OLE2A is going to enter wine? >>>>Presumably OLE2A returning null means that the thread ran out of stack >>>>space? >>> >>>What is OLE2A? I do not see it mentioned anyewhere in the Wine source. >>> >>>Any more debugging output? >>> >>>Ciao, Marcus >> >>Hi Marcus, thanks for taking interest. >> >>A little late now, I think. The problem is not where I thought it was. >> >>OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, >>allocating memory on the stack and calling one of the wide-to-narrow >>conversions. >> >>Our program was behaving quite strangely, throwing an exception from >>some code that should not throw an exception. >> >>I traced it down to some code that did an OLE2A on a BSTR, called strlen >>on the return and then passed the same narrow string to a function. >>The problem occurred when the OLE2A returned a null pointer. Due to an >>oversight I thought the BSTR was non-null and assumed that somehow the >>underlying alloca must be returning null (i.e. was detecting out-of- >>stack-space). >> >>Now I discover that the BSTR itself was also NULL so that makes sense. >> >>I presume what happens is all that magic that traps the segment >>violation on strlen(0) didn't quite handle whatever optimised code was >>being generated for our case. >> >>However what I am also investigating is where the original NULL BSTR >>came from; possibly a defect in VariantChangeTypeEx. >> > > > Actually VariantChangeType was returning E_INVALIDPARAM and a VT_EMPTY > and the caller wasn't checking the result. > > However I think VariantChangeType was wrong in this case. > > >>Bill >> >> >> > > > So. > > 1. Am I misunderstanding something about the tests these days? > > (I am about to add two edge tests on SystemTimeToFileTime in time.c and > GetDateFormatW in locale.c) > > I go into dlls/kernel32/tests and make tests and it fails (change.c, > locale.c) Did you try to run make test a second time? Sometimes that makes it go further. > Should that disconcert me? Yes and no. The theory says that the tests should run on everybodies computer out of the box. The practice disagrees with this and afair only on Alexandre's computer all tests succeed. We should fix that and from time to time somebody tries to do it but it's no sexy work so that effort dies pretty soon. What i do is to run the tests on an origin Wine checkout and then on my modified tree and see if i get any additional failures/successes. > 2. How to fix the VarBstrFromDate? > > VarBstrFromDate(-657434.0 (DATE_MIN), 0x409, 0x80000000, wherever) > fails because VariantTimeToSystemTime successfully converts that to > 1/1/100 but then VarBstrFromDate tries to format that using > GetDateFormat, which is not feasible because the SystemTime is out of > range. > > Is there an existing low level routine that can handle the conversion > for such a small date Add a test for the VarBstrFromDate(-657434.0 ... call and see how Windows handles that. When you know the outcome you'll know how to fix it. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

May 4, 2007

Re: [05/10] d3d: Fix the surface locking rectangle validation

by Stefan Dösinger

Am Donnerstag 03 Mai 2007 20:58 schrieb H. Verbeet: > Validation on the rectangle passed to LockRect/Lock is inconsistent > across ddraw/d3d8/d3d9. D3d9 doesn't do any validation at all, d3d8 > doesn't allow empty, flipped, mirrored, or out of bounds rectangles, > while ddraw does allow empty rectangles, but not flipped, mirrored or > out of bounds ones. Tests for this are in the next few patches in this > set. You have to take care for IDirectDrawSurface::Blt and BltFast too, because parts of the Blt rectangle checks were done by Lock()

May 4, 2007

Re: USB device support in wine

by Damjan Jovanovic

On 5/4/07, Jon Burgess <jkburges(a)gmail.com> wrote: > > > > I have found some talk of implementing USB device support in wine in > this > > > list some time ago (2005), but as far as I know, nothing ever came of > it. > > > > > > I would perhaps be interested in getting this going again, as I have an > > > application (Serato Scratch Live: > > > http://www.rane.com/scratch.html) for which the > software > > > appears to run ok under wine (not that I am able to test much of its > > > functionality on the other hand), but is utterly useless without support > for > > > its associated USB hardware device. > > > > > > Any ideas, or anyone else who would be interested in helping me? > > > > Does the software come with a .SYS file? > > yes: the is a directory .../Serato/Drivers/ containing "MP4Usb.sys" and > "MP4Usb.inf", although I seem to remember reading somewhere that the MP4 > driver is for another Serato product (not Scratch live). It probably doesn't refer to the MP4 music format. > > That website doesn't much, please post lsusb -v output. > Bus 004 Device 002: ID 13e5:0001 > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol This there is no "standard" driver for your USB device (like for example there is just 1 driver for all USB flash disks, because they're all in the same device class). You have the use the vendor-supplied .SYS file. Will it work on wine right now? Not even remotely. Will it ever? Read on... There is no standard user-mode interface for accessing USB hardware - there is no equivalent of Linux's libusb on Windows (there is apparently some user-space USB stuff in mingw's headers, but I couldn't find any official docs on it, and it's not enough to write a user-space driver because there is no bulk/interrupt/isochronous pipe support, so I doubt anybody actually uses it). There is only kernel-mode interfaces for talking to USB - and different kernel mode drivers will export different user-mode interfaces (if any). So user-space software uses a kernel-mode driver. If that driver is documented, like USBSCAN.SYS and USBPRINT.SYS, its interface can be done in wine, and wine can be connected to USB in a number of ways (which I'll discuss later). If that driver is undocumented, either you have to document it by reverse-engineering (very hard) and continue with the first way, or (the second way:) make wine's not-yet-existing NTOSKRNL.EXE load that driver, *and* provide NTOSKRNL.EXE with all the USB interfaces that Windows has. CONNECTING WINE TO USB: A HOW-TO GUIDE There is 4 ways to do it: 1. Make a kernel module in your OS (eg. a Linux kernel module) that exports the same interface that the software expects and works the same way as the Windows driver. Using USBSCAN.SYS as an example, reading does a USB bulk read, writing does a USB bulk write, and 13 or so i/o control codes do various other things, among them USB control and interrupt tranfers. Change kernel32's CreateFileW() to open the /dev device node used by the kernel module and send it to the wine server using wine_server_fd_to_handle(), then reading and writing will go to your kernel module, where you can implement them by doing USB reads and writes. Change ntdll's file.c's NtDeviceIoControlFile to capture i/o control codes used by your device, call wine_server_handle_to_fd(), and do an ioctl() on that fd to send that i/o control call to the kernel module, which then reacts appropriately. This way has been tested by me, it works and it's fast, but it's non-portable (eg. Linux-only, and Linux's USB interface keep changing so an out-of-tree module will only work on some versions, the usual problems...), difficult (kernel-mode code is hard to write), and generally a royal PITA. 2. Like (1) but use a framework like FUSD (the xiph.org version works on 2.6 kernels) to write the driver in user-space and then do USB I/O using libusb. I'm currently testing this approach, I suspect it's slow (how significantly remains to be seen), but at least it's more portable between Linux versions and easier to write and maintain. 3. Integrate your device into wine directly the way eg. serial ports have been done. This is hard, and requires introducing a new FD_TYPE, changing ntdll's file.c's NtReadFile, NtWriteFile, and NtDeviceIoControlFile (and asynchronous versions of those) to use special behavior for that FD_TYPE, and managing global device state (eg. i/o timeouts) in wineserver (look at server/serial.c). With a lot of time, and some changes to both wine and libusb, you could get it to work properly. This should IMO only be done for generally useful drivers, not drivers for just 1 type of device. 4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably through libusb), and modify ntdll to forward the appropriate reads, writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file can handle them. This is the only way that works with .SYS files out-of-the-box, the others all require a rewrite of the .SYS driver's functionality. Architecturally, this is the best way, you wouldn't need to change any code in wine to add a new driver. Way 4 is probably the best and I hope it works at some stage, but it's still a long way off seeing as how NTOSKRNL.EXE itself still isn't in wine. > In the mean time, looks like I have some reading to do regarding USB spec, > dbus and hal :-) There is only 1 or 2 chapters you need from the USB spec. DBus is just an RPC framework, and HAL just lists devices and their properties, so they won't help much. > Thanks for the help so far. > > Regards, > Jono > Damjan

May 4, 2007

Re: [4/5] WineD3D: Implement vertex blending using GL_ARB_vertex_blend

by Stefan Dösinger

Am Donnerstag 03 Mai 2007 20:12 schrieb H. Verbeet: > Actually, I only thought about this just now, but you should also call > glDisableClientState(GL_WEIGHT_ARRAY); in unloadVertexData(). Indeed, I'll send a patch

May 4, 2007

kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS & incorrect GetLastError() codes fix

by Kirill K. Smirnov

+/* 0x00..0x1f chars glyph map */ +static const WCHAR glyph_xlat[32] = { + 0x0000, 0x263A, 0x263B, 0x2665, 0x2666, 0x2663, 0x2662, 0x2219, + 0x25D8, 0x25CB, 0x25D9, 0x2642, 0x2640, 0x266A, 0x266B, 0x263C, + 0x25BA, 0x25C4, 0x2195, 0x203C, 0x00B6, 0x00A7, 0x25AC, 0x21A8, + 0x2191, 0x2193, 0x2192, 0x2190, 0x221F, 0x2194, 0x25B2, 0x25BC +}; + +/* adds glyphs to the string */ +static inline void add_glyphs( WCHAR *str, unsigned int length ) +{ + unsigned int i; + for (i=0; i!=length; i++) { + if (str[i]<0x20) str[i]=glyph_xlat[str[i]]; + } +} I propose to make this routine extern, because it is the simpliest way to make console renderer (I mean user backend of wineconsole) display the characters below 0x20 correct. The test: #include <windows.h> int main(void) { DWORD d; char str[32]; int i; GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &d); d &= ~ENABLE_PROCESSED_OUTPUT; SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), d); for (i = 0; i < 32; i++) str[i] = i; WriteConsoleA(GetStdHandle(STD_OUTPUT_HANDLE), str, 32, &d, 0); d |= ENABLE_PROCESSED_OUTPUT; SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), d); return 0; } Under wine we get strange symbols, under windows we get correct glyphs. If we perform the same character conversion in wineconsole/user.c just before actual text output, we get almost the same result that Windows does. The only difference is handling \0 symbol. -- Kirill

May 4, 2007

Re: USB device support in wine

by Jon Burgess

> > > I have found some talk of implementing USB device support in wine in > this > > list some time ago (2005), but as far as I know, nothing ever came of > it. > > > > I would perhaps be interested in getting this going again, as I have an > > application (Serato Scratch Live: > > http://www.rane.com/scratch.html) for which the software > > appears to run ok under wine (not that I am able to test much of its > > functionality on the other hand), but is utterly useless without support > for > > its associated USB hardware device. > > > > Any ideas, or anyone else who would be interested in helping me? > > Does the software come with a .SYS file? yes: the is a directory .../Serato/Drivers/ containing "MP4Usb.sys" and " MP4Usb.inf", although I seem to remember reading somewhere that the MP4 driver is for another Serato product (not Scratch live). That website doesn't much, please post lsusb -v output. Bus 005 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic ehci_hcd iProduct 2 EHCI Host Controller iSerial 1 0000:00:1d.7 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 11 bDescriptorType 41 nNbrPorts 8 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 0x00 PortPwrCtrlMask 0xff 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Port 3: 0000.0100 power Port 4: 0000.0100 power Port 5: 0000.0100 power Port 6: 0000.0100 power Port 7: 0000.0100 power Port 8: 0000.0000 Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 001 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 002 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 004 Device 002: ID 13e5:0001 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 32 idVendor 0x13e5 idProduct 0x0001 bcdDevice 1.00 iManufacturer 1 Serato iProduct 2 Serato Scratch LIVE(c)2004 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 497 bNumInterfaces 9 bConfigurationValue 1 iConfiguration 13 USB Powered bmAttributes 0x80 (Bus Powered) MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 15 Line 1 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 7 LineOut1Idle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 9 LineOut1 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00b8 1x 184 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 3 LineIn1Idle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 5 LineIn1 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00b8 1x 184 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 16 Line 2 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 8 LineOut2Idle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 10 LineOut2 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00b8 1x 184 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 4 LineIn2Idle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 6 LineIn2 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00b8 1x 184 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 17 Mic Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 7 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 11 MicIdle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 7 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 12 Mic Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0090 1x 144 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 8 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 4 Device Status: 0x0000 (Bus Powered) Bus 004 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0103 power enable connect Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 003 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled And here is the relevant excerpt from my /proc/bus/usb/devices file (not sure if this gives anything extra than lsusb -v above though). T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=32 #Cfgs= 1 P: Vendor=13e5 ProdID=0001 Rev= 1.00 S: Manufacturer=Serato S: Product=Serato Scratch LIVE(c)2004 C:* #Ifs= 9 Cfg#= 1 Atr=80 MxPwr=300mA I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=01 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=01(O) Atr=09(Isoc) MxPS= 184 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 2 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=82(I) Atr=09(Isoc) MxPS= 184 Ivl=1ms I: If#= 3 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=01 Prot=00 Driver=(none) I: If#= 4 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 4 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=04(O) Atr=09(Isoc) MxPS= 184 Ivl=1ms I: If#= 5 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 5 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=84(I) Atr=09(Isoc) MxPS= 184 Ivl=1ms I: If#= 6 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=01 Prot=00 Driver=(none) I: If#= 7 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 7 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=85(I) Atr=09(Isoc) MxPS= 144 Ivl=1ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=4ms E: Ad=03(O) Atr=03(Int.) MxPS= 64 Ivl=4ms In the mean time, looks like I have some reading to do regarding USB spec, dbus and hal :-) Thanks for the help so far. Regards, Jono

May 4, 2007

Re: Unsecured API functions

by Marcus Meissner

On Thu, May 03, 2007 at 04:58:58PM -0500, Tom Spear wrote: > On 5/3/07, Marcus Meissner <marcus(a)jet.franken.de> wrote: > >wine is not using gets() at all, insofar there is no risk from it. > > That much I knew, however we do use strcpy (especially in msi), and > that is another one that has been deprecated ("banned").. > > See http://msdn2.microsoft.com/en-us/library/bb288454.aspx for the > complete list.. > > >It would be quite hard to convert gets -> gets_s by magic ;) > hmm, I thought so, and re-reading the page, it appears that it is > actually more of a proposal, than a list of api's that have actually > already been deprecated, however if msdn has an article from the sdl > that pushes for the deprecation of non-strsafe functions, I think we > should take that seriously, and at least investigate the difficulty > (I'm not pushing for it to be replaced anywhere in the code right now, > because we are already spread too thin). Newer gcc have checking for strcpy() overflows, and I have local patches for buffer overflow checking for some of our other string functions. Meaning ... I am watching at least the Wine Internals ;) Ciao, Marcus

May 4, 2007

Re: Unsecured API functions

by Stefan Dösinger

Am Donnerstag 03 Mai 2007 23:58 schrieb Tom Spear: > On 5/3/07, Marcus Meissner <marcus(a)jet.franken.de> wrote: > > wine is not using gets() at all, insofar there is no risk from it. > > That much I knew, however we do use strcpy (especially in msi), and > that is another one that has been deprecated ("banned").. Afair some time ago part of the code was using strncpy which has a destination size count and is sometimes considered safe because of that. The strncpy calls were removed some time ago. Not sure why, but I think thats because strncpy has tricky cavecats too, like not necessarily terminating the string with '\0'. I don't know about the _s APIs, but I guess they're not fool prove either and look like a sort of embrace and extend to me. As for applications using the safe functions I think Frank is right and they are implemented in the visual studio specifc msvcrt dlls, thus wine doesn't have to implement them. My Visual Studio 6 doesn't know them.

May 4, 2007

Re: USB device support in wine

by Jon Burgess

> > I have found some talk of implementing USB device support in wine in > this > > list some time ago (2005), but as far as I know, nothing ever came of > it. > > > > I would perhaps be interested in getting this going again, as I have an > > application (Serato Scratch Live: > > http://www.rane.com/scratch.html) for which the software > > appears to run ok under wine (not that I am able to test much of its > > functionality on the other hand), but is utterly useless without support > for > > its associated USB hardware device. > > One thing is that you need to make sure that the hardware is detected > and usable by Linux prior to trying to implement support for it in > wine. If linux can't see it, then wine won't be able to, just like if > you dont have the drivers installed in windows, then you wont be able > to use it within the application on windows. Ok, thanks Tom. I will investigate that - "/var/log/syslog" and "/proc/bus/usb/devices" should give me some idea if the USB device is detected, right? I'll check when I get home, at work atm. Cheers, Jono

May 4, 2007

Re: USB device support in wine

by Damjan Jovanovic

On 5/4/07, Jon Burgess <jkburges(a)gmail.com> wrote: > Hi, > > I have found some talk of implementing USB device support in wine in this > list some time ago (2005), but as far as I know, nothing ever came of it. > > I would perhaps be interested in getting this going again, as I have an > application (Serato Scratch Live: > http://www.rane.com/scratch.html) for which the software > appears to run ok under wine (not that I am able to test much of its > functionality on the other hand), but is utterly useless without support for > its associated USB hardware device. > > Any ideas, or anyone else who would be interested in helping me? Does the software come with a .SYS file? That website doesn't much, please post lsusb -v output. > Regards, > Jono Damjan

May 4, 2007

Re: USB device support in wine

by Tom Spear

On 5/3/07, Jon Burgess <jkburges(a)gmail.com> wrote: > Hi, > > I have found some talk of implementing USB device support in wine in this > list some time ago (2005), but as far as I know, nothing ever came of it. > > I would perhaps be interested in getting this going again, as I have an > application (Serato Scratch Live: > http://www.rane.com/scratch.html) for which the software > appears to run ok under wine (not that I am able to test much of its > functionality on the other hand), but is utterly useless without support for > its associated USB hardware device. One thing is that you need to make sure that the hardware is detected and usable by Linux prior to trying to implement support for it in wine. If linux can't see it, then wine won't be able to, just like if you dont have the drivers installed in windows, then you wont be able to use it within the application on windows. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

May 4, 2007