June 2002 - Wine-Devel - list.winehq.org

Re: docu patch

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.com> wrote: > > Apparently it's caused by a bug somewhere, but if you will replace > > c:\windows by c:\Windows (note an uppercase 'W') Wine will not be > > able find the Windows directory. > > It should work just fine, unless you have configured your C drive as > type 'unix' which is probably not a good idea. Weird. It works now. -- Dmitry.

June 3, 2002

Re: problem : win16 stack selector freed twice

by Uwe Bonnes

>>>>> "Christian" == Christian Costa <titan.costa(a)wanadoo.fr> writes: Christian> Hi everybody, I encountered the following problem that Christian> completely broke MapLS. I investigated a little and here is Christian> what I've found : Christian> 1) a selector is allocated for the win16 stack in Christian> THREAD_InitStack 2) the selector is freed and the stack Christian> replaced by another (the DGROUP of the module) in Christian> NE_StartTask 3) MapLS is called, allocates the freed selector Christian> and keep it in a linked list 4) the selector is freed in Christian> SYSDEPS_ExitThread which believes it to be the selector of Christian> the initial task 5) the selector being freed is allocated Christian> (from where is not important) and the associated descriptor Christian> is modified 6) further call to MapLS (wich makes the function Christian> to use this selector) make wine to crash because the Christian> descriptor has been overwritten Christian> So 2) and 4) are conflicting but I think only 4) is wrong. Christian> 4) should free the selector of the new stack instead of the Christian> old one. Or should do nothing if the stack has been changed. Christian> Any idea? What about locking the alloceted handle? Refertencecounting should inhibit it from getting freed to early. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 3, 2002

linux kernel thoughts

by William Knop

I'm sure people have asked questions about integrating wine into the linux kernel. Probably got flamed by everybody, yeah? But that's not what I'm posting about. Not directly, anyway. =) I'm thinking of writing a kernel patch for PE executable support. Is there any reason why wine libraries should not be used in a similar manner as standard linux libraries? Granted wine is more than just it's libraries. Anyway, good idea, bad idea? And please keep the "if it ain't broke, don't fix it" comments to yourself. No progress is made with that mentality. Will _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

June 3, 2002

RE: Win16 Support again

by Steven Edwards

> Yes, most of the 32-bit code doesn't rely on the 16-bit APIs, > so you can start your work with truely separated 16/32 dlls. > But *there are* places where 32-bit code relyes on the 16-bit parts. > > And what is more important, is to decide how 32-bit and > 16-bit code should be separated. I vote for moving them to > separate files as Alexandre did it for dlls/user/wnd16.c and > dlls/user/wnd16.c for instance. I agree with moving the win16 support to its own files. Once that is done it will be easy to have a configure option to not build win16 support. If Alexandre will accept patches for it I will begin to do it. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

June 2, 2002

A problem with winmm and word

by Duane Clark

Word2000 seems to work good for me, except when I exit. It than invariably crashes in winmm, of all places: Backtrace: =>0 0x44056d9f (MULTIMEDIA_PlaySound+0x12f(pszSound=0x0, hmod=0x0, fdwSound=0x40, bUnicode=0x0) [mmsystem.c:639] in winmm.dll.so) (ebp=405b6bfc) 1 0x44056e37 (WINMM.DLL.PlaySound+0x13 in winmm.dll.so) (ebp=405b6c14) 2 0x30962b08 (MSO9.DLL._MsoFShowTooltip(a)8+0x123b in C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\MSO9.DLL) (ebp=405b6d78) 3 0x30a92306 (MSO9.DLL._MsoFGetCursorLocation(a)8+0x23f in C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\MSO9.DLL) (ebp=405b6d9c) 4 0x30170343 (winword.exe.EntryPoint+0x16d9a3 in C:\Program Files\Microsoft Office\Office\winword.exe) (ebp=307cd7d0) 5 0x00000012 (ebp=00000000) MULTIMEDIA_PlaySound() gets called three times. The first two times work ok, but on the third time, it is called with a NIL pszSound. This causes wps to never be set, causing the crash on line 639: wps->lpNext = iData->lpPlaySound; I added a simple test to return if wps is not set, and Word exits fine. But I have no idea whether that is the right thing to do.

June 2, 2002

Re: docu patch

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Apparently it's caused by a bug somewhere, but if you will replace > c:\windows by c:\Windows (note an uppercase 'W') Wine will not be > able find the Windows directory. It should work just fine, unless you have configured your C drive as type 'unix' which is probably not a good idea. -- Alexandre Julliard julliard(a)winehq.com

