February 2007 - Wine-devel - list.winehq.org

Re: wininet: Improve FtpOpenFile()'s parameter checking and remove the corresponding todo_wines.
by Paul Vriens 16 Feb '07

16 Feb '07

Francois Gouget wrote: > Also make test_getfile_no_open() succeed on Windows 98. > --- > > I have had some strange results with these tests. One of them was > actually succeeding in a todo_wine for a good while. > > dlls/wininet/ftp.c | 12 +++++++++++- > dlls/wininet/tests/ftp.c | 12 +++--------- > 2 files changed, 14 insertions(+), 10 deletions(-) > This was the last one for now on my list, you beat me to it. We do have some conflicting patches now in wine-patches. > diff --git a/dlls/wininet/ftp.c b/dlls/wininet/ftp.c > index 5b073cf..2bd29fd 100644 > --- a/dlls/wininet/ftp.c > +++ b/dlls/wininet/ftp.c > @@ -1011,11 +1011,21 @@ HINTERNET WINAPI FtpOpenFileW(HINTERNET hFtpSession, > debugstr_w(lpszFileName), fdwAccess, dwFlags, dwContext); > > lpwfs = (LPWININETFTPSESSIONW) WININET_GetObject( hFtpSession ); > - if (NULL == lpwfs || WH_HFTPSESSION != lpwfs->hdr.htype) > + if (NULL == lpwfs) > + { > + INTERNET_SetLastError(ERROR_INTERNET_NOT_INITIALIZED); > + goto lend; Why do a 'goto lend' you could just 'return FALSE' like I did in the other ftp functions. No need do another check for lpwfs being NULL. If you do a 'return FALSE' you could also get rid of the check for lpwfs being NULL right after lend:. > + } > + if (WH_HFTPSESSION != lpwfs->hdr.htype) > { > INTERNET_SetLastError(ERROR_INTERNET_INCORRECT_HANDLE_TYPE); > goto lend; > } > + if (dwFlags & ~(INTERNET_FLAGS_MASK|FTP_TRANSFER_TYPE_MASK)) > + { > + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); > + goto lend; > + } I think this covers the 5 in the test but not all possible combinations. I did some (loop) testing with dwFlags (also used in FtpGetFile and FtpPutFile) and it appears all boils down to the last 3 bits (see FtpGetFile). Cheers, Paul.

1 0

Re: [7/10] WineD3D: Test for supported queries
by Juan Lang 16 Feb '07

16 Feb '07

Hi Stefan, + hr = IDirect3D9_CreateDevice( pD3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hwnd, + D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &pDevice ); + ok(SUCCEEDED(hr), "Failed to create IDirect3D9Device (%s)\n", DXGetErrorString9(hr)); + if (FAILED(hr)) goto cleanup; (snip) + cleanup: + if(pDevice) IDirect3DDevice9_Release(pDevice); The label cleanup isn't used anywhere except in the failure to create the device. In this case, wouldn't: if (FAILED(hr)) return; be clearer, and omit the unneeded label? There's no reason to release pDevice in creating it failed. --Juan ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

2 1

DIB Engine, some summarization
by Rolf Kalbermatter 16 Feb '07

16 Feb '07

