- Wine-devel - list.winehq.org

RE: Linuxism in dlls/msvcrt/msvcrt.spec?
by Medland, Bill 19 Mar '02

19 Mar '02

> -----Original Message----- > From: Gerald Pfeifer [mailto:pfeifer(a)dbai.tuwien.ac.at] > Sent: Monday, March 18, 2002 8:31 AM > To: wine-patches(a)winehq.com > Cc: Martin Faxer > Subject: Linuxism in dlls/msvcrt/msvcrt.spec? > > > I believe there is a Linuxism in dlls/msvcrt/msvcrt.spec which expects > that _tolower and _toupper exist as functions. > > The following patch by Martin Faxér > <gmh003532(a)brfmasthugget.se> addresses > this; if this patch seems unacceptable, we'd appreciate a > note and a short > explanation why the current code is fine and the patch is not fine. > > Thanks, > Gerald Well actually I think both are wrong; I am just doing the patch. (Actually I don't understand where the _toupper is coming from) The problem is that _toupper is NOT the same as toupper; _toupper does not test that the character is lowercase; it just converts it. The patch is to hook into the existing MSVCRT__toupper and MSVCRT__tolower. Bill

1 0

debugging longman dictionary
by Rizsanyi Zsolt 19 Mar '02

19 Mar '02

Hi! I'm trying to debug what goes wrong with the Longman Dictionary of Contemporary English. I have succeeded installing it under wine on a fake windows installation. (I had some problems, and posted them on wine-user, but I have succeded) Now I get an unhandled exception (page fault on read access). But I cant find the cause of the problem. Maybe somebody could hint me how to proceed. I'm attaching the output of wine --debugmsg +relay LDOCE32.EXE Also I have set up a breakpoint, and stepped through the last 10 instructions before the page fault, but I dont understand what that code is trying to do (it is somewhat strange). Also it may be usefull if you could put in a faq or some other documentation that the next output (which is very frequent), is just a check running debugger. This check is usually done in sharewares to check whether the program is debugged. This is the characteristic output: fixme:win32:DEVICE_Open Unknown/unsupported VxD SICE. Try --winver nt40 or win31 ! fixme:win32:DEVICE_Open Unknown/unsupported VxD SIWVID. Try --winver nt40 or win31 ! fixme:win32:DEVICE_Open Unknown/unsupported VxD NTICE. Try --winver nt40 or win31 ! At first I tried to define these VxD-s, but when I did so the program instracted me to stop the debugger and restart. Thanks for your attention, and I hope you can help me :) Zsolt Rizsanyi

2 1

Status of Wrc port to mingw
by Steven Edwards 18 Mar '02

18 Mar '02

I'm currently trying to port wrc to mingw. Everthing builds fine except when running "bison -bppy -ppp -d -t ./ppy.y" I get "conflicts: 2 shift/reduce". I have started bug 474 in bugzilla if anyone wants to help with this. Thanks Steven _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 2

Re: PATCH: files/smb.c
by Francois Gouget 18 Mar '02

18 Mar '02

On Sat, 16 Mar 2002, Gerald Pfeifer wrote: > This patch is required to make the newly contributed files/smb.c compile > on FreeBSD 4.x (and Solaris 2.x, far as I can see). You should test HAVE_NETINET_IN_SYSTM_H and HAVE_NETINET_IN_H. looks good otherwise. > ChangeLog: > Add missing #includes for FreeBSD and Solaris. > > Index: smb.c > =================================================================== > RCS file: /home/wine/wine/files/smb.c,v > retrieving revision 1.1 > diff -u -3 -p -r1.1 smb.c > --- smb.c 12 Mar 2002 19:24:04 -0000 1.1 > +++ smb.c 16 Mar 2002 12:48:20 -0000 > @@ -53,6 +53,8 @@ > #include <utime.h> > #include <sys/socket.h> > #include <sys/types.h> > +#include <netinet/in_systm.h> > +#include <netinet/in.h> > #include <netinet/ip.h> > #include <arpa/inet.h> -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

1 0

PE loader integrated into BSD
by Dan Kegel 18 Mar '02

18 Mar '02

At Wineconf tonight, people were talking about whether integrating bits of wine into the kernel was useful, and how much should be moved in. (Hello task ornaments!) Anyway, I mentioned that somebody had integrated a PE loader into BSD. Here's the page: http://chiharu.hauN.ORG/peace/ I think this is pretty darn cool, and hope somebody does something similar for Linux. - Dan

3 5

Re: Enhancements for the C testing framework
by Dimitrie O. Paun 18 Mar '02

18 Mar '02

Hi Francois, I still think we should rename the START_TEST macro to DEF_TEST or DEFINE_TEST, 'cause that's what we're actually doing. -- Dimi.

1 0

[Fwd: Re: wineconf summary]
by Michael Cardenas 18 Mar '02

18 Mar '02

Dimi, sorry about the spelling! I'll correct that. >Also, we need to: > 1) post the pics > 2) pick the best group picture, and annotate it >I'll bet you the annotated picture will be the most popular thing. > >When all is done, we need to make an announcement on Slashdot. > I'll send my pics tonight to andi, since I left my digital camera at home.

1 0