June 2, 2002

Re: Win16 Support again

by Dmitry Timoshkov

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> wrote: > > It's much larger work than just #ifdef'ing the code. First of > > all, all 32-bit code should be rewritten to not rely on the > > 16-bit counterparts. > > Does that much of the Win32 code depend on Win16? > I thought they were mostly indepenant of each other in the WINE sources. Yes, most of the 32-bit code doesn't rely on the 16-bit APIs, so you can start your work with truely separated 16/32 dlls. But *there are* places where 32-bit code relyes on the 16-bit parts. And what is more important, is to decide how 32-bit and 16-bit code should be separated. I vote for moving them to separate files as Alexandre did it for dlls/user/wnd16.c and dlls/user/wnd16.c for instance. -- Dmitry.

June 2, 2002

Re: docu patch

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.com> wrote: > Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > > > [wine] > > +; Warning ! case sensitive directory names here ! > > "Windows" = "c:\\windows" > > "System" = "c:\\windows\\system" > > What makes you think they are case sensitive? Apparently it's caused by a bug somewhere, but if you will replace c:\windows by c:\Windows (note an uppercase 'W') Wine will not be able find the Windows directory. -- Dmitry.

June 2, 2002

Patch - Fix building oleaut32 on other platforms

by Steven Edwards

Changelog: Portablity fix Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson cvs diff -u typelib.c Index: typelib.c =================================================================== RCS file: /home/wine/wine/dlls/oleaut32/typelib.c,v retrieving revision 1.69 diff -u -r1.69 typelib.c --- typelib.c 31 May 2002 23:25:50 -0000 1.69 +++ typelib.c 3 Jun 2002 02:21:04 -0000 @@ -53,6 +53,7 @@ */ #include "config.h" +#include "wine/port.h" #include <stdlib.h> #include <string.h>

June 2, 2002

RE: Win16 Support again

by Steven Edwards

> It's much larger work than just #ifdef'ing the code. First of > all, all 32-bit code should be rewritten to not rely on the > 16-bit counterparts. Does that much of the Win32 code depend on Win16? I thought they were mostly indepenant of each other in the WINE sources. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

June 2, 2002

problem : win16 stack selector freed twice

by Christian Costa

Hi everybody, I encountered the following problem that completely broke MapLS. I investigated a little and here is what I've found : 1) a selector is allocated for the win16 stack in THREAD_InitStack 2) the selector is freed and the stack replaced by another (the DGROUP of the module) in NE_StartTask 3) MapLS is called, allocates the freed selector and keep it in a linked list 4) the selector is freed in SYSDEPS_ExitThread which believes it to be the selector of the initial task 5) the selector being freed is allocated (from where is not important) and the associated descriptor is modified 6) further call to MapLS (wich makes the function to use this selector) make wine to crash because the descriptor has been overwritten So 2) and 4) are conflicting but I think only 4) is wrong. 4) should free the selector of the new stack instead of the old one. Or should do nothing if the stack has been changed. Any idea? A+ Christian

June 2, 2002

NT Native API File functions

by Mike McCormack

