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

NT Native API File functions
by Mike McCormack 02 Jun '02

02 Jun '02

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 );

1 0

kernel fix for SB16 fullduplex system lockup
by Andreas Mohr 02 Jun '02

02 Jun '02

[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

1 0

kernel fix for SB16 fullduplex system lockup
by Andreas Mohr 02 Jun '02

02 Jun '02

[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

1 0

RE: Close X after one hour and half
by Robert Yaklin 02 Jun '02

02 Jun '02

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

1 0

Keyboard layout detection not working??
by Shachar Shemesh 02 Jun '02

02 Jun '02

Hi all, I am using Debian SID with KDE. In KDE, I defined two keyboard layouts (US and IL). I tried to add Israeli keyboard detection using the attached patch (layout.diff). When trying to test that patch, however, I perform the following task: I type in the command as suggested in the docs (wine --debugmsg +key,+keyboard >& key.log). Attached are two run attempts. key.log is with the US keyboard selected, key2.log is with the Hebrew keyboard selected. Comparing the two outputs, several things become evident: 1. The Israeli keyboard is not detected. It fails to match even the non-Hebrew characters (such as the '/' instead of lower case 'q'). It's as if WINE did not notice that a non-English keymap was installed. On the other hand, there are some differences between the two runs. What's going on? 2. The dvorak keyboard has 0 mismatches???? I noticed that the code has some different virtual mapping of the keyboard. I am not aware that dvorak keyboards generate a different scan code mapping. Am I missing something here? 3. There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message. I understood that implementing an event trigered by X layout change is a difficult matter, but it is highly necessary for my BiDi support (many programs, including Office, know the current direction, and have visual representation when it changes. Not implementing this message may prove to be problematic in that respect). I currently don't have the capacity to go after this particular problem, but if it remains unsolved by the time it becomes crucial to me, I will. If anyone has any leads on solving this problem, please let me know. I have entered bug #735 on this issue. Many thanks for your input, Shachar Index: dlls/x11drv/keyboard.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/keyboard.c,v retrieving revision 1.1 diff -u -r1.1 keyboard.c --- dlls/x11drv/keyboard.c 30 Apr 2002 21:16:39 -0000 1.1 +++ dlls/x11drv/keyboard.c 28 May 2002 13:20:04 -0000 @@ -531,6 +531,15 @@ "zZ","xX","cC","vV","bB","nN","mM","öÖ","çÇ",".:" }; +/*** Israeli keyboard layout */ +static const char main_key_IL[MAIN_LEN][4] = +{ + "`~","1!","2@","3#","4$","5%","6^","7&","8*","9(","0)","-_","=+", + "/Q","'W","÷E","øR","àT","èY","åU","ïI","íO","ôP","[{","]}", + "ùA","ãS","âD","ëF","òG","éH","çJ","ìK","êL","ó:",",\"","\\|", + "æZ","ñX","áC","äV","ðB","îN","öM","ú<","õ>",".?" +}; + /*** VNC keyboard layout */ static const WORD main_key_scan_vnc[MAIN_LEN] = { @@ -600,6 +609,7 @@ {"Latin American keyboard layout", 28591, &main_key_LA, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Lithuanian (Baltic) keyboard layout", 28603, &main_key_LT_B, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Turkish keyboard layout", 28599, &main_key_TK, &main_key_scan_qwerty, &main_key_vkey_qwerty}, + {"Israeli keyboard layout", 28598, &main_key_IL, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"VNC keyboard layout", 28591, &main_key_vnc, &main_key_scan_vnc, &main_key_vkey_vnc}, {NULL, 0, NULL, NULL, NULL} /* sentinel */

4 14

PATCH: DragQueryFileW (shellole.c; shell32)
by Sander van Leeuwen 02 Jun '02

02 Jun '02

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)

1 0

Shlwapi and user32 question
by Steven Edwards 01 Jun '02

01 Jun '02

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

2 1

Possible minor bug in bin2res
by Steven Edwards 01 Jun '02

01 Jun '02

Hola, 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 I traced it down, made sure that all other tmp file acces works in bin2res and and I think the problem is on line 245 if (rename(tmpfile, g_lpstrInputFile) == -1) { perror("rename"); unlink(tmpfile); return 0; } return 1; I have followed the directions on www.winehq.com for creation of a rsrc.rc to dump the resource information so I don't think I'm doing anything wrong. Can someone check this on windows to make sure I'm not just on the crack rock again? Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

2 1

User (developer ?) friendly execution trace
by max 01 Jun '02

01 Jun '02

I find tracing a wine problem with wine --debugmsg for large programs unpractical. Usually you can know about exactly when a program hangs or behaves badly, but there's no way to activate/deactivate tracing after program start (afaik...) Being also a windoze (sigh) programmer, I find very useful some utilities like winspy that presents a window log in which you can start/stop tracing or logging of wine messages, system calls and so on, and activate/deactivate filters on the fly. This would allow spotting the bug when it arises instead of having tenths or hundreds of mbyte of logs. I could implement it as a filter taking input from wine, but I guess it'll slow downn much apps, having to parse wine output on the fly. Much better would be an internal implementation.... Some comments about ? Regards Max

3 2

DOS memory Question..... or How to increase base memory for DOS apps
by Christian Costa 01 Jun '02

01 Jun '02

Hi, Many DOS apps needs a lot of base memory even if EMS or XMS memory are used. The first 64K of memory being lock to catch null pointer, the DOS memory must start at 0x10000 as you can see in the code below (msdos/dosmem.c) : /*********************************************************************** * DOSMEM_InfoBlock * * Gets the DOS memory info block. */ static dosmem_info *DOSMEM_InfoBlock(void) { return (dosmem_info*)(DOSMEM_dosmem+0x10000); /* 64K */ } /*********************************************************************** * DOSMEM_InitMemory * * Initialises the DOS memory structures. */ static void DOSMEM_InitMemory(void) { /* Low 64Kb are reserved for DOS/BIOS so the useable area starts at * 1000:0000 and ends at 9FFF:FFEF. */ Changing this value to the end of the BIOS DATA area (0x500) does the job and things work as expected (at least for DOS apps). But I was told that this causes problems for others apps. Probably for Win16 ones that use DOS3CALL and not int21h via DPMI. If it's true, a solution could be to initialize DOS memory differently for pure DOS apps by modifying the DOSMEM_Init function. DOSMEM_Init is called at 3 different places : - process_attach in dlls/kernel/kernel_main.c - DOSVM_Init in dlls/winedos/dosvm.c - MZ_InitMemory in dlls/winedos.dosvm.c and acts differently the first and second calls. Since I don't know wine internals enough and the "flow of execution", I have no idea how to do it in a clean way that do not break everything. If someone can help me or give me hints? A+ Christian

3 3