This is getting a bit long so if you do not have time, then skip this. I've looked a little more at the issue of a DIB Engine and tried to use the feedback so far to get an idea what the possible architecture could be. First I took a look at how Windows seems to do it currently (excluding Vista). There GDI32 is mostly a wrapper around win32k.sys and the different GDI APIs call mostly into corresponding NtGdi... functions in win32k.sys. Those functions do the actual handling and call the according driver that is attached to the DC. The interface to the driver is similar to what is done now in Wine although not identical. The modern Windows display driver interface uses sometimes more or less different functions than the old one as used in Wine. A driver can either not implement certain functions, only implement them for its device specific surfaces, or hook certain calls by returning flags inside the driver initialization structure on initialization. Those hook flags tell the GDI engine that the driver wants to be called for DIB surfaces too for particular functions and bit depths. The driver will then be called for according DIB surfaces too and it can decide to do whatever it can do best and for those cases it doesn't know well how to do it, call back into the GDI engine using an according Eng... function. This calling back into the GDI engine for hooked functions is called punting by MS. If the driver didn't provide the actual function it will possibly be simulated by the GDI engine by calling other driver functions and if the driver didn't hook the function or didn't succeed and it is for a DIB surface then the GDI engine itself will call the according Eng... function. GDI32 exports most of those Eng... functions too but that are simply user space wrappers around the win32k.sys entry points for those functions. >From a design view it might be interesting to separate the actual GDI engine into a subpart that corresponds with the NtGdi... functions in win32k.sys eventhough they might stay inside GDI32 for the time being. The actual Eng... functions would be also placed inside that GDI engine and are in fact mostly the long awaited DIB engine. Such an architecture would make reuse of such a GDI32/win32k combo in other projects fairly easy. However this NtGdi API is not documented although it is presumably mostly a mirror of the GDI API. There are lists of what APIs win32k.sys does export and how many parameters each of these functions takes, extracted from the actual win32k.sys file. Eventhough Windows keeps them in the win32k.sys kernel I think it would be a good idea to keep them all in GDI32 for the time being. If that API is at some time mostly complete and separation into its own DLL or something would be desired, this could be done quite easily. But it is certainly quite a bit tedious to do and would require at least partly some sort of clean room reverse engineering and it's not really necessary for a DIB engine at all at this point. There is a little problem with those Eng.. functions however. They are modeled after the new NT display driver interface that is in so far different that it does use partly different functions and parameters to the old (I assume Win 3.1 display driver) interface used in Wine and this is even more or less all documented in the DDK, although the basic principle between the Windows driver interface and what Wine does is of course mostly the same. I can't really see however how it would be possible to change that interface to match the modern NT display driver interface in a seemless manner as it would mean a significant change in winex11.drv, winequartz.drv and the GDI32 (aka win32k.sys) that would need to be done mostly in a few big chunks to not completly break everything. So what would remain is adding the actual Eng... and object access API to GDI. These APIs are (all?) documented in the DDK and could be implemented based on MSDN information alone together with maybe some test cases. The actual driver interface might remain mostly the same as it is now with some extra addition to return to the GDI engine extra flags to indicate hooks for DIB surfaces. Then implementation of the Eng... functions would have to start and as they are fleshed out and work they get integrated into the calling logic one for one. Until this is completely done the current separations for DIBs into appstate and serverstate would have to remain, so that the X11 driver can still pass them to the X11 server for rendering of not implemented DIB engine operations. Once the DIB engine is finished (if ever :-) this could be removed as the X11 driver would not anymore hook any of the DIB operations. If winequartz.drv wants to continue hooking DIB operations it can do so of course. To start with, the actual header winddi.h defining most of the Eng.. calls could be added as ddk header to Wine. There seems to be a copyright free version of this header file from Casper S. Hornstrup that is part of the w32api package. I have thought about modifying the driver function call array instead as Alexandre has pointed out in the past as possible solution instead of adding the actual Eng... calls explicitedly into the GDI engine as fall back. But this seems not a good solution to me. The driver wants to be informed of graphic operations for device specific surfaces most often I would assume and only might want to not get called for device contexts containing a dib section. And as some have pointed out winequartz may even want to get called for DIBs too. In order to allow for such a dynamic overriding of function pointers in the driver function array, that array would have to be allocated dynamically on a device context base and I think this would make everything slower, more memory consuming and it wouldn't really be easier although I admit that adding Eng.. calls everywhere and correctly is quite some work to do. The issue about network transparency for the display driver would not be an issue IMO. Once complete the DIB engine would handle all DIB operations locally and so no need for translating direct memory access into remote calls to some display server would be necessary. And the blitting of DIBs to the display when necessary would still be done through the driver of course so everything would be transparent as far as the capabilities of the used display device itself allow for that. Rolf Kalbermatter

5 6

regression in 613998d4f6ff953a22a4455a28f77d2126642c7d
by Marcus Meissner 16 Feb '07

16 Feb '07

Hi Shanren, your commit 613998d4f6ff953a22a4455a28f77d2126642c7d Author: Shanren Zhou <shanren(a)ucla.edu> Date: Mon Feb 12 19:53:51 2007 -0800 comctl32: Add header tests. generates a Coverity Warning in this code: ... HIMAGELIST hImageList; HIMAGELIST hImageListRetVal; hImageListRetVal = (HIMAGELIST) SendMessage(hWndHeader, HDM_SETIMAGELIST, 0, (LPARAM) &hImageList); HDM_SETIMAGELISTs parameter is used and stored, so hImageList should be: - initialized to something (likely 0 is ok, didnt check) - and not a pointer (did you add the & just to kill the warning?) Ciao, Marcus

1 0

Re: [1/4] wined3d: Fix WINED3DPRESENT_PARAMETERS and use it instead of D3DPRESENT_PARAMETERS
by Duane Clark 15 Feb '07

15 Feb '07

