September 2004 - Wine-devel

Darwine Display Driver
by Nikolas Dahn 04 Sep '04

04 Sep '04

Hi there everybody! First of all i have to admit that im quiet useless in coding, im just a user with _minimal_ programing knowledge, so this might sound like trash which we all should forget as soon as we can ;) When reading the article about porting wine to mac os and the related difficulties it came into my mind to create a borderless x window (best of all just the content) and have carbon/cocoa create an empty window with borders where the x-content is linked and centered to (similar to an bordered control-layer i think). I dont know how to do this or whether it is even possible, but for me it sounds some kind of logical... oO if this isnt the fact, just ignore me :) Cheers Nikolas Dahn -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

1 0

Re: ADVAPI32: preserve the last error value set by the CSP in CryptAcquireContext
by Robert Shearman 04 Sep '04

04 Sep '04

Mike McCormack wrote: > > ChangeLog: > * preserve the last error value set by the CSP in CryptAcquireContext > >------------------------------------------------------------------------ > >Index: dlls/advapi32/crypt.c >=================================================================== >RCS file: /home/wine/wine/dlls/advapi32/crypt.c,v >retrieving revision 1.51 >diff -u -r1.51 crypt.c >--- dlls/advapi32/crypt.c 30 Aug 2004 23:57:18 -0000 1.51 >+++ dlls/advapi32/crypt.c 4 Sep 2004 01:09:44 -0000 >@@ -476,6 +476,8 @@ > } > /* FALLTHROUGH TO ERROR IF FALSE - CSP internal error! */ > error: >+ /* must preserve the last error returned by the CSP here */ >+ r = GetLastError(); > if (pProv) > { > FreeLibrary(pProv->hModule); >@@ -486,6 +488,7 @@ > CRYPT_Free(provname); > CRYPT_Free(temp); > CRYPT_Free(imagepath); >+ SetLastError( r ); > return FALSE; > } > > This seems wrong. Which function is calling SetLastError? I believe there was a problem a while ago with freeing bad pointers. I can't remember whether a fix went in for that. Rob

2 1

WinInet and doubtful assertion in FTP_Connect
by Krzysztof Foltman 04 Sep '04

04 Sep '04

For some reason, FTP connections in WININET crash on assertion: assert( hIC->hdr.htype != WH_HINIT ); However, it seems the assertion is either wrong, or confusing (if its intention was to point out that FTP code is unimplemented). FTP_Connect is called from two places, InternetConnectW and InternetOpenUrlW. As for InternetConnectW, it won't call FTP_Connect unless htype is set to WH_HINIT. As for InternetOpenUrlW, I'm not sure what htype does it expect. However, it's supposed to use HINTERNET handles coming out of InternetOpen, which sets htype to WH_HINIT. After changing != to ==, InternetConnect works (to a degree). Don't know about InternetOpenUrl, but theoretically it should too. Chris

1 0

(no subject)
by Pablo Szuster 04 Sep '04

04 Sep '04

Hi, i´m trying to access a MSSQL server (in a windows machine in the network) from a Visual Basic Application running under wine, using an ODBC driver. Since there aren´t any MSSQL drivers for linux i decided to use de native ones, so i installed mdac_typ.exe . Then i configured the DSN using odbcad32.exe but when i tested the connection (configured using tcp/ip) an error message appeared ("[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets] General network error. Check your network documentation"). Do i have to install some network drivers for wine?? Has anyone been able to connect to a MSSQL server remotely using odbc under wine?? __________________________________________________ Todavía no tenés tu Ciudad Internet Mail? Obtenelo ahora! - http://webmail.ciudad.com.ar Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software para actualizar tu PC. http://www.ciudad.com.ar/ar/servicios/ie/

2 1

Re: Wine and industrial communication like OPC
by Juan Lang 04 Sep '04

04 Sep '04

Mike (at yet another email address) wrote: > Wines sockets support is good though, far better > than its builtin DCOM. Based on what I know of the > DCOM network protocol, I don't think we'd have any > problems with it. I can think of a couple, but they may be able to be worked around: - incoming connections (DCOM servers) won't be supported. If this guy's clients are going with WinCE that won't be an issue, it doesn't support them either AFAIK. - only DCOM over TCP is likely to be supported. DCOM over named pipes definitely wouldn't be. --Juan _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

