October 2002 - Wine-Devel - list.winehq.org

Re: winapi_test update
by Alexandre Julliard Oct. 11, 2002

Oct. 11, 2002

Patrik Stridvall <ps(a)leissner.se> writes: > *** include_test_generated > > * include/wine/test_generated.h: > New include file with helpers for the generated tests. I think it would be better to put these macros in each generated C file. The code duplication doesn't hurt since it's all generated code anyway, and I'd rather avoid creating yet another global include. -- Alexandre Julliard julliard(a)winehq.com

1 0

Exception with ocx not caught
by Fabian Cenedese Oct. 11, 2002

Oct. 11, 2002

Hi I already posted about this problem, now maybe someone else is able to help me. Creating ocx: http://www.winehq.com/hypermail/wine-devel/2002/09/0021.html Catching MFC exception: http://www.winehq.com/hypermail/wine-devel/2002/09/0057.html I now have a simple ocx and an exe that has nothing else than this ocx in it. The ocx appears as black circle on white ground in the upper left corner (right, the wizard made ocx) In Windows it works without a problem but in wine there's an exception upon creating the ocx. It happens with both builtin and native msvcrt.dll. I can see that some exceptions are raised about missing properties in the ocx, they also appear on Windows (debug output) and get caught before doing any harm. I sometimes had problems reproducing it. Then the dialog came up but without ocx. Both exe and ocx are made with MSVC6 (Project and binaries, debug/release): http://www.indel.ch/ftp/TestException.zip Also here is a backtrace at the moment of the exception: http://www.indel.ch/ftp/TestException.txt Alexandre once asked for an example, maybe he or someone else can use this here. I'm using actual wine from cvs on SuSE8, original dlls tried from NT4. Thanks bye Fabi

3 3

building ntdll on cygwin
by Steven Edwards Oct. 11, 2002

Oct. 11, 2002

we get much futher now when building ntdll on cygwin. when linking I am getting the following error ntdll.exp(.edata+0xe4c):fake: undefined reference to `NTDLL_alloca_probe(a)0' ntdll.exp(.edata+0xe5c):fake: undefined reference to `NTDLL_chkstk(a)0' there are some other warnings but this is the only major thing with ntdll. Thanks Steven

4 6

Building setupapi under Mingw
by Steven Edwards Oct. 11, 2002

Oct. 11, 2002

Hola, I noticed some work was going on in setupapi so I figured now would be a good time to ask for some help on the Windows/Mingw port. When I try to build under mingw I get this Info: resolving _wine_ldt_copy by linking to __imp__wine_ldt_copy (auto-import) setupapi.dll.glue.o(.text+0x82):setupapi.dll.glue.c: undefined reference to `win e_call_to_16_word(a)8' fu000001.o(.idata$3+0xc): undefined reference to `libwine_a_iname' nmth000000.o(.idata$4+0x0): undefined reference to `_nm__wine_ldt_copy' C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [setupapi.dll] Error 1 Any hints as to how to fix? Thanks Steven

1 0

Re: wine/dlls Makefile.in rpcrt4/Makefile.in rpcrt ...
by Greg Turner Oct. 10, 2002

Oct. 10, 2002

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 Oct. 10, 2002

Oct. 10, 2002

> 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 Oct. 10, 2002

Oct. 10, 2002

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 Oct. 10, 2002

Oct. 10, 2002

"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 Oct. 10, 2002

Oct. 10, 2002

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 Oct. 10, 2002

Oct. 10, 2002

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