wine-devel

wine-devel@winehq.org

4 participants
84464 discussions

Re: wine/dlls Makefile.in rpcrt4/Makefile.in rpcrt ...
by Greg Turner 11 Oct '02

11 Oct '02

On Thursday 10 October 2002 06:36 pm, Alexandre Julliard wrote: > ChangeSet ID: 5742 > Patch: http://cvs.winehq.com/patch.py?id=5742 >--- wine/dlls/Makefile.in:1.155 Thu Oct 10 23:54:58 2002 >+++ wine/dlls/Makefile.in Thu Oct 10 23:54:58 2002 >@@ -821,7 +821,7 @@ > quartz: kernel32.dll$(DLLEXT) > rasapi32: kernel32.dll$(DLLEXT) > richedit: user32.dll$(DLLEXT) kernel32.dll$(DLLEXT) >-rpcrt4: kernel32.dll$(DLLEXT) >+rpcrt4: advapi32.dll$(DLLEXT) kernel32.dll$(DLLEXT) > serialui: user32.dll$(DLLEXT) advapi32.dll$(DLLEXT) kernel32.dll$(DLLEXT) > setupapi: user32.dll$(DLLEXT) advapi32.dll$(DLLEXT) kernel32.dll$(DLLEXT) ntdll.dll$(DLLEXT) > shdocvw: ole32.dll$(DLLEXT) kernel32.dll$(DLLEXT) > >Index: wine/dlls/rpcrt4/Makefile.in >diff -u wine/dlls/rpcrt4/Makefile.in:1.15 wine/dlls/rpcrt4/Makefile.in:1.16 >--- wine/dlls/rpcrt4/Makefile.in:1.15 Thu Oct 10 23:54:58 2002 >+++ wine/dlls/rpcrt4/Makefile.in Thu Oct 10 23:54:58 2002 >@@ -4,7 +4,7 @@ > SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = rpcrt4.dll >-IMPORTS = kernel32 >+IMPORTS = advapi32 kernel32 > EXTRALIBS = $(LIBUUID) > > LDDLLFLAGS = @LDDLLFLAGS@ Alexandre, thank you for continuing to make up for my ignorance of the inner workings of the makefiles! Amongst other things, I noticed that instead of IMPORTS += ntdll, you did EXTRALIBS = ($LIBUUID). So, this makes me wonder, how on earth does one know what all these dependencies are? It's all-too-easy to suck in some .h file and call methods without knowing what dll dependencies you've really created... and unfortunately, the darn thing seems all-too-happy to compile despite this. Is there, aside from "just knowing," or tracing down API's one-by-one, a task which isn't always obvious to me anyhow, a systematic way to check for broken dll dependencies? I also presume there are some rules about what is allowed to depend on what, which I also don't know... I'd rather not create superfluous work for you because I don't know what I'm doing, so I figure it's time to educate myself, especially if I plan to go beyond just feeding you patches from Ove. Thanks, -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

2 2

Re : wine/programs/wcmd wcmdmain.c
by Sylvain Petreolle 10 Oct '02

10 Oct '02

> Log message: > Try CreateProcess even if SHGetFileInfo fails so that we can > launch Unix binaries. Isn't that dangerous ? A windows program could gain access to some commands that shouldn't launch into normal windows. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

6 6

MZ_Exec() patch, try 2
by chrismorgan＠rcn.com 10 Oct '02

10 Oct '02