H. Verbeet wrote: > It looks like the patch might be a bit large for the list, here's a > compressed version instead. > Anything over 80K just gets caught in the mail queue. It should get through eventually.

1 0

Office 2007 help wine
by Keith H. Pratt 15 Feb '07

15 Feb '07

Hi, I went to a Microsoft Launch for their enterprise and business products this past tuesday, and they gave me a full version of Office 2007 Professional. Nice of them huh. Well, I am a linux user, and an avid evangelist for open source, and for anything that lets thw linux and windows world work together. I also have spent a considerable amount of time testing and bug reporting beta software. With all that said, here's my point. What can I do with this software to help you in the testing and development of wine? I run a dual-boot system with winxp and ubuntu linux. linux is where i work, and windows is there to make it easier to support my clients in their windows machines. If theres nothing now that applies to wine and office 2007, maybe keep this message for when the need does arise. Thanks Keith

2 1

Re: [PATCH 6/6] kernel32: Fix the GetComputerName* functions to not write to the buffer at all if there is not enough space.
by Alexandre Julliard 15 Feb '07

15 Feb '07

Robert Shearman <rob(a)codeweavers.com> writes: > Remove the exception handlers, since testing on XP SP2 shows that > access violations are not caught. Yes, but they are caught on Win9x, and the handler was added because an app needed it. I'd suggest to keep it at least in the A function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Symbol encoding should be always selectable
by Dmitry Timoshkov 15 Feb '07

15 Feb '07

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > this patch fixes a failure in the font charset test in the case when > only Arial is installed. As the test shows the symbol encoding should be > always selectable. Please do not commit this patch, it's wrong. According to GetTextFace XP selects Wingdings if SYMBOL_CHARSET was requested. I'm not sure how to make the test pass: probably SYMBOL_CHARSET should be skipped if Symbol or Wingdings are not installed. -- Dmitry.

1 0

WINSPOOL: search for a printer driver
by Vitaly Lipatov 15 Feb '07

15 Feb '07

When wine is loading, CUPS_LoadPrinters function get printer list from CUPS and add printer and their printer drivers to registry. If printer is already exist, we do not override nor printer driver, nor printer entry. It all works fine. Note, we place printer driver in "Windows 4.0" registry entry if Wine version is win9x and use "Windows NT x86" registry entry if Wine version is win2000 and above. If we will change wine version after printer loaded, Wine printing is got failed. Wine search in empty registry entry. For example, I get such configuration after run wine in win98 mode: [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows 4.0\\Drivers\\hp] 1171461136 "Configuration File"="wineps16" "Data File"="<datafile?>" "Datatype"="RAW" "Dependent Files"=str(7):"<dependent files?>\0" "Driver"="wineps16" "Help File"="<helpfile?>" "Monitor"="<monitor name?>" "Version"=dword:00000000 [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows NT x86\\Drivers\\Version-3] 1171461821 [System\\CurrentControlSet\\Control\\Print\\Printers\\hp] 1171461818 "Attributes"=dword:00000000 "Datatype"="RAW" "Default DevMode"=hex:68,70,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ ... "Description"="WINEPS Printer using CUPS" "Location"="<physical location of printer>" "Name"="hp" "Parameters"="<parameters?>" "Port"="LPR:hp" "Print Processor"="WinPrint" "Printer Driver"="hp" ... I try to find a better way to resolve this problem. Some ideas: 1. Check if Wine version is changed and reset printer drivers. 2. Search in both registry entry in any way. 3. ... -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Direct Draw "palette_convert"
by Nathan Williams 15 Feb '07

15 Feb '07

I'm working on some direct draw code to get Carmageddon working. I think I have found my issue in IWineD3DPaletteImpl_SetEntries Carmageddon runs in 8 bit mode, my x windows is set at 24bit. If I drop xorg to 8bit, wine refuses to load. If i set it to 16bit, the Carmageddon menus are still bad, but noticeably better then running in 24bit. In SetEntries there is a bit of code idef'd out: #if 0 /* Now, if we are in 'depth conversion mode', update the screen palette */ /* FIXME: we need to update the image or we won't get palette fading. */ if (This->ddraw->d->palette_convert != NULL) This->ddraw->d->palette_convert(palent,This->screen_palents,start,count); #endif Uncommenting the above only leads to compile errors. Dredging through the wine archives, I see that the palette convert functions haven't been there since 2000. Can anyone give me an idea on why they were removed & what might be the best way to reimplement some form of palette conversion? (Even just in a hacky way right now, so i can test my assumptions) -- Nathan

4 4