wine-devel April 2004

wine-devel@winehq.org

138 participants
323 discussions

Re: ShellExecute IE compatibility problems
by Martin Fuchs 09 Apr '04

09 Apr '04

On 09.04.2004 02:03:37 Francois Gouget wrote: > > This patch fixes two IE compatibility problems. > > The first one is a mundane issue. IE calls ShellExecuteEx with a NULL > verb. Our implementation fails when it should use some sophisticated > algorithm described in the MSDN to choose a default verb. Well most of > the time we just want 'open' anyway so that's what this patch does. I've > left it as an exercise to the reader to head over to the MSDN and > implement the series of fallbacks we're supposed to implement. This is what SHELL_FindExecutable() tries to do when enumerating the registry keys. What is wrong with that - doesn't this work for you? I don't think we should go back and use "open" again if the verb parameter is NULL. Please correct the current algorithm, if it's not fully compliant. Regards, Martin

1 0

Re: Workaround a SoundBlaster 16 OSS bug
by Andreas Mohr 09 Apr '04

09 Apr '04

Hi, On Fri, Apr 09, 2004 at 02:27:19AM +0200, Francois Gouget wrote: > Note: AFAIK Andreas' kernel patch has never been applied :-( In fact it has been, fortunately, just about two weeks ago... By Andreas Kies in 2.4.26-pre3. He'd already patched 2.6.x a bit earlier. I've been trying to get the slightest bit of attention about that DoS at that time, but after two very detailed fruitless mails to LKML, I just gave up: http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.0/0087.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.2/0033.html Andreas Kies told me that it seemed that they now cared a slight wee bit more about small fringe problems such as DoSes in 2.4.x... </sarcasm> > (now you know how to mount a DOS on these systems!) Ow, watch your words! This can be VERY easily misinterpreted as mounting a DOS partition somewhere!? (in fact I did fall for it the first couple of seconds) > Patch the fragment size if it does not match the current sound > format. This saves us from trigerring a kernel freeze on some OSS 2.4 + > SounBlaster 16 systems. Crap, I thought I'd sent a Wine patch at that time; it would have been the easiest thing to do. Anyway, glad to see it fixed now. Greetings, Andi (been finishing my wireless driver any single day for about 5 months now :))

2 1

Re: Regression
by Ivan Leo Murray-Smith 08 Apr '04

08 Apr '04

> Tried to install on an updated (like 45 min old) CVS version to test it, > seems to get in an endless loop here. Alexandre committed a fix http://www.winehq.com/hypermail/wine-cvs/2004/04/0095.html Everything seems OK again, and hopefully will stay so. Ivan.

2 1

Re: Regression
by Ivan Leo Murray-Smith 08 Apr '04

08 Apr '04

> Tried to install on an updated (like 45 min old) CVS version to test it, > seems to get in an endless loop here. You're wright, it loops :( Ivan.

1 0

Re: Re: inheriting exec-shield avoidance
by chmorgan＠charter.net 08 Apr '04

08 Apr '04

Any idea when the kernel and wine changes will be going in? Then we can start asking people with Fedora to disable exec-shield and prelinking OR upgrade to kernel 2.6.X and the latest wine. There are people everyday that come onto #winehq with problems due to prelinking/exec-shield. Thanks, Chris > > From: "Dimitrie O. Paun" <dimi(a)intelliware.ca> > Date: 2004/04/08 Thu PM 03:10:35 EDT > To: Mike McCormack <mike(a)codeweavers.com> > CC: Peter Riocreux <par+wine_devel(a)silistix.com>, <wine-devel(a)winehq.org> > Subject: Re: inheriting exec-shield avoidance > > On Thu, 8 Apr 2004, Mike McCormack wrote: > > > I've attached the source code. The idea is to run it like this: > > > > wld /home/mike/wine/loader/wine-pthread my.exe > > Cool. One small nit: for consistency, can we name it wineld instead? > Or is it winepreld more apropriate? I'm thinking that wineld will > seem to be the counterpart of winegcc... > > -- > Dimi. > > > >

1 0

RE: Status of TAPI
by Robert van Herk 08 Apr '04

08 Apr '04

> This (dutch..) site provides some TAPI patches for Wine that are not > in CVS: > http://home.wanadoo.nl/wijn/girotel/ > > Since I'm dutch, I'd thought I'd explain a bit on what this site says. Wijn is dutch for wine by the way . The site explains how to patch wine in order to be able to use girotel software. Girotel is a telebanking system using dail up by modem that was quite popular a few years ago. Anyway, now-a-days most people use Internet for telebanking, not dail up modem. Although the site for that specific bank is not mozilla compatible , it can be used from Konqueror. The patches seems to be specially suited in order to use this Girotel system. Greetings, Robert

