wine-devel

wine-devel@winehq.org

4 participants
84472 discussions

Re: using native regedit
by Jeff Smith 22 Oct '02

22 Oct '02

Thanks for the advice, this should get me by for now. Of course I would still like DllOverrides section to work as advertised, but maybe I can hack on it some more when I am more in the mood. P.S. Sorry about the HTML message, the Hotmail admins seem to be playing around with default settings. -- Jeff S. >From: Greg Turner To: "Jeff Smith" , wine-devel(a)winehq.com On Tuesday 22 >October 2002 01:01 pm, Jeff Smith wrote: > I know I must be missing > >something very simple, but I cannot seem to > > get native regedit to run. The builtin version always > runs instead. >The only thing I could think of was an entry > in DllOverrides: > > "regedit.exe" = "native, builtin". That did not work. > > > I have debugged a little and know MODULE_GetLoadOrder > is returning >{LOADORDER_BI, LOADORDER_DLL, LOADORDER_INVALID, > LOADORDER_INVALID} even >when I add that DllOverride line. > But I am just not in the mood at the >moment for deep digging if > I can help it. > -- Jeff S. >Well, if my wetware HTML parser is working today, I think I understand your >problem. Just rename regedit.exe to "winregedit.exe" (or whatever you >like), or create a symlink or copy of the native version. (some configs >don't respect symlinks). > >-- >gmt _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Perhaps (2) and (3) are not much different (se below), > > but (1) and (2/3) are clearly different. > > Well yes, that why they are in different directories. (1) is in > include and (2/3) is in include/wine. Yes, but because of how they are positioned in the filesystemet and used by C they are effectively "packaged together" in a bad way. It seems that I'm not the only one having this problem as well. Steven Edwards also wants a way to use the Mingw/W32api package together with Wine in a sane way. But I have a plan how to smoothly migrated from the current layout to a new layout. See below. > > That is why I think "-I../../include" shouldn't automatically give > > you (2) and (3) as it does now. Having to add -I../../include/wine > > or whatever to get it would make it possible in addition to > > solving my MSVC Microsoft header problem to make it possible to > > uses the Microsoft headers or whomevers headers even on Linux. > > The problem is that then you require everybody who wants to use > Winelib to add stuff to their include path, even if they don't use any > Wine header directly (since our Windows headers reference the Wine > ones). They currently do, yes. That is why I initially suggested creating a include/wine/wine and only moving the "extension" headers like over to include/wine/wine. The "extension" headers are files in include/wine like debug.h, exception.h, library.h, port.h, server.h, test.h, unicode.h that isn't or shouldn't be included by our Windows headers. In the extent that they are it is a bug IMHO and AFAICS one that is quite easily fixed in most cases as well. However, in the first phase to get the all the tests running I AFAICS only need exception.h, test.h and unicode.h. Of them only unicode.h is currently used by the Wine headers (file.h and heap.h). However fixing that shouldn't really be a problem. I will look into it. I suggest that we gradually move the files in include/wine to include/wine/wine or in some cases other places like the DLL directories. Eventually, far in the future, the include/wine directory will be empty (save for a wine directory). This provides a slow and steady migration path from the old to the new that doesn't have any of the problems you described. What more can you ask for? > So you are making the normal case more complex to simplify the > very unusual case of mixing headers. I prefer to ask people who want > to mix headers to do some extra steps and make the common case as easy > as possible. As stated above the problem can be solved. Wine itself is AFAIU (not tested) fixed by this patch. Nothing more should be needed. Index: Make.rules.in =================================================================== RCS file: /home/wine/wine/Make.rules.in,v retrieving revision 1.131 diff -u -r1.131 Make.rules.in --- Make.rules.in 19 Oct 2002 17:15:00 -0000 1.131 +++ Make.rules.in 22 Oct 2002 09:02:33 -0000 @@ -45,7 +45,7 @@ LN = @LN@ LN_S = @LN_S@ TOOLSDIR = @TOOLSDIR@ -DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include $(EXTRAINCL) +DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include -I$(TOPSRCDIR)/include/wine $(EXTRAINCL) ALLCFLAGS = $(DIVINCL) $(CFLAGS) $(DEFS) $(OPTIONS) LD = @LD@ LDFLAGS = @LDFLAGS@ Normal Winelib application have shouldn't (and needn't) use the Wine "extension" header so they don't need the in the include path them. The few application that does, can be very easily fixed simply by adding an additional -I, which isn't to much to ask IMHO.

3 2

Problem with X11 driver
by Till Mossakowski 22 Oct '02

22 Oct '02

