February 2001 - Wine-Devel - list.winehq.org

AFM-Handling problem
by Joerg Mayer Feb. 12, 2001

Feb. 12, 2001

Moin, Marcus last patch to add default paths for afm files triggered a bug: Inside my font dirs, there is a directory that contains gzipped afm files. After I unzipped these files, wine started up again. Not nice. Ciao Jörg PS: This is the directory *after* decompression of the .afm.gz files: jmayer(a)alice:/usr/X11R6/lib/X11/fonts/Type1 > ls UTBI____.afm c0419bt_.afm c0632bt_.afm cour.afm cursor.pfa lcdxro.afm UTBI____.pfa c0419bt_.pfb c0632bt_.pfb cour.pfa encodings.dir lcdxro.pfa UTB_____.afm c0582bt_.afm c0633bt_.afm courb.afm fonts.dir lcdxrr.afm UTB_____.pfa c0582bt_.pfb c0633bt_.pfb courb.pfa fonts.scale lcdxrr.pfa UTI_____.afm c0583bt_.afm c0648bt_.afm courbi.afm lcdxmo.afm lcdxso.afm UTI_____.pfa c0583bt_.pfb c0648bt_.pfb courbi.pfa lcdxmo.pfa lcdxso.pfa UTRG____.afm c0611bt_.afm c0649bt_.afm couri.afm lcdxmr.afm lcdxsr.afm UTRG____.pfa c0611bt_.pfb c0649bt_.pfb couri.pfa lcdxmr.pfa lcdxsr.pfa jmayer(a)alice:/usr/X11R6/lib/X11/fonts/Type1 > -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

2 1

The Muncher project.
by Josh Walker Feb. 12, 2001

Feb. 12, 2001

I aplolgize for the spelling. I never was any good at english. The muncher project is the implmentation of wine into a very very unique distro of linux and used as a true windows clone. I know, it's not a good name for a project, but it's the best I could come up with after spinning around in a desk chair for five minutes. I also know that this isn't the first time anyone has come up with the idea either, but this is differnt. I have an implentation scheme. I came up with the idea while working on an mp3 player for my car (which also runs linux) There are two HDs in my car stereo. The first is a small 512M drive running linux with all the core compents to make xmms work. The second drive is the mp3 drive, an 8GB removable with FAT32 on it so I can swap it into a windows box too. The mall Linux drive does all the work. It struck me one day that wouldn't it be cool at have a real windows interface for wine. I mean, you can hack the system as much as you can, but when it comes to it, the explorer start bar and all of the activeX do-hickies like control panel and My computer are owned by microsoft. So I devised a plan to make Linux look, run, smell, feel, and act like windows. The goal is to fool my mom by swapping the OS and seeing if she notices. The system works muck like the mp3 player in my car. Two partitons, one is the linux "Macrokenrel" which does all the behind the scenes stuff and the a fat32 partition, which holds the windows files and that the user only sees. The Macrokenel will be a linux partition that has the ability to boot, starts the devices, and then run the neccary core files. The big ones are X, FVWM95, the gnome desktop (Just the desktop, no icons, or panels, no virtual displays, nothing crazy... yet), and wine. Using glade, I will write little replacements for the ActiveX compents that are missing, (My computer, Control panel, etc) GTK will handle the windows "theme" as far as widgets go and fvwm95 is small, sleek, and gives you the right window dressings and a start button. I have here a compiled list of what I plan to add. CORE: Main Kernel -> Linux 2.4.1, USB and harware support big plus/framebuffer for startup screen http://www.kernel.org/ Dos support -> DosEMU 1.0.1 with FreeDOS .98, depending on dos support under wine http://www.dosemu.org/ http://www.freedos.org/ Windows support -> Wine, the latest http://www.winehq.org/ Graphic Display -> Xfree86 4.0.2 more graphics cards, the better font server http://www.xfree86.org DirectX -> Transgameing Explorer(GUI) -> modded FVWM95/Gnome desktop combo ftp://mitac11.uia.ac.be/html-test/fvwm95.html http://www.gnome.org Explorer(filelister) -> gmc (was Midnight Commander, swallowed by Gnome) http://www.gnome.org Explorer(Browser) -> Mozilla (activeX compent, full browser) http://www.iol.ie/~locka/mozilla/mozilla.htm http://www.mozilla.org/ DO-HICKIES & THINGAMABOBS: These are small apps that are written in gtk (possably quick glide apps) that mimic the function of native windows apps. My Computer -> GTK do-hickie that looks like My Computer Launches gmc and the contol panel do-hiokie. System -> GTK do-hickie that will list devices that are valid in /dev in a windows format, intermixed with kernal modules and stuff from kudzu. Network Neighborhood -> LinNeighborhood/Samba http://www.bnro.de/~schmidjo/ Trash -> Gnome's trash Display Properties -> GTK do-hickie that edits xf86config, xscreensaver, and fvwmrc is a windows fimilar way Dial-up Networking -> working for an ISP, I know this thing foreward and backwards do-hickie that writes chat/pppd scripts, easy! Control Panel -> Ugh! Do what WinME does. Make it simple unless you want complex. Start with date/time, internet options, display, printers, and totaly ignore add/remove programs for now. Complex will have date/time, display, fonts, internet options keyboard, modems, mouse, network, passwords, printers regonal settings, scedualed tasks, system Date/Time -> simple GTK app internet options -> working for an ISP know this foreward amd backwards too edits chat/pppd scripts Printers -> Wrapper for redhat's printtool w/ tweaks add/remove programs -> not gonna touch this with a 10 foot pole. maybe later fonts -> links to the font dirs in X keyboard -> edits keyboard properties and Xkeyboard settings who's config file escapes me for the moment. modems -> chat script tweaking mouse -> gtk app that pays with mouse bindings network -> know this back and foreward too, grabbs info from the loaded kernel modules passwords -> password wrapper for xdm, gdm, *dm password thingies regonal settings -> sets loocale varible sceduled tasks -> wrapper for editing the chrontab It's a big task, but I have faith in myself. I'm going to be build a "base system" tomarrow (Ceryix 133, 40M ram, Sound Blaster, Matrox graphics card, and a 814M HD) Feel free to comment. I have no web page on the porject yet, I don't want to call attention to myself in case it turns out to be a bigger project that I intended. Maybe we can use a form of this as a DirectX-compatible only OS that can just run games. Look out X-box ^_^ -Halkun

