September 2002 - Wine-Devel

Using winbind with Wine
by Martin Wilck Sept. 24, 2002

Sept. 24, 2002

Hello, There has been a discussion on wine-devel about using winbind for purposes like user authorization, retrieving user and group information, and more. It seemed reasonable to use PAM and NSS for the basic lookups and leave it to the sysadmin to configure these services to use winbind. Winbind offers some more functionality than that, though, such as SID lookups. Continuing along that line, it would be desirable to have a more generic interface than what winbindd currently offers - actually it would be nice to be able to access all RPC calls that samba supports through an interface like winbindd's. * Are there any plans by the Samba team to extend winbindd in this direction? * If no, would the Samba team accept patches from wine developers implementing such extensions to winbindd? * Does winbind support client requests (from the Unix side) where strings are in Unicode format, i.e. could wine pass Unicode strings from Windows applications to windbind directly? * If no, would it be possible to extend winbindd to support this without modifying the samba libraries? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

winebootup
by Raul Dias Sept. 24, 2002

Sept. 24, 2002

Hi, What happened to winebootup? >From documentation/packaging.sgml: <varlistentry><term><filename>winebootup</filename></term> <listitem> <para> Winelib app to be found in programs/. It'll be called by the winelauncher wine wrapper startup script for every first-time wine invocation. Its purpose is to process all Windows startup autorun mechanisms, such as wininit.ini, win.ini Load=/Run=, registry keys: RenameFiles/Run/RunOnce*/RunServices*, Startup folders. </para> </listitem> </varlistentry> and it not under wine's tree. Does it exist? (or ever did?) Is there something similar to handle RunOnce keys? I just want to avoid doing a duplicated work. []'s Raul Dias

2 1

Re: Correct and update executable types in PathIsExe
by Jeff Smith Sept. 23, 2002

Sept. 23, 2002

I was just going by what MSDN says. Screensavers (SCR) are just like regular executables with a standard (I believe) command-line arguement interface. I really know next to nothing about SCF files. BTW, my version of Windows (95-OSR-2.1) is so old, it doesn't even have .cmd -- Jeff Smith >From: Alexandre Julliard <julliard(a)winehq.com> >To: "Jeff Smith" <whydoubt(a)hotmail.com> >CC: wine-devel(a)winehq.com >Subject: Re: Correct and update executable types in PathIsExe >Date: 23 Sep 2002 11:13:43 -0700 > >.pif is clearly right, but are you sure about .scr and .scf? My >version of Windows doesn't do that. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

1 0

Re: winapi update
by Alexandre Julliard Sept. 23, 2002

Sept. 23, 2002

Patrik Stridvall <ps(a)leissner.se> writes: > Fixed some issues found by winapi_check. I'd prefer that we didn't add standard headers on the dll separation hacks. We don't want to give the impression that these functions are legitimate exports. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: export {Start,End}GraphicsExposures from x11drv
by Alexandre Julliard Sept. 23, 2002

Sept. 23, 2002

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Fundamentally, the main purpose of a USER driver is to deal > with windowing, and as such, it needs to be able to compute > invalidated areas. It thus makes sense to for it to export > functions that let you query this information. > > The start/end interface used by x11drv makes sense, and it > looks sane enough to be exported. I disagree. Graphics exposures are a very X11 specific concept, they don't belong in the generic driver interface. This kind of change leads to the approach that we used before: do everything in USER and add a few strategically placed calls to x11drv where we really need it. That's the wrong approach, because it cannot be adapted to other drivers except by adding more and more driver calls all over USER. The new approach is to put the driver in charge as much as possible; this means a lot more work is done inside the driver functions, which in turn gives a lot more flexibility. Of course reconciling that with dll separation is not always trivial, but that's part of the fun... -- Alexandre Julliard julliard(a)winehq.com

2 9

Re: Correct and update executable types in PathIsExe
by Alexandre Julliard Sept. 23, 2002

Sept. 23, 2002

"Jeff Smith" <whydoubt(a)hotmail.com> writes: > Looking at PathIsExe, I thought PID was probably supposed to be PIF > (Program Information File). I checked MSDN, and found this was the > case. I also found two more types that need to be recognized: SCR > (SCReensaver) and SCF (Shell Command File?). .pif is clearly right, but are you sure about .scr and .scf? My version of Windows doesn't do that. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Correct and update executable types in PathIsExe
by Rolf Kalbermatter Sept. 23, 2002

Sept. 23, 2002