Hi, I have a problem with the X11 driver (it seems), related to bug 1027. When I run my program (Fitch.exe), wine gets stuck. All threads do a WaitForMultipleObjects, the main thread a WaitMessage. And I get an error err:ntdll:RtlpWaitForCriticalSection section 0x40af4b04 "x11drv_main.c: X11DRV_CritSection" wait timed out, retrying (60 sec) tid=080b8780 I read the FAQ about critical section errors, and it helped my to get the following calling stack: KERNEL32.DLL.WaitForMultipleObjectsEx+0x16a X11DRV.DLL.MsgWaitForMultipleObjectsEx+0xf3 USER32.DLL.MsgWaitForMultipleObjectsEx+0x14f USER32.DLL.WaitMessage+0x22 WINAWT.DLL.PrintEmbeddedFrame+0x7ca JAVAI.DLL.mmiFrameMethod+0x3625 JAVAI.DLL.mmiFrameMethod+0xb60 COMDLG32.DLL.PrintDlgExW+0x2a2dc0 JPEG.DLL..reloc+0x12e2cb9b *** Invalid address 0xc308c483 (IBMJITC.DLL..reloc+0x1df5f482) (Indeed, Fitch is written in Java - however, unfortunately it is not possible to run it directly under Linux. I also tried to get diagnostic messages from the Java runtime systems, but it seems that all classes are loaded correctly, and then the error occurs.) When I set "Synchronous" = "Y" in the x11drv section of config, everything works, but *very* slowly. Sometimes it takes 15 seconds until a mouse click leads to the desired action. I also played with the other x11drv settings in the config file, but without effect. The documentation says that one should set "Synchronous" = "Y" for debugging purposes. But how proceed then? Greetings, Till -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till(a)tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till

2 7

OleAut32.dll.DispCallFunc
by Fabian Cenedese 22 Oct '02

22 Oct '02

Hi all My app stumbled over a not implemented function from oleaut32.dll called DispCallFunc. It's only available as stub. I tried to find some info about this but it's an undocumented "feature". MSDN doesn't mention it at all (obviously) and on the net I could only find this short description: *** ITypeInfo::Invoke (or DispInvoke) needs v-table to call-in a method. But when we are talking about pure disp-interfaces - they don't have any info about v-table, but just a mapping between DISPID and method signature. Therefore these functions would fail miserably to convey the call to pure dispinterface, but as all we know - the majority of sources(/events) interfaces are these pesky dispinterfaces. DispCallFunc is a low-level routine (that btw is used by DispInvoke and ITypeInfo::Invoke internally). It pushes arguments from DISPPARAMS argument to the stack accordingly to supplied description of the method, calls specified function pointer and on the return adjusts stack back and return retval (both variant and HRESULT) to the caller. *** And I also found this example: *** //Helper for invoking the event HRESULT InvokeFromFuncInfo(void (__stdcall T::*pEvent)(), _ATL_FUNC_INFO& info, DISPPARAMS* pdispparams, VARIANT* pvarResult) { T* pT = static_cast<T*>(this); VARIANTARG** pVarArgs = info.nParams ? (VARIANTARG**)alloca(sizeof(VARIANTARG*)*info.nParams) : 0; for (int i=0; i<info.nParams; i++) pVarArgs[i] = &pdispparams->rgvarg[info.nParams - i - 1]; CComStdCallThunk<T> thunk; thunk.Init(pEvent, pT); CComVariant tmpResult; if (pvarResult == NULL) pvarResult = &tmpResult; HRESULT hr = DispCallFunc( &thunk, 0, info.cc, info.vtReturn, info.nParams, info.pVarTypes, pVarArgs, pvarResult); ATLASSERT(SUCCEEDED(hr)); return hr; } *** Does anyone know more about this function? Where would this have to be implemented? Thanks bye Fabi

2 1

Re: MZ_Exec() patch, try 3
by Jukka Heinonen 22 Oct '02

22 Oct '02

The patch starts to look good, only one tiny thing left: you most likely want to return FALSE from MZ_Exec if CreateProcessA fails. If you want to read all comments to posts on wine-devel you have to take into account different time zones and different mail reading habits - waiting 24 hours should be enough to get replies from all active readers during weekdays. But, anyway, good to see I didn't scare you by being critical :) -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

VS6 Package & Deployment Wizard regression
by Ender 22 Oct '02

22 Oct '02