Hi, I have a small dilema. I'd like to implement the functions below, and declare them in a header file somewhere, but they are not declared by Microsoft in any of their header files. (Checked the NT DDK, VC++ headers and Platform SDK.) So, should I: * go ahead and declare them like this * add an #ifdef DECLARE_NATIVEAPI / #endif around the functions * put them in a private header file in (say dlls/ntdll/native.h ) or just leave them out all together? Anyway, feel free to apply this if it's the right way to do it... Mike License: LGPL (as always) ChangeLog: * declare NtCreateFile() NtOpenFile() and NtReadFile() Index: include/ntddk.h =================================================================== RCS file: /home/wine/wine/include/ntddk.h,v retrieving revision 1.44 diff -u -r1.44 ntddk.h --- include/ntddk.h 31 May 2002 23:06:48 -0000 1.44 +++ include/ntddk.h 2 Jun 2002 13:51:35 -0000 @@ -1027,6 +1027,31 @@ BOOL WINAPI RtlTryEnterCriticalSection( RTL_CRITICAL_SECTION *crit ); NTSTATUS WINAPI RtlLeaveCriticalSection( RTL_CRITICAL_SECTION *crit ); +/* file functions */ + +/* flags for NtCreateFile and NtOpenFile */ +#define FILE_DIRECTORY_FLAG 0x00000001 +#define FILE_WRITE_THROUGH 0x00000002 +#define FILE_SEQUENTIAL_ONLY 0x00000004 +#define FILE_NO_INTERMEDIATE_BUFFERING 0x00000008 +#define FILE_SYNCHRONOUS_IO_ALERT 0x00000010 +#define FILE_SYNCHRONOUS_IO_NONALERT 0x00000020 +#define FILE_NON_DIRECTORY_FILE 0x00000040 +#define FILE_CREATE_TREE_CONNECTION 0x00000080 + +/* status for NtCreateFile or NtOpenFile */ +#define FILE_SUPERSEDED 0x00000000 +#define FILE_OPENED 0x00000001 +#define FILE_CREATED 0x00000002 +#define FILE_OVERWRITTEN 0x00000003 +#define FILE_EXISTS 0x00000004 +#define FILE_DOES_NOT_EXIST 0x00000005 + +NTSTATUS WINAPI NtCreateFile(PHANDLE, ACCESS_MASK, POBJECT_ATTRIBUTES, PIO_STATUS_BLOCK, PLARGE_INTEGER, ULONG, ULONG, ULONG, ULONG, PVOID, ULONG); +NTSTATUS WINAPI NtOpenFile(PHANDLE, ACCESS_MASK, POBJECT_ATTRIBUTES, PIO_STATUS_BLOCK, ULONG, ULONG); +NTSTATUS WINAPI NtReadFile(HANDLE, HANDLE, PIO_APC_ROUTINE, PVOID, PIO_STATUS_BLOCK, PVOID, ULONG, PLARGE_INTEGER, PULONG); + + /* string functions */ extern LPSTR _strlwr( LPSTR str ); extern LPSTR _strupr( LPSTR str );

June 2, 2002

Re: docu patch

by Alexandre Julliard

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > [wine] > +; Warning ! case sensitive directory names here ! > "Windows" = "c:\\windows" > "System" = "c:\\windows\\system" What makes you think they are case sensitive? -- Alexandre Julliard julliard(a)winehq.com

June 2, 2002

kernel fix for SB16 fullduplex system lockup

by Andreas Mohr