1 0

Status of TAPI
by Andreas Rosenberg 08 Apr '04

08 Apr '04

Hi guys! I'd like to run a TAPI based application in Wine (updated from CVS today). I extracted the vendor specific TAPI driver and the registry keys and included both into a Wine setup. Then I tried to do setup the TAPI driver using the telephon.cpl (taken from Win98): wine rundll32.exe shell32.dll,Control_RunDLL telephon.cpl first I had a problem with the Wine implementation of the TAPI32.DLL. err:module:import_dll No implementation for TAPI32.dll.internalConfig imported from L"C:\\windows\\system\\telephon.cpl", setting to 0xdeadbeef ... No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TELEPHON.CPL' (0x75a70000) Unhandled exception: page fault on read access to 0xdeadbeef in 32-bit code (0x404c5b7e). who had dug in that DEAD BEEF? ;-) Then I took the TAPI32.DLL from a Win98 installation. This gave me another error: fixme:ole:RpcServerRegisterAuthInfoA ((null),10,(nil),(nil)): stub fixme:seh:EXC_RtlRaiseException call to unimplemented function rpcrt4.dll.NdrClientCall (last message repeated several times). At last I took the rpcrt4.dll from a Windows98 installation and tried it again. Then it took quite a time (~15 sec) until the Wine debugger came up. wine rundll32.exe shell32.dll,Control_RunDLL telephon.cpl wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 8 Can't find file for ELF 'wine-kthread' ((nil)) Loaded debug information from ELF 'wine-pthread' ((nil)) Breakpoint 1 at 0x4000dd60 (_end+0x3fefb8d0) Loaded debug information from ELF '/usr/local/lib/libwine.so.1' (0x40028000) No debug information in ELF '/lib/i686/libpthread.so.0' (0x40040000) No debug information in ELF '/lib/i686/libc.so.6' (0x40091000) No debug information in ELF '/lib/libdl.so.2' (0x401c4000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' (0x401c8000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' (0x40238000) No debug information in ELF '/lib/i686/libm.so.6' (0x4032b000) Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' (0x40460000) Loaded debug information from ELF '/usr/local/lib/wine/rundll32.exe.so' (0x405a2000) Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' (0x406c0000) Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' (0x407f8000) Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' (0x40878000) No debug information in ELF '/usr/lib/libfreetype.so.6' (0x408b7000) No debug information in ELF '/usr/lib/libfontconfig.so.1' (0x4090d000) No debug information in ELF '/usr/lib/libexpat.so.0' (0x40935000) Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' (0x40955000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x4001c000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x409d3000) No debug information in ELF '/usr/X11R6/lib/libXrandr.so.2' (0x405b6000) No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x409ea000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x409f2000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40a00000) No debug information in ELF '/usr/lib/tls/libGL.so' (0x40afc000) No debug information in ELF '/usr/lib/tls/libGLcore.so.1' (0x40b67000) No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' (0x410e4000) Unsupported debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x40025000) Unsupported debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x41131000) No debug information in ELF '/usr/lib/gconv/ISO8859-1.so' (0x408a9000) Loaded debug information from ELF '/usr/local/lib/wine/imm32.dll.so' (0x41150000) Loaded debug information from ELF '/usr/local/lib/wine/shell32.dll.so' (0x4116e000) Loaded debug information from ELF '/usr/local/lib/wine/ole32.dll.so' (0x411f6000) Loaded debug information from ELF '/usr/local/lib/wine/shlwapi.dll.so' (0x4126a000) Loaded debug information from ELF '/usr/local/lib/wine/comctl32.dll.so' (0x412c1000) No debug information in 32bit DLL 'C:\windows\system\rundll32.exe' (0x405b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x401e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40490000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40890000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40810000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40970000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IMM32.DLL' (0x41160000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x7fb90000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x41210000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x41280000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x412d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x41190000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSVCRT.DLL' (0x78000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TAPI32.DLL' (0x7f960000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TELEPHON.CPL' (0x75a70000) Unhandled exception: page fault on read access to 0xda62061d in 32-bit code (0x401f999a). In 32-bit mode. 0x401f999a (RtlpWaitForCriticalSection+0x6a [critsection.c:204] in NTDLL.DLL): movl 0x1c(%eax),%eax 204 if ((!crit->DebugInfo) || (!crit->DebugInfo->Spare[1])) continue; The wait time could be an indication that a timeout happened. Anybody has a clue what could be the problem? Regards Andy

4 5

Re: MSYS's sh.exe has trouble reading from stdin on Wine?
by Pouech Eric DMI AEI CAEN 08 Apr '04

08 Apr '04

> wine --debugmsg +all -- sh.exe - does wineconsole -- sh.exe - work ? I fear it's the same old pb of not mapping win32 console semantics on standard unix files without winconsole (anyway, check for the CreateFile which returns 0xffffffff, likely on $CONIN) A+

1 0

MSYS's sh.exe has trouble reading from stdin on Wine?
by Dan Kegel 08 Apr '04

08 Apr '04

Someone's having trouble building my crosstool on msys, so I tried installing msys on my Wine (a home-built 20040213). (This is slightly less crazy than installing Cygwin, I think, but it's still a pretty hard test, I bet.) The installer http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download ran just fine until it tried to run the postinstall shell script. Turns out running msys's sh.exe hangs. Running it with wine --debugmsg +all -- sh.exe - and waiting until the output settles into an infinite repeat, I see the repeating section is 0009:Call kernel32.WaitForSingleObject(00000084,0000000a) ret=7105f927 0009: select( flags=12, cookie=0x4060eea8, timeout=1081401202.858741 (+0.009956), handles={0x84} ) 0009: select() = PENDING 0009: *wakeup* signaled=258 cookie=0x4060eea8 0009:Ret kernel32.WaitForSingleObject() retval=00000102 ret=7105f927 0009:Call ntdll.RtlEnterCriticalSection(710a8b0c) ret=71070c98 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=71070c98 0009:Call ntdll.RtlLeaveCriticalSection(710a8b0c) ret=71070cb0 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=71070cb0 0009:Call kernel32.PeekConsoleInputA(ffffffff,4060f150,00000001,4060f12c) ret=7105687a 0009: read_console_input( handle=0xffffffff, flush=0 ) 0009: read_console_input() = OBJECT_TYPE_MISMATCH { read=-1, rec={} } 0009:Ret kernel32.PeekConsoleInputA() retval=00000000 ret=7105687a 0009:Call ntdll.RtlEnterCriticalSection(710a8b0c) ret=71070c98 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=71070c98 0009:Call ntdll.RtlLeaveCriticalSection(710a8b0c) ret=71070cb0 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=71070cb0 0009:Call kernel32.WaitForSingleObject(00000084,0000000a) ret=7105f927 So it kind of looks like it's having trouble reading from stdin? Can someone have a look? It'd be so awesome to be able to run msys on Wine... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: abnt2 keyboard
by Dmitry Timoshkov 08 Apr '04

08 Apr '04

"Rafael аvila de EspМndola" <rafael.espindola(a)ic.unicamp.br> wrote: > The attached patch fixes the problem that wine has with the abnt2 (Brazilian) > keyboard. The problem was recently discussed in wine-devel. If you still can't provide more arguments as on wine-devel I don't see a reason why the patch can be accepted. Especially taking into account that the patch contains magic numbers without a little bit of explanation what they are. > While reading dlls/x11drv/keyboard.c I notice that wine does a linear search > to convert a virtKey to a keycode. Could this be optimized/simplified by > pre-computing a vkey2keyc[(e->state & NumLockMask)!=0] table? Feel free to send a patch. -- Dmitry.

1 0

[Fwd: DSD_CreateSecondaryBuffer]
by Robert Reif 08 Apr '04

08 Apr '04

sorry, wrong reply button again.

1 0

DSD_CreateSecondaryBuffer
by Daniel Skorka 07 Apr '04

07 Apr '04

Hi, said function is a stub in Wine-20040309. Is anyone working on implementing it? If not, any pointers on doing so, especially on how this fuction differs from DSD_CreatePrimaryBuffer? Thanks, Daniel Skorka

1 0

Regression
by Ivan Leo Murray-Smith 07 Apr '04

07 Apr '04

This patch http://www.winehq.com/hypermail/wine-cvs/2004/03/0434.html breaks the decompression system used by lots of microsoft software, a screenshot is attached. This breaks the installer of the word 97 viewer, and probably of all office viewers, and it may affect dcom and the installer of other Windows components or Microsoft software. This should be fixed before the next release. The CVS regression testing was done with the word viewer available at http://www.microsoft.com/downloads/details.aspx?FamilyID=9bbb9e60-e4f3-436d… Ivan.

2 1

Re: Documentation: Clarified need for conformance tests.
by Francois Gouget 07 Apr '04

07 Apr '04

On Wed, 7 Apr 2004, Michael Jacobsen wrote: > Hi there. This is my first go at submitting a patch. Let's see if it works. It needs a small s/avalible/available/ and it would be nice to follow the 2-space indentation used in the rest of the doc. Besides that it looks good. Thanks for your contribution. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

article
by Pouech Eric DMI AEI CAEN 07 Apr '04

07 Apr '04

read on from lwn.net http://www-106.ibm.com/developerworks/linux/library/l-wine/?ca=dgr-lnxw04Fi…

1 0

Virus on wine-patches@winehq.org
by Rolf Kalbermatter 07 Apr '04

07 Apr '04

Could someone please remove the following postings from the archive as they contain viruses? http://www.winehq.org/hypermail/wine-patches/2004/04/0082.html http://www.winehq.org/hypermail/wine-patches/2004/04/0084.html Rolf Kalbermatter

3 2

Re: development speed
by Ivan Leo Murray-Smith 07 Apr '04

07 Apr '04

> The website stats are interesting too: Are these available somewhere? Ivan.

2 1

arch tip #1
by Mike Hearn 07 Apr '04

07 Apr '04

At Dimis request, I've added a new script to the root of the gateway tree. The genpatch program takes a series of patch ids as parameters and can generate and send an email to wine-patches with the combined diff of all the given commits. For example: let's say you are working on a feature. You do 3 commits, to keep the changes physically separate, however you decide the commits are too fine grained to submit all at once, so you want to submit them together. Genpatch makes that easy. Say you commit patch-4, patch-5 and patch-6: ./genpatch -m 4 5 6 will compute the combined differential of all those commits, take the commit log and summary of the first and generate an email from them. The patch will include and new files that were added. Have fun! thanks -mike

1 0

Re: wine/ include/config.h.in dlls/x11drv/xrandr.c ...
by Mike Hearn 07 Apr '04

07 Apr '04

On Tue, 06 Apr 2004 22:57:36 -0500, Alexandre Julliard wrote: > Log message: > Mike McCormack <mike(a)codeweavers.com> > Load the XRandR extension dynamically (with help from Alex Pasadyn). Are we sure this is a good idea? Dynamic version of the X extension libraries are not available on every distro, as traditionally XFree has shipped them statically. I'm not even sure they have stable interfaces. It seems wiser to just statically link libXrandr, seeing that it's only 7.7k

1 0

Window management thoughts
by Mike Hearn 07 Apr '04

07 Apr '04

So, me and Mike have been discussing some ideas for window management in Wine. Currently it hasn't turned into code, but I thought I'd write up what our thoughts were so others could comment and maybe be inspired to write patches. The problem: Currently Wine decides whether to make a window managed or not based on a series of heuristics, in is_window_toplevel in dlls/x11drv/window.c Unfortunately these heuristics are frequently wrong, as they have only limited information to work with (window styles, mostly). In CrossOver, is_window_toplevel is easily the most hacked function in the entire codebase. This manifests itself in a variety of ways: * Windows are marked unmanaged when they shouldn't be. For instance, see WinAmp, Trillian, the Counter-Strike CD Key screen etc: there are tons of examples of this problem. This at best means the window is "nailed" to the screen, at worst it makes the program unusable. * The classic "my game starts but I can't type" problem where keyboard input goes to the terminal instead of the window, due to the lack of focus management in unmanaged windows. * Some programs display splash screens and then pop up errors or question dialogs underneath them. Unmanaged windows are always-on-top -> you cannot get to the underlying managed window and the app appears to hang. * Fullscreen windows are really hard to do properly because they must be managed to work correctly in KDE/GNOME. We currently make certain windows unmanaged typically because we need to control their position or rendering with a high degree of accuracy. Unfortunately some X window managers ignore positioning hints, even when we ask them not to. There is no way to make things like menus and tooltips work correctly with these WMs, so we take the window out of the usual window management mechanism entirely. Unfortunately due to the design of the win32 API there is no simple way to tell the difference between a large menu and the Trillian main window. We could mark our own menus specially to make them unmanaged and have everything else be managed, but we then run into problems with programs that draw their own menus and tooltips, of which there are a truly shocking number. So what is a possible solution? Well, one way forward is to implement another mode, in which Wine makes all windows managed and uses a variety of WM hints to get the desired behaviour. For instance, the PPosition flag asks the WM to place the window where the application requests it to. Some WMs respect this, others do not, in yet others it's a toggleable option. For people with WMs that meet the requirements of Wine all windows could be made managed, and for people that don't use such WMs the old way can still be used. IIRC it's possible to ask the WM for identification which means this setting could be largely autodetected by having blacklists of WMs to use the old mode for (or vice-versa). Unfortunately there's no way to know how well this approach would work, or even if it would work at all, short of trying it. thanks -mike

5 6

Re: Re: wineserver: correctly free the debug ctx
by Pouech Eric DMI AEI CAEN 07 Apr '04

07 Apr '04

> It seems to me this will cause the context to never be freed. I don't > understand the problem with multiple processes, the context is bound > to the debugger thread so it shouldn't make any difference how many > processes are being debugged. Could you please give more details on > the problem? well, problem (sigsev in wineserver) happened when quitting windbg after debugging several processes. I'll try to reproduce it over this weekend. A+

1 0

Re: Game support
by James Perry 07 Apr '04

07 Apr '04

Sorry, meant to send this to the list first time around... >> But I narrowed it down to 3 Wine calls in the >> critical loop: SetEvent, WaitForSingleObject and ResetEvent. >> I tried wrapping each of these functions with >> __asm__("pushfl\n"); at the start and __asm__("popfl\n"); at >> the end to preserve the flags - with this, PECrypt works >> fine and the game gets as far as trying to initialise >> DirectX. Not exactly a neat fix though. > > > Did you have to do all of them, or is it just one function that needs this > treatment? SetEvent definitely needs it. The others possibly don't. But I think it would be more robust to preserve the flag through all of them anyway, in case someone makes a change in future that causes one of the others to clear the direction flag too, which seems quite possible. > Are you sure it's not that we need to set the flag before > jumping to the entrypoint? The flag is normally cleared. PECrypt sets it explicitly, then expects it to remain set across those three API calls. > PECrypt sounds like it should run very early on > in the programs lifetime: how much stuff does it do before hitting this > bug? AFAIK, PECrypt just decrypts and decompresses the executable at startup, then it goes away and the program runs as normal. This bug does happen very early on. > If there is really widespread software that depends on > this behaviour though there is precedent for including a hack for it - see > the DllMain wrapper which preserves %ebx for an example. Certainly anything compressed with PECrypt will depend on the flag being preserved. In general I'd imagine it's quite rare for programs to run with the direction flag set for long periods though. Cheers, James

1 0

ole32.dll_CoRegisterPSClsid
by Paul Ortyl 06 Apr '04

06 Apr '04

Hi, If only ole32.dll.CoRegisterPSClsid() is implemented (empty stub returning '1' is enough) then the application "GeoGeogrid® for Windows©" starts and allows at least some basic operations. (tested with "Baden-Würtemberg AMTLICHE TOPOGRAPHISHE KARTEN" Top50, Version 4) For more info on GeoGrid you may look at: http://swpat.ffii.org/patents/effects/geogrid/index.en.html http://www.eads.net/frame/lang/en/xml/content/OF00000000400004/4/20/534204.… Basically all official topographical maps in Germany are available only through this proprietary application. It would be really useful if ole32.dll.CoRegisterPSClsid() could be implemented in (next) release... TIA Paul Ortyl -- Don't take life too seriously; you will never get out of it alive. -- Elbert Hubbard

1 0

AbiWord on ReactOS
by Steven Edwards 06 Apr '04

06 Apr '04

Note there are still a few minor bugs but for the most part it seems we have a real application working on ReactOS. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

Re: WININET: move to Windows sockets
by Juan Lang 06 Apr '04

06 Apr '04

> Geoff wrote: > > Or we write our own BIO that wraps up whatever > > glue is desirable on the wine-side. Worst-case > > (and it's not that bad an alternative) is that > > you use a memory-base BIO to encapsulate all I/O > > and worry about moving data to and from "sockets", > > whatever they look like, afterwards. > > That's what I've always done. <snip> > So it's not a bad way to go at all. Yep, in fact the "real" way to do this as far as Wine is concerned is to implement SSL in secur32.dll, since this is where Windows does it. It looks about like this, although as Geoff pointed out to me the API is a bit broken. Doing a BIO inside wininet.dll might be more expedient for Hans, who I think is trying to get as much of Wine as possible ported to MinGW. You guys that know SSL better than I do: patches welcome :) --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2004