Oddly, some recent change has broken some of the command buttons in VS6's Package/Deployment wizard's dialogs.. Does anyone have any suggestions on what'd be some good traces to turn on? Or want to fix it themselves? <grin> - Ender

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I would like to have a directory structure like > > > > include: Wine's version of Windows headers > > include/wine: Wine's internal headers > > include/wine/wine: Wine's "extension" headers > > > > With "extension" headers I mean that headers that > > are exported and usuable by Winelib applications. > > That's ugly IMO. The specific solution above, perhaps. However I think it would be very useful to make a proper distinction between 1. The Wine version of Microsoft headers 2. Anything that Wine uses to communicate internal 3. Extensions that Winelib applications can use. Perhaps (2) and (3) are not much different (se below), but (1) and (2/3) are clearly different. That is why I think "-I../../include" shouldn't automatically give you (2) and (3) as it does now. Having to add -I../../include/wine or whatever to get it would make it possible in addition to solving my MSVC Microsoft header problem to make it possible to uses the Microsoft headers or whomevers headers even on Linux. > Besides there is no such distinction between internal > and "extension" headers, all the headers in include/wine are supposed > to be usable by Winelib app. Sure there are. Not all header from include/wine are copied to /usr/local/include/wine/wine during. The ones that are not copied are "internal" and the ones there are are "extensions" in some meaning. Only the "exension" headers (ie header that are copied during install) can be used by Winelib applications. However that might perhaps only be a temporary distiction. Anyway cd include/wine mkdir wine mv *.h wine work for me as well if you prefer that. > I'd suggest you simply copy the ones you > need with MSVC somewhere else to avoid conflicts. Hmm. Yes, that is another possibillity (read: kludge). Don't really like copying source files around, but it would work (with the possible exception of dependecies, but then "Rebuild all" is your friend :-). In short: I still think that we should require another -I to access the Wine specific (internal and extension) headers. However I don't really care if we do (1) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/include/wine (2) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/$(WHATEVER) I just don't think just doing -I$(TOPSRCDIR)/include like now is good for the reasons given above and below. Sometime you only want the Wine specific header sometimes you only want Wine's version of the Windows header. "Forcing" everybody to take them as a package only gives rise to unnessary problem like the one I'm trying to solve. Sure I could kludge it, but why not try to solve it properly?

3 2

MZ_Exec() patch, try 3
by chrismorgan＠rcn.com 22 Oct '02

22 Oct '02

Alright, yet another revision of this patch. This one uses dynamic memory allocation via HeapAlloc/Free(), doesn't modify the input command line and doesn't try to close process handles if CreateProcess failed. Third time a charm? ;-) * 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.23 diff -u -r1.23 module.c --- dlls/winedos/module.c 18 Oct 2002 23:48:58 -0000 1.23 +++ dlls/winedos/module.c 21 Oct 2002 22:00:16 -0000 @@ -339,17 +339,78 @@ /*********************************************************************** * 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 */ + { + LPBYTE fullCmdLine; + WORD fullCmdLength; + 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]; + + fullCmdLength = (strlen(filename) + 1) + cmdLength + 1; /* filename + space + cmdline + terminating null character */ + + fullCmdLine = HeapAlloc(GetProcessHeap(), 0, fullCmdLength); + + /* build the full command line from the executable file and the command line being passed in */ + snprintf(fullCmdLine, fullCmdLength, "%s ", filename); /* start off with the executable filename and a space */ + memcpy(fullCmdLine + strlen(fullCmdLine), cmdline + 1, cmdLength); /* append cmdline onto the end */ + fullCmdLine[fullCmdLength - 1] = 0; /* null terminate string */ + + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, fullCmdLine, NULL, NULL, TRUE, + 0, envblock, NULL, &st, &pe); + + WaitForSingleObject(pe.hProcess, INFINITE); /* wait here until the child process is complete */ + + HeapFree(GetProcessHeap(), 0, fullCmdLine); /* free the memory we allocated */ + + /* clean up PROCESS_INFORMATION handles if necessary */ + if(status) + { + 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 */

3 4

Re: Listview V15
by Bobby Bingham 21 Oct '02

21 Oct '02

On Mon, Oct 21, 2002 at 10:51:35AM -0400, Dimitrie O. Paun wrote: > > ChangeLog > Updated header documentation to the latest, and greatest. > <snip> > + * -- LVIS_ACTIVATING (not currently supported my comctl32.dll version 6.0) you mean "by" comctl32.dll version 6.0 ? <snip> > + * -- LVN_BEGINDRAG, LVN_BEGINRDRAG hmmm ... how about "LVN_BEGINFRAG, LVN_ENDDRAG" -- Bobby Bingham

2 2

compile with -DSTRICT
by Michael Stefaniuc 21 Oct '02

21 Oct '02

Hello, i'm not 100% sure what -DWINE_NO_STRICT should do, but i suspect it should negate the effect of -DSTRICT. The attached patch enables that and lets wine compile with -DSTRICT where WINE_NO_STRICT isn't defined. Comments? bye michael P.S.: is this -DSTRICT a m$ windows thing or a wine only thing? -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 2

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