Re: Heap allocation problem
by Duane Clark 18 Mar '02

18 Mar '02

Duane Clark wrote: > Uwe Bonnes wrote: >>Just a shot in the dark: Did you perhaps install on a real WinNT machine and >>now run wine in --winver win95 mode or vice versa? >>http://support.microsoft.com/default.aspx?scid=kb;EN-US;q125713 >>points out some possible problems. > > > I'm running a dual boot Win98/RH7.2 system, and booted Win98 to install > the app. I don't ever supply a winver, but have Tweak.Layout set for > Win98. The app ran fine (except for the toolbars) prior to the addition > of anon_mmap_aligned() this past October (I had not run it for awhile, > but needed it now again). It looks like I never mentioned the circumstances where this error occurs. Most of the app comes up and runs, but there is a large area where messages are printed that uses a richedit control. Since the wine richedit does not work, I use a Win98 native richedit. What happens along with the heap error, is that the richedit control is not drawn. Instead the desktop remains showing through a large area in the center of the app. With my quicky "fix", the entire app including the native richedit works fine. However this is not specific to richedit. I have another test app I put together that uses richedit, and it works fine without the heap "fix".

1 0

TurboTax
by Kevin O'Connor 18 Mar '02

18 Mar '02

> I've been following Wine development for the last 6 months, mostly watching > for improvements for the 2 Windows applications I actually care about -- > Quicken and TurboTax. [...] > TurboTax was basically unusable until recently -- but when I returned from > a short vacation and updated my wine sources, all the show-stopping issues > with TurboTax had been resolved. Amazing. Hi Jeff, After seeing your note, I synched up my cvs and attempted to run turbo tax as well. After a brief failure due to a missing NdrDllUnregisterProxy function (which I fixed using the patch below), I too was impressed to see turbo tax running. > The one issue in both tools that I still need to check on is both > consistently ran out of GDI space, which I've hacked around with some > tweaks to gdiobj.c. Unfortunately, I quickly ran into this problem as well. I am not familiar enough with wine to fix this error by myself - would you be willing to push your hack along so I can take a look at this also? Thanks, -Kevin --- dlls/rpcrt4/rpcrt4.spec 19 Feb 2002 18:37:26 -0000 1.13 +++ dlls/rpcrt4/rpcrt4.spec 18 Mar 2002 03:34:28 -0000 @@ -26,7 +26,7 @@ @ stdcall NdrDllCanUnloadNow(ptr) NdrDllCanUnloadNow @ stdcall NdrDllGetClassObject(ptr ptr ptr ptr ptr ptr) NdrDllGetClassObject @ stdcall NdrDllRegisterProxy(long ptr ptr) NdrDllRegisterProxy -@ stub NdrDllUnregisterProxy +@ stdcall NdrDllUnregisterProxy(long ptr ptr) NdrDllUnregisterProxy @ stub RpcAbortAsyncCall @ stub RpcAsyncAbortCall --- dlls/rpcrt4/rpcrt4_main.c 9 Mar 2002 23:39:12 -0000 1.21 +++ dlls/rpcrt4/rpcrt4_main.c 18 Mar 2002 03:34:28 -0000 @@ -363,7 +363,20 @@ HMODULE hDll, /* [in] */ const ProxyFileInfo **pProxyFileList, /* [in] */ const CLSID *pclsid /* [in] */ -) +) +{ + FIXME("(%x,%p,%s), stub!\n",hDll,pProxyFileList,debugstr_guid(pclsid)); + return S_OK; +} + +/*********************************************************************** + * NdrDllUnregisterProxy (RPCRT4.@) + */ +HRESULT WINAPI NdrDllUnregisterProxy( + HMODULE hDll, /* [in] */ + const ProxyFileInfo **pProxyFileList, /* [in] */ + const CLSID *pclsid /* [in] */ +) { FIXME("(%x,%p,%s), stub!\n",hDll,pProxyFileList,debugstr_guid(pclsid)); return S_OK; -- ------------------------------------------------------------------------ | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin(a)koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | ------------------------------------------------------------------------

2 1

Heap allocation problem
by Duane Clark 18 Mar '02

18 Mar '02

Something else to look at when people get back from wineconf. One of my apps (Actel Designer) was generating the error message from HEAP_CreateSystemHeap(): system heap base address 65430000 not available This results from the call to MapViewOfFileEx() with the address SYSTEM_HEAP_BASE, which is 65430000. The comment in the header of MapViewOfFileEx() for this parameter, addr, says it is a "Suggested starting address for mapped view". That then calls anon_mmap_aligned(). In this particular application, the address 6543xxxx appears to have already been allocated elsewhere, so anon_mmap_aligned() appears to have allocated a valid block, but at a different address. Then at the bottom of the routine, the test else if (ptr != base) determines that these two addresses do not match and then unmaps the allocated block, leading to the heap allocation failure. Oddly enough, back in October, when this problem first appeared (with the introduction of anon_mmap_aligned()), HEAP_CreateSystemHeap() contained the comment "pre-defined address not available, use any one", but later on the "use any one" part was removed. So I tried commenting out the unmapping in anon_mmap_aligned(), and returning the allocated pointer, and my program is back to working fine. But I am not anywhere near understanding what the right fix is.

2 1