5 7

Re: Wine Emulation: Swapping functions
by Alexandre Julliard 04 Sep '04

04 Sep '04

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Hi Alexandre, > > This patch allows to load a PE exe to memory. You may notice that > there is no "mass" byte swapping. The technics used here is a bit > developer here: > http://stegefin.free.fr/wine/ > You might prefer a more conventional way of doing the byte swapping, > in this case tell me. We might still need this approach since it could > efficient for sharing data accross the LE exe and the BE winelib. It doesn't seem very efficient to trap on every memory access... Besides, I don't see how this can possibly work, there is no guarantee that the compiler is going to generate accesses that always match the size of the requested type, memcpy() being the obvious example. I think you are going in the wrong direction with this; the right way IMO is to compile Wine for x86 and run the whole Wine+app under the CPU emulator. Otherwise you'll have to write wrappers for each of the 15,000 APIs. -- Alexandre Julliard julliard(a)winehq.org

7 21

problem in using Winelib
by gupta.lokesh＠philips.com 03 Sep '04

03 Sep '04

Hi, I have been trying to use Winelib to build a very trivial Windows Application on Unix just to test the working of winelib. But it does not work according to the documentation at all. Here are the problems I found: - When I run winemaker in my project root directory, it runs successfully but in the end does not produce any configure script as said in the documentation but produces directly a Makefile - The Makefile must be manually tweaked to put in the WINE include files path and the WINE libraries path. - After changing the generated Makefile, when I run it, I see thousands of warnings related to ignoring of __stdcall__ attribute in some of the windows header files, but the build goes through - The generated executable always has a .so extension which gives a feeling that it is a shared library rather than an executable - When I run the above generated file, it simply dumps core without any messages "Segmentation Fault" - When I try to run the above application through GDB to debug it, it crashes even before reaching main - When I try to run the above application through winedbg to debug it, it simply hangs, nothing happens after that. If such a basic thing does not work with Winelib, then I hope that something is wrong with the way I have understood things and in my process of trying to do this. Can somebody help ?? By the way, the same kind of setup also did not work on Linux/Intel and Linux/Athlon combinations as well. So there must be something very wrong in the way I am doing it. I imagine that the Winelib user's guide documentation is totally out of date, in which case could somebody please forward me a document which can produce working executables. Best Regards Lokesh

2 1

Re: listview
by Rein Klazes 03 Sep '04

03 Sep '04

On Thu, 2 Sep 2004 17:28:31 -0400, you wrote: > ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Handle WM_BUTTONDOWN operations before dragging test > Don't eat WM_LBUTTONUP message > > Index: dlls/comctl32/listview.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/listview.c,v > retrieving revision 1.393 > diff -u -r1.393 listview.c > --- dlls/comctl32/listview.c 25 Aug 2004 17:33:01 -0000 1.393 > +++ dlls/comctl32/listview.c 2 Sep 2004 21:21:32 -0000 > @@ -7927,6 +7927,7 @@ > else if (msg.message >= WM_LBUTTONDOWN && > msg.message <= WM_RBUTTONDBLCLK) > { > + DispatchMessageW(&msg); > break; > } This was discussed before. The problem here is that Windows/native comctl32 *does* eat the WM_LBUTTONUP message ending the mouse track. The reason why you miss the WM_LBUTTONUP message is that mouse tracking is started wrongly under Wine. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

RE: Protected message
by Mike 03 Sep '04

03 Sep '04

1 0

OLE Problem?
by Adriano Bonat 03 Sep '04

03 Sep '04

Hello, im trying to run a program, but appear this error message: Invoking /usr/lib/wine/wine.bin SVLGER.EXE ... fixme:ole:CoRegisterMessageFilter stub fixme:ole:GetRecordInfoFromGuids (0x40b8e0,2,12,0,0x40b8f0,0x4465e8),stub! fixme:ole:CoRegisterMessageFilter stub Wine exited with a successful status Im using Debian, and configured Wine with Winetools, the software that im trying to run is a ERP build with VB in Windows NT. Any appointment of the patch for this problem? Thanks in advance, -Adriano Bonat

1 0