1 0

Small DDraw problem
by Lionel Ulmer Feb. 12, 2001

Feb. 12, 2001

Hi all, After seeing the reports on cemw of Grim Fandango not working anymore, I decided to check it out. Install worked fine, but the game did not work. It stopped just after doing a SetCooperativeLevel. After some checkings, the error came from there (file dlls/ddraw/ddraw/main.c) : HRESULT WINAPI Main_DirectDraw_SetCooperativeLevel(LPDIRECTDRAW7 iface, HWND hwnd, DWORD cooplevel) { (....) if ((This->cooperative_level & DDSCL_EXCLUSIVE) && (cooplevel & DDSCL_EXCLUSIVE)) return DDERR_EXCLUSIVEMODEALREADYSET; (....) } Grim Fandango did the following : fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4039a090)->(00000138,00000051) - DDSCL_FULLSCREEN DDSCL_ALLOWMODEX DDSCL_EXCLUSIVE (...) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4039a090)->(00000138,00000011) - DDSCL_FULLSCREEN DDSCL_EXCLUSIVE I wonder if this test is really needed ? My interpretation of the 'DDERR_EXCLUSIVEMODEALREADYSET' error was that ANOTHER application already used this flag, not that it was already set for the current application. Anyway, removing this test fixed Grim Fandango. It now starts fine, except for some palette problems. If you agree, I will submit a patch that removes this test :-) Lionel PS: I found out that Grim Fandango eats up my X auto repeat (I need to do a 'xset r on' after)... I thought that this was removed in recent Wine versions ?

4 3

Explorer/shell question.
by Rob Landley Feb. 12, 2001

Feb. 12, 2001