This look more reasonable? Thanks, Chris * dlls/winedos/module.c: Chris Morgan <cmorgan(a)alum.wpi.edu> Call CreateProcessA() when executing non-dos applications from a dos application. Index: dlls/winedos/module.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.21 diff -u -r1.21 module.c --- dlls/winedos/module.c 30 Aug 2002 00:03:25 -0000 1.21 +++ dlls/winedos/module.c 10 Oct 2002 22:08:48 -0000 @@ -339,17 +339,68 @@ /*********************************************************************** * MZ_Exec + * + * this may only be called from existing DOS processes */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { - /* this may only be called from existing DOS processes - * (i.e. one DOS app spawning another) */ - /* FIXME: do we want to check binary type first, to check - * whether it's a NE/PE executable? */ + DWORD binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + HANDLE hFile = CreateFileA( filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); BOOL ret = FALSE; + + if(!GetBinaryTypeA(filename, &binType)) /* determine what kind of binary this is */ + { + return FALSE; /* binary is not an executable */ + } + if (hFile == INVALID_HANDLE_VALUE) return FALSE; + + /* handle non-dos executables */ + if(binType != SCS_DOS_BINARY) + { + if(func == 0) /* load and execute */ + { + BYTE fullCmdLine[512]; + LPBYTE psp_start = (LPBYTE)((DWORD)DOSVM_psp << 4); + PDB16 *psp = (PDB16 *)psp_start; + ExecBlock *blk = (ExecBlock *)paramblk; + LPBYTE cmdline = PTR_REAL_TO_LIN(SELECTOROF(blk->cmdline),OFFSETOF(blk->cmdline)); + LPBYTE envblock = PTR_REAL_TO_LIN(psp->environment, 0); + BYTE cmdLength = cmdline[0]; + cmdline[cmdLength + 1] = 0; /* null terminate and remove the \r at the end */ + cmdline++; /* the first character contains the length of the command line */ + + snprintf(fullCmdLine, sizeof(fullCmdLine), "%s %s", filename, cmdline); /* build the full command line */ + + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, fullCmdLine, NULL, NULL, TRUE, + 0, envblock, NULL, &st, &pe); + + /* wait here until the child process is complete */ + WaitForSingleObject(pe.hProcess, INFINITE); + + /* clean up PROCESS_INFORMATION handles */ + CloseHandle(pe.hProcess); + CloseHandle(pe.hThread); + + ret = TRUE; + } else + { + FIXME("EXEC type of %d not implemented for non-dos executables\n", func); + ret = FALSE; + } + + CloseHandle(hFile); + return ret; + } /* if(binType != SCS_DOS_BINARY) */ + + /* handle dos executables */ switch (func) { case 0: /* load and execute */ case 1: /* load but don't execute */

1 0

Re: Scrollbar clean up part 1
by Alexandre Julliard 10 Oct '02

10 Oct '02

"Andrew M. Johnston" <johnstonam(a)logica.com> writes: > This interim patch will do a little more drawing than is strictly necessary. > (I hear what you asked re not changing names of things but in the interest of > producing something this version does make the structure names lower case > as is common else where and hence there are some irrelevant changes in > SCROLL_GetScrollBarRect) I still don't see much reason for renaming these things, but if you really want to do it, again a separate patch with just that change would be nicer. Also if you could avoid changing all the indentation it would make it a lot easier to see the real changes. Your patch breaks the scrollbars in notepad for me, but there are so many irrelevant differences that finding the bug is a lot more painful than it should be. -- Alexandre Julliard julliard(a)winehq.com

2 2

Load .so error
by Fabian Cenedese 10 Oct '02

10 Oct '02

Hi I already managed to load a .so recently but I can't get it to work on my new PC. The Windows dll was MyDll.dll which I turned now into a .so. ELF_LoadLibraryExA is looking for a libMyDll.so but returns with error=2. I couldn't find out what this error means. I have my .so with same spelling and case in various places (local to exe, windows\system, /usr/lib, /usr/local/lib) but nothing helped. I take it that this is a Linux problem and not from wine. Maybe something with rights? Thanks bye Fabi

3 4

Using a DLL from a linux shared lib
by Descalzi Carlos 10 Oct '02

10 Oct '02

Hi. I'm trying to use a DLL from a linux shared lib and i'm having the next error in the initialization: err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000!

2 1

focus and auto-raise
by Thorsten Kranzkowski 10 Oct '02

10 Oct '02

Hello! We're running quite successful the Lotus Notes Client under wine here. However there's one entry on my wishlist: Would it be possible to teach wine to _not_ auto raise windows when they get focus? We're using wine in managed mode so that it is possible to use several desktops etc. We prefer to use focus-when-mouse-enters-window mode but without automatically raising the windows. Unfortunately wine raises itself when it's getting focus. This leads to some undesireable effects like garbled popup-windows (when focus switches for the fraction of a second to the underlying main window - not much but enough to redraw the background) or oscillations (two main windows are on top of each other, due to 'lucky' timing and not being able drawing fast enough the lower window gets focus - so it gets raised and during drawing the new lower one gets focus ...) These effects are greatly reduced by using click-to-focus mode, but we don't want that :-) BTW: Many thanks for working printer support! Bye, Thorsten PS: please CC: me on reply -- | Thorsten Kranzkowski phone: +49 5402 9844-32 fax: -99 | | CCE Systemhaus GmbH & Co. KG office: tkranzkowski(a)cce.de | | Gewerbepark 18, D-49143 Bissendorf private: dl8bcu(a)dl8bcu.de |

1 0

Problems with multiple Wine programs at once
by David D. Hagood 10 Oct '02

10 Oct '02

I have the misfortune of needing to use Windows based DSP compilers for a project I am working on. Fortunately, they run under Wine just fine. So, the actual makefile is executed by a native GNU/Linux make, but the compile and assemble parts are Windows programs running under Wine (using Linux's binfmt_misc to launch them.) If I do a normal make, all is well. However, if I try to do a "make -j2" then after a few moments all the wine processes will freeze. Doing a ps -o wchan shows all the wine processes stuck in pipe_wait, and the wineserver process in do_poll. Has any body else seen this sort of behavior?

2 1

Re : wine/programs/wcmd wcmdmain.c
by Sylvain Petreolle 10 Oct '02

10 Oct '02

1 0

Please ignore previous posting
by Matthew Davison 09 Oct '02

09 Oct '02

Please ignore my previous posting (if it even showed up), the fault was nothing to do with wine. -- Matthew Davison

1 0

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