- Wine-Devel - list.winehq.org

Re: SMB filesystem
by Dan Kegel June 3, 2002

June 3, 2002

Jean-Eric Cuendet wrote: > > > I'm thinking of implementing an smb filesystem, the way AFS implement > > > the AFS client fs kernel driver. > > > - Mount the smb filesystem on /smb (done at boot time) > > > - Every user has list dir access on /smb > > > - There, you see each workgroup/domain available on the network > > > - Then in each domain, a list of machines > > > - Then in each machine, a list of shares > > > - Then a list of files/dirs > > > Access will be granted using the SMB token (like a kerberos ticket) > > > issued by the primary domain controller. > > > It's the way the windows explorer works. It's cool and useful. > > > > Dan Kegel wrote: > > I've been hoping somebody would take this on. > > Why did you hope someone took this one? Do you think it's REALLY needed > or is there non-solvable problems? I'm interested in the Wine project, in particular, the kernel module being developed to speed up execution of win32 programs. It would really benefit from what you're proposing. (Wine is currently starting to do its own SMB client stuff, probably using the same shared library you're proposing to use, but not in a way that would be usable by the wine kernel module, I think. Wine could use your enhanced smbfs, if present, to allow all file operations to be handled by the wine kernel module.) > > Question: how will you carry the SMB token around? > > Let's imagine somebody starts a script that runs two programs > > that access SMB shares, and that they're initially not logged in at > > all. > > If this were Windows, it would prompt them once for their username > > and password, and then allow access from then on. ... > > For The user/pwd problem, you are right, user should be prompted for a > password. This could be achieve in the following way: > - If no token available: logged in anonymous or Guest > - The application could ask the daemon if a token is available, then > prompt the user for it before accessing the files. > - Make a generic callback way to call an arbitrary process > - When no token available, return a "NO LOGIN" message, so the > application should ask the user/password, create the token, or failed. > > I think that 1 or 4 is the best way to do it. I favor #4, it's the simplest. When the time comes that somebody wants closer emulation of windows behavior, something fancier could be done. > For the token [itself], it could be a file on the disk: > /tmp/user.smb.token, like with kerberos If that's how kerberos does it, that's probably fine. (In fact, in the future, won't you just use kerberos for a lot of windows networks?) But it might be awkward to access from inside the kernel, so I can imagine you might want to store it inside your smbfs kernel module instead. > What about putting that in a ENV VAR? Nope, environment variables are not global enough. Some posters have proposed using autofs to do the mounting. That's a good idea if it saves work and lets you have the per-user semantics you want. So all you need to do is implement an smbfs that uses the user's token to validate each open/rm/mv, and you're done. (Modulo somebody hooking an smb browser into an ldap server, but that may already have been done.) - Dan

1 0

Re: docu patch
by Alexandre Julliard June 3, 2002

June 3, 2002

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

2 3

problem : win16 stack selector freed twice
by Christian Costa June 3, 2002

June 3, 2002

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

2 1

Win16 Support again
by Steven Edwards June 3, 2002

June 3, 2002

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

2 4

Patch - Fix building oleaut32 on other platforms
by Steven Edwards June 3, 2002

June 3, 2002

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>

1 0

NT Native API File functions
by Mike McCormack June 2, 2002

June 2, 2002

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 June 2, 2002

June 2, 2002

[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 June 2, 2002

June 2, 2002

[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 June 2, 2002

June 2, 2002

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 June 2, 2002

June 2, 2002

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