>Jeff Smith" <whydoubt(a)hotmail.com> writes: > >> Looking at PathIsExe, I thought PID was probably supposed to be PIF >> (Program Information File). I checked MSDN, and found this was the >> case. I also found two more types that need to be recognized: SCR >> (SCReensaver) and SCF (Shell Command File?). > >.pif is clearly right, but are you sure about .scr and .scf? My >version of Windows doesn't do that. It doesn't do it always. I had it once and disabled it immediately since I use an application with its own .scf file types. When enabled it captors the scf files directly on shell level and it wasn't possible to select scf files in the file dialog anymore!!! They are really text files in the way of Ini files. It may be possible that it comes with certain versions of Internet Explorer or Active Desktop or whatever. The scf extension when enabled is linked to SHCmdFile which starts explorer.exe without command arguments and then probably passes a DDE execute command to App: Folders, Topic: AppProperties with the command [ShellFile("%1","%1",%S)]. It is therefore not a Windows executable but really a shell extension feature. SCR files really are special exes. They are usually started by the screen saver control panel or system and not by a user double click. Windows adds links to the HKR keys to execute them as executable but again this happens on the shell level and not in the kernel. The file without any arguments started should display the configuration dialog if any. For the Test case the shell calls the file with argument /S. Installation is done by calling "rundll32.exe desk.cpl,InstallScreenSaver %l". I would not recommend trying to enable scf files at all in Wine. They are certainly no executables. I have no idea how the Wine pholosophy is in terms of enabling and supporting Windows shell features in Wine itself. It seems not useful to do that other than in the internal Wine browser/explorer eventually with help of Shell32. I would believe that Windows makes those types only indirectly executable through their registry entry and the shell which can interprete and resolve them. Rolf Kalbermatter

1 0

Name Mangling in WineLib
by steve.lustbader＠philips.com Sept. 23, 2002

Sept. 23, 2002

I'm building a WineLib dll in C++ that gets called by a Windows app run by wine. Is there a way to specify how exported function and class names get mangled when compiling with winelib? The Windows app expects MSVC mangled names, so it can't find the exported symbols in my dll, since the names are mangled differently. I'd like to be able to make my dll export the MSVC style names, instead of g++ names. I think spec files used to provide similar functionality, but not any more... -Steve

1 0

PE support in MZ_Exec() /winedos/module.c
by Chris Morgan Sept. 23, 2002

Sept. 23, 2002

I have a .com application that is calling out to dos int21 4Bh to load and execute a program. MZ_Exec assumes this program is always going to be a dos executable and the application fails to run and complains that it is a pe executable. So I've started to try and add support for correctly handling pe executables. So far I have a patch like below but I'm thinking that a lot more needs to be done in order to fulfill the dos requirements of this function and kind of wanted some opinions on this. This compiles but I haven't tested it since the program is at work, just wanted to get some feedback. Thanks, Chris Index: dlls/winedos/module.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.21 diff -u -r1.21 module.c --- dlls/winedos/module.c 30 Aug 2002 00:03:25 -0000 1.21 +++ dlls/winedos/module.c 22 Sep 2002 03:28:00 -0000 @@ -39,6 +39,7 @@ #endif #include "windef.h" #include "wine/winbase16.h" +#include "wine/winbase.h" #include "wingdi.h" #include "winuser.h" #include "winerror.h" @@ -342,16 +343,29 @@ */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { + enum binary_type binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + /* this may only be called from existing DOS processes * (i.e. one DOS app spawning another) */ - /* FIXME: do we want to check binary type first, to check - * whether it's a NE/PE executable? */ HANDLE hFile = CreateFileA( filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); BOOL ret = FALSE; + + binType = MODULE_GetBinaryType(hFile); + if (hFile == INVALID_HANDLE_VALUE) return FALSE; switch (func) { case 0: /* load and execute */ + if(binType == BINARY_PE_EXE) + { + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, filename, NULL, NULL, FALSE, + 0, NULL, NULL, &st, &pe); + } case 1: /* load but don't execute */ { /* save current process's return SS:SP now */

4 3

Standard load address for a Win32 program (0x00400000) not available
by Per Wigren Sept. 23, 2002

Sept. 23, 2002

Hi! I'm trying to run Streambox VCR, but I get this error: err:win32:do_relocations Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load 'F:\x\vcr.exe' as Win32 binary I DO have some security-patches in the kernel.. If that is the problem, what patches should I disable? Regards Per Wigren

2 2