[wine-devel copy of my LKML mail] doh ! This time with patch... Hi all, when running a program on Wine, suddenly my 2.4.18 froze completely. This has been caused by the program submitting an odd number of output bytes to the soundcard in 16bit output mode, thus causing the sound driver to loop endlessly on the last remaining byte. When digging deeper, I found that this odd number of output bytes had been caused by the SoundBlaster 16 driver always returning one half of the output bytes that it could take (in the SNDCTL_DSP_GETOSPACE ioctl result), thus always cutting the remaining free buffer in half, thus hitting an odd number after some time (1988 bytes -> 994 -> 497). The SB16 driver is doing an internal 16bit -> 8bit conversion in case it's running in fullduplex mode, and it simply returned the remaining free bytes in the DMA buffer, which should have been twice that number due to the 16bit -> 8bit conversion in fullduplex mode. Also, it's doing 8bit -> 16bit conversion in the 8bit output case, which SNDCTL_DSP_GETOSPACE ioctl didn't account for either. In short: When using SB16 in fullduplex mode, the SNDCTL_DSP_GETOSPACE ioctl didn't account for the 16/8bit format conversions that the SB16 does in this case, thus leading to an odd-numbered input count freezing the box due to a second "odd remainder" endless loop bug. Thus this patch does: - add two flags DMA_CONV_16_8, DMA_CONV_8_16 to struct dma_buffparms to check for format conversion in dma_ioctl()/SNDCTL_DSP_GETOSPACE and thus fix SNDCTL_DSP_GETOSPACE result to account for format conversion - prevent endless looping (lockup) on single remaining byte by discarding odd remainders of odd output counts in case of 16bit format This WORKS (well, for me at least :-). My previous LKML mails about this problem were: 950 May 25 Andreas Mohr ( 80) SB16: 2.4.18 lockup on odd-numbered 16bit 951 May 26 Andreas Mohr ( 59) SNDCTL_DSP_GETOSPACE bug for SB16 (was: S I'm not in the least experienced with sound card programming, and I didn't get much LKML help on this issue, so please review and let me know the result, if possible. CC'd to Andrea, the original author of SB16 fullduplex support. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

June 2, 2002

kernel fix for SB16 fullduplex system lockup

by Andreas Mohr

[wine-devel copy of my LKML mail] Hi all, when running a program on Wine, suddenly my 2.4.18 froze completely. This has been caused by the program submitting an odd number of output bytes to the soundcard in 16bit output mode, thus causing the sound driver to loop endlessly on the last remaining byte. When digging deeper, I found that this odd number of output bytes had been caused by the SoundBlaster 16 driver always returning one half of the output bytes that it could take (in the SNDCTL_DSP_GETOSPACE ioctl result), thus always cutting the remaining free buffer in half, thus hitting an odd number after some time (1988 bytes -> 994 -> 497). The SB16 driver is doing an internal 16bit -> 8bit conversion in case it's running in fullduplex mode, and it simply returned the remaining free bytes in the DMA buffer, which should have been twice that number due to the 16bit -> 8bit conversion in fullduplex mode. Also, it's doing 8bit -> 16bit conversion in the 8bit output case, which SNDCTL_DSP_GETOSPACE ioctl didn't account for either. In short: When using SB16 in fullduplex mode, the SNDCTL_DSP_GETOSPACE ioctl didn't account for the 16/8bit format conversions that the SB16 does in this case, thus leading to an odd-numbered input count freezing the box due to a second "odd remainder" endless loop bug. Thus this patch does: - add two flags DMA_CONV_16_8, DMA_CONV_8_16 to struct dma_buffparms to check for format conversion in dma_ioctl()/SNDCTL_DSP_GETOSPACE and thus fix SNDCTL_DSP_GETOSPACE result to account for format conversion - prevent endless looping (lockup) on single remaining byte by discarding odd remainders of odd output counts in case of 16bit format This WORKS (well, for me at least :-). My previous LKML mails about this problem were: 950 May 25 Andreas Mohr ( 80) SB16: 2.4.18 lockup on odd-numbered 16bit 951 May 26 Andreas Mohr ( 59) SNDCTL_DSP_GETOSPACE bug for SB16 (was: S I'm not in the least experienced with sound card programming, and I didn't get much LKML help on this issue, so please review and let me know the result, if possible. CC'd to Andrea, the original author of SB16 fullduplex support. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

June 2, 2002

RE: Close X after one hour and half

by Robert Yaklin

The problem may be a memory leak in Wine. Try running top while your Wine application is running and keep an eye on the amount of memory Wine is using. If you are using the latest Wine from CVS you may notice that you application runs longer, thanks to a bug-fix by Andreas Mohr. Robert You Wrote: > Hello friends > > a run my applicationwith wine and xinit like: > > xinit wine myapp.exe -- :0 > > running very well, but after one hour and half this broken my X > session and back to text console... > > i not see a messagem that refer to this problem in the screen and > logs are equal > > I dont understand what happen with X to make... > > anybody help me..? > > > Marcelo

June 2, 2002

Re[2]: Keyboard layout detection not working??

by Nerijus Baliunas

On Sun, 02 Jun 2002 10:40:37 +0300 Shachar Shemesh <wine-devel(a)sun.consumer.org.il> wrote: > >Does it mean it should work if I change keyboard layout to non English > >and then launch Word? > > > > > What language are we talking about? If we are talking about a BiDi It's Lithuanian. > Office (Hebrew or Arabic), I am not sure how Word will display the > direction indicator. Like I told Hetz, I am pretty early in the process. > I'm currently at the Text output functions, and things like "Word" are a > bit in the future for me. > > I don't know how and if Word needs to know about non-BiDi languages. > > > > >>I'm afraid that my BiDi attempts are at a rather early stage. If you > >>want to follow them, or contribute (and the testing you are performing > >>certanly count as contribution), you can add youself as CC to bug #609 > >>(http://bugs.winehq.com/show_bug.cgi?id=609) > >> > > > >BTW, how to do that (add myself as CC)? > > follow the link, and add your email address under the "add CC:" field > (top right). Oh, it was veeery right in Konqueror, now I see. Regards, Nerijus

June 2, 2002

PATCH: DragQueryFileW (shellole.c; shell32)

by Sander van Leeuwen

Hi, There appears to be a little bug in DragQueryFileW. According to MSDN pFiles is the offset in bytes. Did somebody make a mistake or was the LPWSTR cast added on purpose? Sander Changelog: - Fixed wrong cast; MSDN says lpDropFileStruct->pFiles is offset in bytes (regardless of ascii/unicode) Author: Sander van Leeuwen (sandervl(a)xs4all.nl) --- shellole.co Sun Mar 17 11:20:10 2002 +++ shellole.c Sun Jun 2 13:15:54 2002 @@ -627,7 +627,7 @@ if(!lpDropFileStruct) goto end; - lpwDrop = (LPWSTR) lpDropFileStruct + lpDropFileStruct->pFiles; + lpwDrop = (LPWSTR) ((LPSTR)lpDropFileStruct + lpDropFileStruct->pFiles); i = 0; while (i++ < lFile)

June 2, 2002

Re: Keyboard layout detection not working??

by Shachar Shemesh

Nerijus Baliunas wrote: >On Sat, 01 Jun 2002 14:30:36 +0300 Shachar Shemesh <wine-devel(a)sun.consumer.org.il> wrote: > > > >>I believe the problems you are experiencing have nothing to do with the >>keyboard layout problem, but with the keyboard switching detection. >> >> > >Does it mean it should work if I change keyboard layout to non English >and then launch Word? > > What language are we talking about? If we are talking about a BiDi Office (Hebrew or Arabic), I am not sure how Word will display the direction indicator. Like I told Hetz, I am pretty early in the process. I'm currently at the Text output functions, and things like "Word" are a bit in the future for me. I don't know how and if Word needs to know about non-BiDi languages. > > >>I'm afraid that my BiDi attempts are at a rather early stage. If you >>want to follow them, or contribute (and the testing you are performing >>certanly count as contribution), you can add youself as CC to bug #609 >>(http://bugs.winehq.com/show_bug.cgi?id=609) >> >> > >BTW, how to do that (add myself as CC)? > >Regards, >Nerijus > > > > follow the link, and add your email address under the "add CC:" field (top right). Shachar p.s. If your language is Arabic, I need help from an Arabic speaker. I need to model the Windows BiDi algorythm (as opposed to the Unicode BiDi algorythm), so I need someone with Arabic experience to ask some questions.

June 2, 2002

Re: Win16 Support again

by Dmitry Timoshkov

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> wrote: > Ok I changed my mind, I want to disable it for now. What is going to be > the best way to go about doing it? We currently have the > -DNO_WINEWINSOCK should I just #ifndef the code out with -DNO_WIN16 ? It's much larger work than just #ifdef'ing the code. First of all, all 32-bit code should be rewritten to not rely on the 16-bit counterparts. -- Dmitry.

June 1, 2002

Win16 Support again

by Steven Edwards

Ok I changed my mind, I want to disable it for now. What is going to be the best way to go about doing it? We currently have the -DNO_WINEWINSOCK should I just #ifndef the code out with -DNO_WIN16 ? Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

June 1, 2002

Re: Shlwapi and user32 question

by Alexandre Julliard

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> writes: > The only thing keeping me from building shlwapi is that its import the > non-win32 call wvsnprintfA and wvsnprintfW from user32 to implement > wvnsprintfA and wvnsprintfW. I did a search of the wine source tree and > nothing else seems to depend on these functions being exported from > user32. Can they be moved somewhere else or removed? The problem is that the user32 wvsprintf depends on wvsnprintf. The only way is to duplicate the implementation I'm afraid. -- Alexandre Julliard julliard(a)winehq.com

June 1, 2002

Re: Possible minor bug in bin2res

by Alexandre Julliard

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> writes: > I have been working on a small project that I am going to be submitting > to the wine tree that used binary resources under windows and when I > went to convert the files with bin2res I get this error "rename: File > exists" It dumps the right wine resource information to the resouce-tmp > file but when it goes to unlink the tmp file is when the error happens > and the information must be manualy added to the rsrc.rc You most likely need to remove the destination file before the rename, Windows is too stupid to do it itself. -- Alexandre Julliard julliard(a)winehq.com

June 1, 2002

Shlwapi and user32 question

by Steven Edwards

Hola, The only thing keeping me from building shlwapi is that its import the non-win32 call wvsnprintfA and wvsnprintfW from user32 to implement wvnsprintfA and wvnsprintfW. I did a search of the wine source tree and nothing else seems to depend on these functions being exported from user32. Can they be moved somewhere else or removed? Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

June 1, 2002

Re[2]: Keyboard layout detection not working??

by Nerijus Baliunas

On Sat, 01 Jun 2002 14:30:36 +0300 Shachar Shemesh <wine-devel(a)sun.consumer.org.il> wrote: > I believe the problems you are experiencing have nothing to do with the > keyboard layout problem, but with the keyboard switching detection. Does it mean it should work if I change keyboard layout to non English and then launch Word? > I'm afraid that my BiDi attempts are at a rather early stage. If you > want to follow them, or contribute (and the testing you are performing > certanly count as contribution), you can add youself as CC to bug #609 > (http://bugs.winehq.com/show_bug.cgi?id=609) BTW, how to do that (add myself as CC)? Regards, Nerijus

June 1, 2002