I don't personally use windows, but I have a lot of friends who do. I just showed a friend 98lite.net (which has apparently gone commercial in the last year or two; I was actually looking for the list of instructions the used to have on how to replace the 98 I.E. based explorer with the 95 filesystem only explorer and delete I.E. from the system). Unfortunately, the 95 explorer, being MS intellectual property, can't be included with 98lite, they have to have a copy of 95 (pre OSR 2.5) lying around. I vaguely remembered this list discussing cloning the filesystem explorer months and months back, so my next thought was to wander over to winehq and see if you guys had cloned the filesystem explorer in such a way it could potentially be cleaned up and used to browse the filesystem so I.E. can be deleted. I didn't find one here, so I'm guessing the outcome of said discussion was "no, we aren't going to do that", but it seemed to be a question worth asking anyway. So: has anybody simply cloned the 95 explorer yet? Would the clone run under windows itself? How deeply does it have its tentacles into the guts of the rest of the system? Where would I go to look for such a thing? Rob __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

3 2

Re: Novell filesystem support
by gerard patel Feb. 12, 2001

Feb. 12, 2001

At 01:44 PM 12/2/01 +1200, you wrote: <snip> >program, by writting into the users maildir. How this is done is >under novel you can Create files in directorys that you cannot see(if >that permisson is greated to you). But you can't do this under unix. >So the need to implement file i/o for novell files arises. Why not just give the Scan file right to the user ? Certainly more simple, and this is not a very serious security breakage IMO. Gerard

3 3

Fix to OpenGL for BadMatch issue with Alice
by Gavriel State Feb. 12, 2001

Feb. 12, 2001

Hi Lionel, I recently remembered that I hadn't mentioned the below patch to you. This is something that we put in the last TG patch to fix an issue with Alice, but I'm not sure if the problem in question is the fault of the Wine OpenGL code or an issue with NVidia's OpenGL driver (I haven't really tried it on other drivers yet). Alice creates a rendering window, then walks through the pixel formats for that window's DC using DescribePixelFormat. The current implementation of DescribePixelFormat simply creates a new visual for each pixel format by calling glXChooseVisual. Under the NVidia libGL, at least, this creates a new visual even if there's already a visual that matches the requested parameters. Once we try to create a wgl context, the previous implementation was picking one of the newly created visuals, and initializing the glX context with that. An instant later, we get an X BadMatch error, since the rendering window that Alice is using was created with the default X11DRV visual, not the visual that was created by DescribePixelFormat. The patch below is a simple fix to just always use the X11DRV visual when creating contexts. Ideally we would somehow recreate the X11DRV window with the new visual, but I suspect that will have to wait for significant restructuring of the X11DRV. I didn't notice until later that you'd done a similar hack in X11DRV_ChoosePixelFormat, forcing the visual there to be the default. We could do the same thing for X11DRV_DescribePixelFormat as well, or we could simply drop most of the visual management code in graphics/x11drv/opengl.c and use my patch below. What's your preference? -Gav Index: wine/dlls/opengl32/wgl.c diff -u wine/dlls/opengl32/wgl.c:1.1.1.3 wine/dlls/opengl32/wgl.c:1.3 --- wine/dlls/opengl32/wgl.c:1.1.1.3 Tue Jan 23 12:12:23 2001 +++ wine/dlls/opengl32/wgl.c Tue Jan 23 12:23:42 2001 @@ -78,6 +78,8 @@ X11DRV_PDEVICE *physDev; XVisualInfo *vis; Wine_GLContext *ret; + int num; + XVisualInfo template; TRACE("(%08x)\n", hdc); @@ -88,8 +90,9 @@ physDev = (X11DRV_PDEVICE *)dc->physDev; - /* First, get the visual for the choosen pixel format */ - vis = physDev->visuals[physDev->current_pf - 1]; + /* First, get the visual in use by the X11DRV */ + template.visualid = XVisualIDFromVisual(X11DRV_GetVisual()); + vis = XGetVisualInfo(display, VisualIDMask, &template, &num); if (vis == NULL) { ERR("NULL visual !!!\n"); @@ -299,7 +302,7 @@ return ret->func; } else { - ERR("Extension defined in the OpenGL library but NOT in opengl_ext.c... Please report (lionel.ulmer(a)free.fr) !\n"); + ERR("Extension %s defined in the OpenGL library but NOT in opengl_ext.c... Please report (lionel.ulmer(a)free.fr) !\n", lpszProc); return NULL; } } -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

Novell filesystem support
by Simeon Pilgrim Feb. 12, 2001

Feb. 12, 2001

