August 2007 - Wine-Devel - list.winehq.org

re: Using pthread_create within Wine
by Dan Kegel Aug. 22, 2007

Aug. 22, 2007

Phil wrote: >The Wine socket implementation has problems when it comes to select. >A fix for this problem is not currently on anybody's radar. > http://www.winehq.org/pipermail/wine-devel/2006-February/044588.html Hmm. You never filed a bug at http://bugs.winehq.org for this, it seems. Could you, please? Incidentally, I ported your test app to Unix, and on Linux, it prints out THIS IS WINE. I'm not sure why you can't adapt your code to deal with the difference in select behavior -- is the problem third party code you have no source for? - Dan

1 0

re: gphoto2.ds: remove camera import UI
by Dan Kegel Aug. 22, 2007

Aug. 22, 2007

Lei wrote: > ... > The alternative is to keep the GUI. It is useful in the case where > there's many pictures on the camera, and the user just want to import > a few of them. We would need to: > > - modify the GUI to fix the crash > - do not automatically generate download thumbnails, but rather, > present the user with the options to download thumbnails, or just go > ahead and import all pictures > - perhaps add a winecfg option to turn off the GUI Rather than remove all that nearly-working code, how about keeping it, adding the winecfg option, and making it default to off for now? (i.e. leave fixing the bug for later.) That should be a smaller, less violent patch... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 3

Using pthread_create within Wine
by Phil Lodwick Aug. 22, 2007

Aug. 22, 2007

Greetings, I have a proprietary library that has both Windows and Linux ports. The Windows DLL has problems running on Wine, so I have created a builtin version of this DLL in Wine. This has worked fine, except for one function that basically creates a new thread and fires back events to the calling Window application. I believe I have traced this down to the Linux version of the library creating the new thread with pthread_create. Windows.exe Call_dll_to_spawn_thread_and_register_callback(MyCallbackfunc); Windows DLL implemented in wine: void * NewThread(void *p) { MyParams *params = (MyParams *)p; for (i = 0; i < 500000; i++) p->Callback(); } void Call_dll_to_spawn_thread_and_register_callback(void (*callback)()) { MyParams *params = (MyParams *)malloc(sizeof(MyParams)); params->Callback = callback; pthread_create(&MyThread, NULL, NewThread, (void *)params); } If instead of using pthread_create I use CreateThread, I never have a problem. I notice no other wine DLLs are using pthread_create and I have seen hints that this might not work. If so, how do I use the Linux library. (Call_dll_to_spawn_thread_and_register_callback is just simulating what the Linux library would do) Do I create a separate thread using CreateThread to communicate back to the Window application, so that Call_dll_to_spawn_thread_and_register_callback effectively creates two threads, one using CreateThread (Wine DLL), one using pthread_create (Linux Library) and then do synchronization between the two? Any help, suggestion, ideas, questions would be greatly appreciated. Phil

4 5

Compositing GL
by Chris Robinson Aug. 22, 2007

Aug. 22, 2007