Hello, I have been making Wine support Novell Bindery calls via the ncplib, so that I can get Pegasus mail to do mhs mail. But i've hit the brick wall, novell file operations on a window -> unix -> novell file system dose not work very well. So what needs to happen is make Wine know about other file system types other than dos / windows / unix. What I was thinking is, there must be some system that windows uses to register extra file systems and then use supplied functions for read/write/etc operations. Dose Wine also support this system, or should it be made to do this? If this is in place where in the code should I look for references. If it is not supported, is it something that is should be supported in the future( i.e. a clean implementation ) or is an ugly little hack ok. If doing a hack, what structures should I add the extra information to, what structures should I not touch. p.s. sorry if this has been brought up before, I found it hard to search the archives. Regards, Simeon Pilgrim ------------------------------------------------------------- Simeon Pilgrim 27 Nazareth Avenue System Test Engineer PO Box 8011 Allied Telesyn Research Christchurch 8034 (An Allied Telesyn Group company) New Zealand phone +64 3 377 8900 fax +64 3 377 8870 -------------------------------------------------------------

2 2

[Fwd: Eyes requested]
by Ian Pilcher Feb. 12, 2001

Feb. 12, 2001

Ian Pilcher wrote: > > Can anyone comment on whether using alloca will mess up Wine? (Jon's > comment seems to imply that he avoids alloca on general principles, > rather than for Wine-specific reasons.) Does Wine use exceptions? > Never mind. Upon further review, alloca looks like a bad idea all the way around. (God forbid C should actually include a feature that makes someone's life easier!) -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

1 0

Eyes requested
by Ian Pilcher Feb. 12, 2001

Feb. 12, 2001

Attached is a patch to implement EnumPrinterDataEx (which should let everyone be happy about where the PostScript driver's font substitution table goes). Since this is the first time I've implemented a "real" Win32 API, rather than just doing internal tweaking, I may have missed something that's glaringly obvious to the more experienced. Before I send this to wine- patches, I'd appreciate it if some folks would take a quick look and let me know what they think. Thanks! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ======================================================================== --- ../wine-20010203cvs/include/winspool.h Sun Feb 11 21:46:34 2001 +++ include/winspool.h Sun Feb 11 14:59:53 2001 @@ -763,6 +763,25 @@ DECL_WINELIB_TYPE_AW(PPROVIDOR_INFO_1) DECL_WINELIB_TYPE_AW(LPPROVIDOR_INFO_1) +typedef struct _PRINTER_ENUM_VALUESA { + LPSTR pValueName; + DWORD cbValueName; + DWORD dwType; + LPBYTE pData; + DWORD cbData; +} PRINTER_ENUM_VALUESA, *PPRINTER_ENUM_VALUESA; + +typedef struct _PRINTER_ENUM_VALUESW { + LPWSTR pValueName; + DWORD cbValueName; + DWORD dwType; + LPBYTE pData; + DWORD cbData; +} PRINTER_ENUM_VALUESW, *PPRINTER_ENUM_VALUESW; + +DECL_WINELIB_TYPE_AW(PRINTER_ENUM_VALUES) +DECL_WINELIB_TYPE_AW(PPRINTER_ENUM_VALUES) + /* DECLARATIONS */ INT WINAPI DeviceCapabilitiesA(LPCSTR pDevice,LPCSTR pPort,WORD fwCapability, LPSTR pOutput, LPDEVMODEA pDevMode); @@ -1082,6 +1101,14 @@ BOOL WINAPI DeletePrintProvidorW(LPWSTR pName, LPWSTR pEnvironment, LPWSTR pPrintProvidorName); #define DeletePrintProvidor WINELIB_NAME_AW(DeletePrintProvidor) + +DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues); +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues); +#define EnumPrinterDataEx WINELIB_NAME_AW(EnumPrinterDataEx) --- ../wine-20010203cvs/dlls/winspool/winspool.drv.spec Sun Feb 11 21:46:34 2001 +++ dlls/winspool/winspool.drv.spec Sun Feb 11 14:59:53 2001 @@ -80,6 +80,10 @@ @ stub EnumPrintProcessorDatatypesW @ stub EnumPrintProcessorsA @ stub EnumPrintProcessorsW +@ stub EnumPrinterDataA +@ stdcall EnumPrinterDataExA(long str ptr long ptr ptr) EnumPrinterDataExA +@ stdcall EnumPrinterDataExW(long wstr ptr long ptr ptr) EnumPrinterDataExW +@ stub EnumPrinterDataW @ stdcall EnumPrinterDriversA(str str long ptr long ptr ptr) EnumPrinterDriversA @ stdcall EnumPrinterDriversW(wstr wstr long ptr long ptr ptr) EnumPrinterDriversW @ stdcall EnumPrintersA(long ptr long ptr long ptr ptr) EnumPrintersA --- ../wine-20010203cvs/dlls/winspool/info.c Sun Feb 11 21:46:34 2001 +++ dlls/winspool/info.c Sun Feb 11 21:36:19 2001 @@ -2561,3 +2561,322 @@ return GetPrinterDataExW(hPrinter, PrinterDriverDataW, pValueName, pType, pData, nSize, pcbNeeded); } + +/* + * The Win32 doc says that RegCloseKey and HeapFree can fail, but it's hard to + * imagine why either of them would. And what is the calling function supposed + * to do about it anyway? + */ + +#define REGCLOSEKEY(X) \ +{ \ + DWORD ret; \ + \ + ret = RegCloseKey (X); \ + if (ret != ERROR_SUCCESS) \ + WARN ("RegCloseKey returned %li\n", ret); \ +} + +#define HEAPFREE(X,Y,Z) \ +{ \ + if (HeapFree ((X), (Y), (Z)) == 0) \ + WARN ("HeapFree failed with code %li\n", GetLastError ()); \ +} + +/******************************************************************************* + * EnumPrinterDataExW [WINSPOOL.197] + */ +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + HKEY hkPrinter, hkSubKey; + DWORD ret, dwIndex, cValues, cbMaxValueNameLen, + cbValueNameLen, cbMaxValueLen, cbValueLen, + cbBufSize, dwType; + LPWSTR lpValueName; + HANDLE hHeap; + PBYTE lpValue; + PPRINTER_ENUM_VALUESW ppev; + + TRACE ("%08x %s\n", hPrinter, debugstr_w (pKeyName)); + + if (pKeyName == NULL || *pKeyName == 0) + return ERROR_INVALID_PARAMETER; + + ret = WINSPOOL_GetOpenedPrinterRegKey (hPrinter, &hkPrinter); + if (ret != ERROR_SUCCESS) + { + TRACE ("WINSPOOL_GetOpenedPrinterRegKey (%08x) returned %li\n", + hPrinter, ret); + return ret; + } + + ret = RegOpenKeyExW (hkPrinter, pKeyName, 0, KEY_READ, &hkSubKey); + if (ret != ERROR_SUCCESS) + { + REGCLOSEKEY (hkPrinter); + TRACE ("RegOpenKeyExW (%08x, %s) returned %li\n", hPrinter, + debugstr_w (pKeyName), ret); + return ret; + } + + REGCLOSEKEY (hkPrinter); + + ret = RegQueryInfoKeyW (hkSubKey, NULL, NULL, NULL, NULL, NULL, NULL, + &cValues, &cbMaxValueNameLen, &cbMaxValueLen, NULL, NULL); + if (ret != ERROR_SUCCESS) + { + REGCLOSEKEY (hkSubKey); + TRACE ("RegQueryInfoKeyW (%08x) returned %li\n", hkSubKey, ret); + return ret; + } + + TRACE ("RegQueryInfoKeyW returned cValues = %li, cbMaxValueNameLen = %li, " + "cbMaxValueLen = %li\n", cValues, cbMaxValueNameLen, cbMaxValueLen); + + if (cValues == 0) /* empty key */ + { + REGCLOSEKEY (hkSubKey); + *pcbEnumValues = *pnEnumValues = 0; + return ERROR_SUCCESS; + } + + ++cbMaxValueNameLen; /* allow for trailing '\0' */ + lpValueName = alloca (cbMaxValueNameLen * sizeof (WCHAR)); + if (lpValueName == NULL) + { + ERR ("Failed to allocate %li bytes on stack\n", + cbMaxValueNameLen * sizeof (WCHAR)); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + lpValue = HeapAlloc (hHeap, 0, cbMaxValueLen); + if (lpValue == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", cbMaxValueLen); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + TRACE ("pass 1: calculating buffer required for all names and values\n"); + + cbBufSize = cValues * sizeof (PRINTER_ENUM_VALUESW); + + TRACE ("%li bytes required for %li headers\n", cbBufSize, cValues); + + for (dwIndex = 0; dwIndex < cValues; ++dwIndex) + { + cbValueNameLen = cbMaxValueNameLen; cbValueLen = cbMaxValueLen; + ret = RegEnumValueW (hkSubKey, dwIndex, lpValueName, &cbValueNameLen, + NULL, NULL, lpValue, &cbValueLen); + if (ret != ERROR_SUCCESS) + { + HEAPFREE (hHeap, 0, lpValue); + REGCLOSEKEY (hkSubKey); + TRACE ("RegEnumValueW (%li) returned %li\n", dwIndex, ret); + return ret; + } + + TRACE ("%s [%li]: name needs %li bytes, data needs %li bytes\n", + debugstr_w (lpValueName), dwIndex, + (cbValueNameLen + 1) * sizeof (WCHAR), cbValueLen); + + cbBufSize += (cbValueNameLen + 1) * sizeof (WCHAR); + cbBufSize += cbValueLen; + } + + TRACE ("%li bytes required for all %li values\n", cbBufSize, cValues); + + *pcbEnumValues = cbBufSize; + *pnEnumValues = cValues; + + if (cbEnumValues < cbBufSize) /* buffer too small */ + { + HEAPFREE (hHeap, 0, lpValue); + REGCLOSEKEY (hkSubKey); + TRACE ("%li byte buffer is not large enough\n", cbEnumValues); + return ERROR_MORE_DATA; + } + + TRACE ("pass 2: copying all names and values to buffer\n"); + + ppev = (PPRINTER_ENUM_VALUESW) pEnumValues; /* array of structs */ + pEnumValues += cValues * sizeof (PRINTER_ENUM_VALUESW); + + for (dwIndex = 0; dwIndex < cValues; ++dwIndex) + { + cbValueNameLen = cbMaxValueNameLen; cbValueLen = cbMaxValueLen; + ret = RegEnumValueW (hkSubKey, dwIndex, lpValueName, &cbValueNameLen, + NULL, &dwType, lpValue, &cbValueLen); + if (ret != ERROR_SUCCESS) + { + HEAPFREE (hHeap, 0, lpValue); + REGCLOSEKEY (hkSubKey); + TRACE ("RegEnumValueW (%li) returned %li\n", dwIndex, ret); + return ret; + } + + cbValueNameLen = (cbValueNameLen + 1) * sizeof (WCHAR); + memcpy (pEnumValues, lpValueName, cbValueNameLen); + ppev[dwIndex].pValueName = (LPWSTR) pEnumValues; + pEnumValues += cbValueNameLen; + + /* return # of *bytes* (including trailing \0), not # of chars */ + ppev[dwIndex].cbValueName = cbValueNameLen; + + ppev[dwIndex].dwType = dwType; + + memcpy (pEnumValues, lpValue, cbValueLen); + ppev[dwIndex].pData = pEnumValues; + pEnumValues += cbValueLen; + + ppev[dwIndex].cbData = cbValueLen; + + TRACE ("%s [%li]: copied name (%li bytes) and data (%li bytes)\n", + debugstr_w (lpValueName), dwIndex, cbValueNameLen, cbValueLen); + } + + HEAPFREE (hHeap, 0, lpValue); + REGCLOSEKEY (hkSubKey); + return ERROR_SUCCESS; +} + +/******************************************************************************* + * EnumPrinterDataExA [WINSPOOL.196] + * + * The observant will note that this function returns ASCII strings in Unicode- + * sized buffers (for value names and values of type REG_SZ, REG_EXPAND_SZ, and + * REG_MULTI_SZ). This is what Windows 2000 does. + * + */ +DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + INT len; + LPWSTR pKeyNameW; + DWORD ret, dwIndex, dwBufSize; + HANDLE hHeap; + LPSTR pBuffer; + + TRACE ("%08x %s\n", hPrinter, pKeyName); + + if (pKeyName == NULL || *pKeyName == 0) + return ERROR_INVALID_PARAMETER; + + len = MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, NULL, 0); + + pKeyNameW = alloca (len * sizeof (WCHAR)); + if (pKeyNameW == NULL) + { + ERR ("Failed to allocate %li bytes on stack\n", + (LONG) len * sizeof (WCHAR)); + return ERROR_OUTOFMEMORY; + } + + if (MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, pKeyNameW, len) == 0) + { + TRACE ("MultiByteToWide Char (%s, %i) failed with code %li\n", pKeyName, + len, GetLastError ()); + return GetLastError (); + } + + ret = EnumPrinterDataExW (hPrinter, pKeyNameW, pEnumValues, cbEnumValues, + pcbEnumValues, pnEnumValues); + if (ret != ERROR_SUCCESS) + { + TRACE ("EnumPrinterDataExW returned %li\n", ret); + return ret; + } + + if (*pnEnumValues == 0) /* empty key */ + return ERROR_SUCCESS; + + dwBufSize = 0; + for (dwIndex = 0; dwIndex < *pnEnumValues; ++dwIndex) + { + PPRINTER_ENUM_VALUESW ppev = + &((PPRINTER_ENUM_VALUESW) pEnumValues)[dwIndex]; + + if (dwBufSize < ppev->cbValueName) + dwBufSize = ppev->cbValueName; + + if (dwBufSize < ppev->cbData && (ppev->dwType == REG_SZ || + ppev->dwType == REG_EXPAND_SZ || ppev->dwType == REG_MULTI_SZ)) + dwBufSize = ppev->cbData; + } + + TRACE ("Largest Unicode name or value is %li bytes\n", dwBufSize); + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + return ERROR_OUTOFMEMORY; + } + + pBuffer = HeapAlloc (hHeap, 0, dwBufSize); + if (pBuffer == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", dwBufSize); + return ERROR_OUTOFMEMORY; + } + + for (dwIndex = 0; dwIndex < *pnEnumValues; ++dwIndex) + { + PPRINTER_ENUM_VALUESW ppev = + &((PPRINTER_ENUM_VALUESW) pEnumValues)[dwIndex]; + + len = WideCharToMultiByte (CP_ACP, 0, ppev->pValueName, + ppev->cbValueName / sizeof (WCHAR), pBuffer, dwBufSize, NULL, + NULL); + if (len == 0) + { + HEAPFREE (hHeap, 0, pBuffer); + TRACE ("WideCharToMultiByte (%s, %li) failed with code %li\n", + debugstr_w (ppev->pValueName), dwBufSize, GetLastError ()); + return GetLastError (); + } + + memcpy (ppev->pValueName, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + + if (ppev->dwType != REG_SZ && ppev->dwType != REG_EXPAND_SZ && + ppev->dwType != REG_MULTI_SZ) + continue; + + len = WideCharToMultiByte (CP_ACP, 0, (LPWSTR) ppev->pData, + ppev->cbData / sizeof (WCHAR), pBuffer, dwBufSize, NULL, NULL); + if (len == 0) + { + HEAPFREE (hHeap, 0, pBuffer); + TRACE ("WideCharToMultiByte (%s, %li) failed with code %li\n", + debugstr_w ((LPWSTR) ppev->pData), dwBufSize, + GetLastError ()); + TRACE (" (only first string of REG_MULTI_SZ printed)\n"); + return GetLastError (); + } + + memcpy (ppev->pData, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + TRACE (" (only first string of REG_MULTI_SZ printed)\n"); + } + + HEAPFREE (hHeap, 0, pBuffer); + return ERROR_SUCCESS; +} + +#undef REGCLOSEKEY +#undef HEAPFREE

2 2

Re: Novell filesystem support
by gerard patel Feb. 12, 2001

Feb. 12, 2001

At 12:41 PM 12/2/01 +1200, you wrote: >Hello, > >I have been making Wine support Novell Bindery calls via the >ncplib, so that I can get Pegasus mail to do mhs mail. But i've hit >the brick wall, novell file operations on a window -> unix -> novell >file system dose not work very well. <snip> What is not working in file operations ? I have my news messages with a reader working under Wine stored on a 4.10 file server since years. It's not exactly fast but I have yet to lose data. Gerard

1 0