Over the past several days, I've been working with some people in #winehackers on a way to help solve the problems Wine faces with OpenGL.. namely the lack of useable onscreen pixel formats and broken child windown rendering. Here's a patch for your perusal in hopes to generate feedback. What this does is, it renders GL to an offscreen buffer the size of the window it's rendering to, first trying a redirected window (if you have the Xcomposite extension), then falling back to GLXPixmaps (which may be slower, especially if you don't have AIGLX). The offscreen buffer is then copied to the window it should be displaying on using X, acting in a manner nearly identical to how Vista composites OpenGL (as described here: http://www.opengl.org/pipeline/article/vol003_7/ ). Given that it uses X to do the final composite, it obeys all clipping regions, which means it works even on obscured child windows. And since it's offscreen, it won't interfere with, or be bothered by, Wine's window. It also allows it to use other visuals/pixel formats than Wine's window (not done in this patch yet). There is a speed hit, however. The DX9 swap chains demo, which gets about 280 FPS for me normally, gets about 80 to 90 FPS with the compositing method. It seems to be a ceiling though, as other more GPU intense apps have no extra noticeable slow down. Still, as an optimization, it can render directly to the window when it's being used on the whole window and the selected pixel format matches the current visual (this bit is disabled in the patch since it's for testing offscreen rendering, but it's simple to re-enable). Further, a registry setting (HKCU\Software\Wine\X11 Driver\CompositeGL) can be used to force GL compositing off to give you the current behavior (single onscreen pixel format, broken child window rendering). This obviously isn't the final patch, however it's likely what the final result will be like, forgoing unforeseen issues. Questions and comments are welcome.

4 7

Re: include: add some definitions to winioctl.h (patch)
by Robert Shearman Aug. 22, 2007

Aug. 22, 2007

Mikolaj Zalewski wrote: > -#define IOCTL_STORAGE_GET_MEDIA_TYPES CTL_CODE(IOCTL_STORAGE_BASE, 0x0300, METHOD_BUFFERED, FILE_ANY_ACCESS) > -#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_TYPES CTL_CODE(IOCTL_STORAGE_BASE, 0x0300, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER CTL_CODE(IOCTL_STORAGE_BASE, 0x0305, METHOD_BUFFERED, FILE_ANY_ACCESS) > The above should be 0x0304 instead of 0x0305. > +#define IOCTL_STORAGE_GET_HOTPLUG_INFO CTL_CODE(IOCTL_STORAGE_BASE, 0x0305, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_SET_HOTPLUG_INFO CTL_CODE(IOCTL_STORAGE_BASE, 0x0306, METHOD_BUFFERED, FILE_READ_ACCESS) > -- Rob Shearman

2 1

gphoto2.ds: remove camera import UI
by Luke Bratch Aug. 22, 2007

Aug. 22, 2007

--- Alexandre Julliard <julliard at winehq.org> wrote: > > Rather than remove all that nearly-working code, > > how about keeping it, adding the winecfg option, > > and making it default to off for now? > > That option is much too specific to go in winecfg, it's > something most > users don't care about. What you could do though is have a "don't show > this dialog again" option in the dialog itself. How about a registry key? ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

1 0

Re: [2/5] WineD3D: Refuse to lock locked surfaces
by H. Verbeet Aug. 22, 2007

Aug. 22, 2007

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Spotted by DCT > I don't know what the DCT actually tests, but should it refuse to lock any locked surface, or only when the rectangles overlap? Of course a test would be nice, considering surface locking behaves somewhat different between ddraw, d3d8 and d3d9.

2 2

Re: [5/5] WineD3D: Fake occlusion queries if the wrong context is active
by H. Verbeet Aug. 22, 2007

Aug. 22, 2007

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Can't we wait for the other thread & context to become active? Afaik occlusion queries are allowed to block on Windows.

2 1

Changing Bugzilla settings so a single person can't confirm bugs by "popular vote"
by Kai Blin Aug. 22, 2007

Aug. 22, 2007

Hi folks, While working on bug 9405, I realized that all 20 votes on that bug were made by the reporter. I think that's pretty lame, so I've asked the bugzilla folks if there's a way to fix that. They said that the settings should be obvious when editing the product. Can we please fix that? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

4 4

Re: advapi32: Add more tests for CryptVerifySignatureW, and correct its parameter checking
by Alexandre Julliard Aug. 22, 2007

Aug. 22, 2007

"Juan Lang" <juan.lang(a)gmail.com> writes: > From 53a45e7e2adf3b8591f2c07501e7b37538d95657 Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Tue, 21 Aug 2007 15:10:35 -0700 > Subject: [PATCH] Add more tests for CryptVerifySignatureW, and correct its parameter checking This breaks the tests: ../../../tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p rsaenh_test.exe.so rsaenh.c && touch rsaenh.ok rsaenh.c:1081: Test failed: Expected ERROR_INVALID_PARAMETER error, got 80090006 make: *** [rsaenh.ok] Error 1 Also the indentation is messed up, please fix your tab size. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: How to Calling PE Dlls on linux??
by trulyliu Aug. 22, 2007

Aug. 22, 2007

Hi, Damjan Jovanovic Thank you tired of the answer to my questions. I carefully read the wine part of the code and development document, searched in mail lists, these days. And I got some inspiration from wine plugin API wiki page and wine loader's code. I am considering of an approach. Link preloader and related resource(libwine) with my Linux native App. Do some modify with wine_init function, and call it before main(). This can be implemented by a global C++ objects's constructor. Upper two steps can deal with TEP and FS register. But I there may be another problem. If there was aready an static global C++ object in my App, How can I makde it initiatited after wine_init from in object. Do you have some other expostulate of this idea? BTW, I skim over mplayer and xine's parts of code. They don't dealwith TEB and FS register. They only do sth on LDT and allocat PE header before LoadeLibaray. Why they can run correctly??? 2007/8/22, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > > > > > > > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > > > > > > > > > > > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > > > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > > > > > Can I made Arithmetic.dll.so ? And link it against my linux App? > > > > > > > > > > A library function runs in the context of the process that invokes > it. > > > > > A library doesn't have its own TEB/memory layout/exception > handling > > > > > that works independently of the process that calls it, no matter > how > > > > > it is compiled. If the wine plugin API is ever made, it will > modify > > > > > the process so it has what the library expects when the library > > > > > functions are called. > > > > > > > > > > Does your Arithmetic.dll.so call any Windows functions? If so, you > > > > > need wine and you will always need wine, plugin API or no plugin > API, > > > > > whether you compile it into a DLL or .dll.so. But if you only use > ANCI > > > > > C stuff you can compile it into a .so and use it without wine. > > > > > > > > > > If you want something that runs seamlessly on every operating > system > > > > > today, IMHO you should consider Java. > > > > > > > > > > > > > > > > > > > > > > Yes, Java may be a good choice for crossing platform. > > > > > > > > As you said, my Arithmetic.dll does not call any windows function. > > > > It's pure ANSI C library. What's the step of make .dll.so ?? > > > > > > > > Use winegcc or gcc ?? > > > > > > Use gcc and make a .so like this: > > > gcc -c arithmetic.c -fPIC > > > gcc arithmetic.o -shared -o arithmetic.so > > > > > > Then put it in /usr/lib and link to it like so: > > > gcc -c application.c > > > gcc application.o -o application -larithmetic > > > > > > > > > -- > > > > > > trulyliu(a)gmail.com > > > > > Damjan > > > > -- > > > > trulyliu(a)gmail.com > > > > > > > > > > Damjan > > > > gcc -c arithmetic.c -fPIC ??? > > I am sorry. I don't have Arithmetic.dll's source code. > > Can I use LoadLibaray() and GetProcAddress > > to get the function which Arithmetic.dll exports. > > No, for the reasons I talked about before. Eg. GetProcAddress() does > look up the current directory, which resides in the TEB, which AFAIK > resides in the FS CPU register on Windows. On Linux the FS register > contains something else, leading to a crash. > > At the moment, you can only use Windows DLLs from Windows applications > or from winelibs, which are Windows applications compiled to be able > to use Linux libraries as well. > > > -- > > trulyliu(a)gmail.com > > > > Damjan > -- trulyliu(a)gmail.com

1 1

Re: [kernel32/tests] Skip some not implemented functions and add a few skip's
by Francois Gouget Aug. 22, 2007

Aug. 22, 2007

On Tue, 21 Aug 2007, Paul Vriens wrote: > Hi, > > GetTempPathW is not implemented on win9x. I did not actually read the test but it sounds like GetTempPathW() is not actually essential to the test. Could we replace it with another way to get the path for a temporary directory? Maybe even hard-code one, maybe adding the process id to make it somewhat unique? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 1

Re: [1/2] wined3d: Restore a line that got lost
by Stefan Dösinger Aug. 21, 2007

Aug. 21, 2007

Am Dienstag, 21. August 2007 23:22 schrieb H. Verbeet: > This got lost by commit 92ce028a0b3aba513f8fb62d7021533896cd99f6. > > Changelog: > - Restore a line that got lost Actually I think we can remove that whole codeblock now. stateblock::apply and stateblock::capture have the needed states hardcoded now for _ALL, _VERTEX and _PIXEL stateblocks.

1 0

OS X and OpenGL
by Mike Kronenberg Aug. 21, 2007

Aug. 21, 2007

Hello list, I'm a frequent user of wine and normally build my own copy, as no official distribution for Mac OS X exists. Lately I had to deal with a Program, that needs OpenGL. I found different hints on the list and around the net, that the current Apple X11 libGL is broken, so I tried different flavors of xdarwin and x11: X11R6.8.2 and X11R7.2. With X11R6.8 (compiled from fink) wine builds without error. (OpenGL Headers and libs where found) When I run the app, I get: err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_ChoosePixelFormat No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglMakeCurrent No libGL on this box - disabling OpenGL support ! I modified opengl.c to see whether SONAME_LIBGL was set in as_opengl () and it was. With X11R7.2 (pkg form x.org) wine builds without error. (OpenGL Headers and libs where found) but it seams that libGL has a link to a nonexistent library (/usr/X11/ lib/GL), which crashes openGL32.dll when I run the app. Before I start some more debugging on my system: Do you have any hints? (Is this a linking problem / Anybody knows a working revision of X11 / recent bugs, etc) Txs Mike Intel Wine 0.9.43 OS X 10.4.10

1 0

Re: WineD3D: fix a null pointer dereference
by Stefan Dösinger Aug. 21, 2007

Aug. 21, 2007

Am Dienstag, 21. August 2007 16:55 schrieb Roderick Colenbrander: > Hi, > > This patch gets Tiberian Sun working in ddraw OpenGL mode. Before it > suffered > > >from a null pointer dereference bug. This patch is ok with me, but there's a bad flaw with opengl'ed ddraw I want to point out Ddraw apps can just create offscreen surfaces and perform blits between them without creating a render target. To do anything in opengl, a context is needed, and a context needs a drawable. So no gl context without a render target in gl. Now the current code checks if the locked surface is a render target, and crashes because the render target array doesn't exist. This patch simply fixes this NULL pointer dereference. The essential problem remains though, that ddraw operations in gl won't work unless the app creates a render target. Currently it works because only operations on render targets use opengl, but there is code to have opengl do offscreen<->offscreen blits. That code(stretch_rect_fbo) is only used for d3d9, but when activated for ddraw apps too, we have to be careful.

1 0

Re: dinput: Fix compile with old input.h that missing input_absinfo
by Dmitry Timoshkov Aug. 21, 2007

Aug. 21, 2007

"Vitaliy Margolen" <wine-patches(a)kievinfo.com> wrote: > +struct wine_input_absinfo { > + LONG value; > + LONG minimum; > + LONG maximum; > + LONG fuzz; > + LONG flat; > +}; If it's a kernel structure, it's better IMO to use the types that are actually used in the native structure instead of LONG. -- Dmitry.

1 0

Re: How to Calling PE Dlls on linux??
by Damjan Jovanovic Aug. 21, 2007

Aug. 21, 2007

On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > Can I made Arithmetic.dll.so ? And link it against my linux App? A library function runs in the context of the process that invokes it. A library doesn't have its own TEB/memory layout/exception handling that works independently of the process that calls it, no matter how it is compiled. If the wine plugin API is ever made, it will modify the process so it has what the library expects when the library functions are called. Does your Arithmetic.dll.so call any Windows functions? If so, you need wine and you will always need wine, plugin API or no plugin API, whether you compile it into a DLL or .dll.so. But if you only use ANCI C stuff you can compile it into a .so and use it without wine. If you want something that runs seamlessly on every operating system today, IMHO you should consider Java. > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com >: > > On 8/21/07, trulyliu <trulyliu(a)gmail.com > wrote: > > > > > I have tried these code, It works well. Thanks a lot. > > > Could I use gcc/g++ instead of winegcc/wineg++ ??? > > > mplayer use gcc as it's complier？ What's the mystery in it? > > > > > > > gcc/g++ would give you the wrong ABI (eg. 4 bytes per wide char > > instead of 2 bytes), and the special code needed to set up the Windows > > memory layout and the thread extension block and structured exception > > handling wouldn't get executed, leading to segfaults when you call any > > code that tries to access them. That's assuming you can even compile > > and link. > > > > That's why you need winegcc/wineg++. > > > > > trulyliu(a)gmail.com > > > > Damjan > > > > > > > > > > -- > trulyliu(a)gmail.com > Damjan

2 2

Re: [2/5] WineD3D: Use 0/0/0 as normal if no normal is supplied
by H. Verbeet Aug. 21, 2007

Aug. 21, 2007

I'm not sure about this one. Unless explicitly checked for, (0, 0, 0) will cause a division by zero when trying to normalize it, and I don't know for sure if GL has well defined behaviour for it.

2 1

Re: [5/5] WineD3D: Fix fogstart == fogend with table fog
by H. Verbeet Aug. 21, 2007

Aug. 21, 2007

On 21/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Feel free to suggest a better way to increase the fogend. My way works, but it > is not the nicest way. > Does this really matter? To me, this looks like a rather ugly hack to get the DCT to shut up.

2 1

Re: gdi: AddFontResource needs to support a second default directory
by Alexandre Julliard Aug. 21, 2007

Aug. 21, 2007

"Dan Kegel" <dank(a)kegel.com> writes: > @@ -1727,6 +1736,22 @@ INT WineEngAddFontResourceEx(LPCWSTR file, DWORD flags, PVOID pdv) > { > INT ret = AddFontFileToList(unixname, NULL, NULL, ADDFONT_FORCE_BITMAP); > HeapFree(GetProcessHeap(), 0, unixname); > + if (!ret && !strchrW(file, '\\')) { > + /* http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q100057 > + * suggests that in older versions of Windows, AddFontResource > + * paths were relative to %WINDIR%/Fonts instead of %WINDIR%/System > + * Retry assuming that's what went wrong. > + */ This comment is misleading, fonts are in WINDIR/fonts in all Windows versions, and we never look in WINDIR/system anyway. -- Alexandre Julliard julliard(a)winehq.org

2 1

How to Calling PE Dlls on linux??
by trulyliu Aug. 21, 2007

Aug. 21, 2007

hi: I am sorry to disturb you with a question about calling PE Dll on linux. This is really an old question. I found the sameness issues in mail list. http://www.winehq.org/pipermail/wine-devel/2003-December/thread.html http://www.winehq.org/pipermail/wine-devel/2005-November/thread.html#41917 http://www.winehq.org/pipermail/wine-users/2004-August/014685.html http://www.winehq.org/pipermail/wine-devel/2006-August/050619.html I have tried the ways discussed in these threads。 But it's not clear enough how to do this. So I send this mail to you for some help. I have a PE Dll named Arithmetic.dll which exports a function, it's prototype is: void sort(unsigned int*, int num) I want to call the function in my Linux App. I used winedump to generate a spec file winedump spec Arithmetic.dll This comand generated three files: Arithmetic_dll.h Arithmetic_main.c and Arithmeticspec. What's the next exactly step I should do? What's the usage of the three files? And wow could I use them? I made reference to mplayer's implementation, It's code is a little clutter， and I don't have experience on MS D-Show. Could you give me some simple sample codes ?? Best Regards. -- trulyliu(a)gmail.com

4 5

Re: [patch] Garbage code in text string display
by Guan Xin Aug. 21, 2007

Aug. 21, 2007

Q: Can you give a simple example of such a program (preferably downloadable)? A: Yes. If you have Simplified Chinese environment, you can try: http://update.cz88.net/soft/qqwry.rar which is a freeware for IP address-to-geographical address translation. Before patching WINE, most (though not all) labels and all buttons show garbage code. None after. Q:Can you add a conformance test showing that your patch is correct? A: I have tried editplus, acdsee, and gvim in en_US and zh_CN.GBK locale/encodings. They all ran well. I also tried the German version of winrar in de locale, no problem either. I don't think we need to prove this patch is correct because it is certainly wrong and introduced a bug. However, `any sufficiently advanced bug becomes a feature'. In the source code of Microsoft Windows NT/2k/XP, or to be excact, in the file "private/windows/shell/accesory/spechars/charmap.c" they confessed there is a bug in GDI that `assumes the font's default charset is always the system default locale'. I know peeking into The source code is illegal, but I've only done this some 24 hrs after I submitted this patch. So this patch has nothing to do with my undesirable deed. Xin On 8/19/07, Dan Kegel <dank(a)kegel.com> wrote: > Xin Guan wrote: > > This patch solves the problem that many MBCS programs display garbage code > > for text strings. Because most windows programmers do not handle charsets > > properly, we have to force DEFAULT_CHARSET in here. > > Can you give a simple example of such a program (preferably downloadable)? > > Can you add a conformance test showing that your patch is correct? > - Dan >

2 4

[Winetest RFI] What do you want out of the test suite?
by Paul Vriens Aug. 21, 2007

Aug. 21, 2007

Hi, I just want to get people's opinion(s) about the needs/requirements/whishes for both the conformance tests themselves (including winetest) as well as the webpages. I'll collect the information and will put it on the wiki. Cheers, Paul.

5 16

Re: [PATCH try2 2/5] wininet: Free handle structs in WININET_Release.
by Robert Shearman Aug. 20, 2007

Aug. 20, 2007

Misha Koshelev wrote: > This is necessary so that we send the INTERNET_STATUS_HANDLE_CLOSING before, for example > INTERNET_STATUS_CLOSE_CONNECTION gets sent from HTTP_CloseConnection in HTTP_CloseHTTPRequestHandle. > This can be tested on native/with native wininet on wine because although we do not send > INTERNET_STATUS_CLOSE_CONNECTION correctly when the data is finished reading on wine as native > does, if we simply don't read all the data (or any data, changing the while TRUE's to while FALSE's > in the InternetReadFiel_test for example in wininet/tests/http.c) then these do in fact get sent > as a response to InternetCloseHandle like they do on wine, and INTERNET_STATUS_HANDLE_CLOSING > always gets sent afterwards (last). > It seems like it would be better to add a close_connection method to go along with destroy, instead of leaving the handle in a half-destroyed state. Either that, or to not use INTERNET_SendCallback to send the callback in this case so that you don't have to have a WININETHANDLEHEADER object still around. -- Rob Shearman

2 1

Re: winefile: Save font settings for registry
by Dmitry Timoshkov Aug. 20, 2007

Aug. 20, 2007

"Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > Changelog: > this patch add opportunity to save font option to the regestry, and load font > option from regestry in the winefile program Nothing prevents you from writing and reading the whole LOGFONT structure in one go. -- Dmitry.

1 0