April 2003 - Wine-Devel - list.winehq.org

Re: Visual FoxPro 8 / Wine20030318 crash

by Paul McNett

Uwe Bonnes writes: > Paul> fixme:ole:DispCallFunc Do not know how to handle pvargResult > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > For the first error, either try with a combo of the native OLE dlls > (ole2,ole32,oleaut32, rpcrt4 and maybe more) or hope that some of the OLE > gurus( Hey Marcus :-) picks up the problem. Ok, that error disappeared. Will have to add back builtin to each dll individually to determine which one is at fault... I don't think that was the cause of my problem anyway (see below). > Paul> kernel32.dll.BeginUpdateResourceA fixme:process:CreateProcessA > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > For the unimplemented function, perhaps try to add a stub > implementation. Look in the archives how others did it ( find out the > arguments, add the entry in the spec file, add a stub implementation in a > .c file and send the patch). Ok, I did this. Now I'm not a C programmer but it was pretty easy to figure out what to do. I changed the @stub in the spec file to @stdcall, and added the argument types. I noticed that UpdateResourceA and UpdateResourceW are implemented as stubs in /win32/kernel32.c, so I put in the BeginUpdateResourceA, W and EndUpdateResourceA, W there as well. With these changes, the Build EXE process doesn't crash for me anymore. I end up with an EXE that runs fine, but doesn't contain icon and version resources. At least I can do my test builds on Linux and then when I'm ready to deploy I can build on Windows. So, I'll follow the instructions on submitting the patch later today. Thanks Uwe! -- Paul McNett Liberal Earthling

April 2, 2003

Re: Any DCOM experts?

by Gregory M. Turner

On Monday 31 March 2003 11:40 am, Bill Medland wrote: > > > The builtin rpcrt4 fails on a call to unimplemented > > > RpcServerInqDefaultPrincName but I don't understand why it is even > > > calling that; why does it think I have Netware only and why does it > > > think this is a server process. > > > > What does that have to do with netware? As far as I know, the security > > principal is the backbone of the NT domain's and DCOM's security model. Probably just crappy docs. IIRC DCE RPC does define an equivalent API, so it ought to have some non-netware applications as well. Probably, stubs for more of the RPC security and name services API's would be helpful here, if only to expose a new landscape of unimplemented functionality ;) So to recreate this, what does one do exactly? DCOMTST does it with native rpcrt4? Or some other setup? -- gmt "An honorable Peace is and always was my first wish! I can take no delight in the effusion of human Blood; but, if this War should continue, I wish to have the most active part in it." --John Paul Jones

April 2, 2003

Re: ImageList - dirty hack

by Vitaliy Margolen

Is there are any reason why this one haven't been checked in? This is pretty close to what windows does. Vitaliy Margolen > Fix ImageList_Read. This hopefully fixes these ugly images mostly on tool bars. > I'll continue to work on ImageList since ImageList_Replace, ImageList_Add, > ImageList_GetImageInfo and perhaps some other functions doesn't work right. > Vitaliy Margolen > changelog: > - dlls/comctl32/imagelist.c > fix ImageList_Read - the root cause of ugly toolbar icons > Index: dlls/comctl32/imagelist.c > =================================================================== [skip]

April 2, 2003

Re: Compiling Wine sources with duplicated include parameters

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On April 2, 2003 12:15 am, Alexandre Julliard wrote: > > At least gcc doesn't do that. It looks in the directory that the > > source file came from, which is *not* the current directory for out of > > tree builds. So the -I. is very much needed. > > OK, but then we don't need to include the source dir <g>. Yes we do, not all files are in the main source dir. Believe it or not, all that stuff is here for a reason. -- Alexandre Julliard julliard(a)winehq.com

April 2, 2003

Re: Unexpected message from winebuild...

by Bill Medland

On April 1, 2003 09:59 pm, Kevin Cousins wrote: > ...when attempting to build a WineLib application. > > Remember, I'm attempting to get something that will run-time link > against a native DLL, so I take my code, run it by "winemaker", run > "./configure", then "make", all with options I believe to be > appropriate. In particular, given export WINEDIR=/home/kevin/wine, the > root of my Wine source tree checked out from winehq CVS yesterday, and > export DLLINCDIR=/home/kevin/include, then from within the directory > containing the C source code for my simple console app I execute the > following: > > $ winemaker --cuiexe -I${DLLINCDIR} -I${WINEDIR} > [...snip...] > $ ./configure --with-wine=${WINEDIR} \ > --with-wine-dlls=${WINEDIR}/libs/dlls --srcdir=`pwd` \ > --with-wine-libraries=${WINEDIR}/libs/wine:${WINEDIR}/libs/uuid:${WINEDIR}/ >libs/unicode [...snip...] > $ make > [...snip...] > > > > Until make executes, there seems to be no obvious problem (at least to > my eyes), and even then, as the compilation happens, I get a nice file > called "prog.o" written. > > However, as "winebuild" executes, I see the following: > > --- > LD_LIBRARY_PATH="/home/kevin/wine/libs/wine:/home/kevin/wine/libs/unicode:$ >LD_LIBRARY_PATH" /home/kevin/wine/tools/winebuild/winebuild -fPIC -o > prog.exe.spec.c --exe prog.exe -mcui prog.o -L/home/kevin/lib > -L/home/kevin/lib/wine -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 > -lole32 -loleaut32 -lshell32 -luser32 -lwinspool could not open .def file > for advapi32 > --- > > I don't believe I even need anything from advapi32.dll.so, let alone > most of the other Wine DLLs mentioned on the winebuild command line. > Even if I hack the generated Makefile so as to remove mention of any > Wine DLLs on the winebuild command line, winebuild still complains about > not opening "...a .def file for ntdll". > > On a related note, the configure script generated by winemaker complains > about test linking against -L${WINEDIR}/dlls -lntdll.dll and subsequent > equivalent builtin DLLs such as -lkernel32.dll and -luser32.dll. My > quick hack is merely to clone the symbolic links in ${WINEDIR}/dlls to > add a "lib" prefix, vis: > > $ ( cd ${WINEDIR}/dlls ; ls -l *ntdll.dll* ) > lrwxrwxrwx 1 kevin 18 Apr 1 15:29 ntdll.dll.so -> > ntdll/ntdll.dll.so lrwxrwxrwx 1 kevin 18 Apr 1 15:29 libntdll.dll.so > -> ntdll/ntdll.dll.so $ > > That keeps configure happy, but I wonder what I'm doing wrong. This is > Wine built from CVS as of 20030401 (i.e. yesterday). > > Suggestions? Particularly for the wanted .def files. They're %^*&@# > builtin DLLs! Kevin Hopefully someone will get back to you today, but here's my (not very useful) additions. I haven't touched winemaker for probably over six months and in that time it looks like its all changed. If you don't need any dlls linked in then why are you bothering with winebuild. However if you are using functions that are implemented in dlls (whether in native Microsoft ones or wine builtin ones) then the "linking system" needs to know about them. Since this is not necessarily under VC++ winebuild is going to have to do that, and that is done in the def files. I see a whole load of def files in my /usr/local/lib/wine; don't you have them there? Hopefully that will keep you going until one of the experts turns up. -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

April 2, 2003

Re: OSS Bug

by Rod Taylor

Found something related: http://news.gw.com/freebsd.bugs/22626 According to it, FreeBSD doesn't have that ioctl as it's always on. On Tue, 2003-04-01 at 19:09, Robert Reif wrote: > The problem Rod is seeing is caused by code that I added to > check the return value of an ioctl in OSS_RawOpenDevice. > The code now checks the return value and returns on failure > rather than ignoring it. I don't know if this is a BSD issue or > a hardware driver issue or something else. > > Rod Taylor wrote: > > > http://bugs.winehq.com/long_list.cgi?buglist=1349 > > > > I think bug 1349 is related to the below conversation. > > > > http://www.winehq.com/hypermail/wine-devel/2003/03/0379.html > > > > Robert Reif suggested I send in a note. > > > > -- > > Rod Taylor <rbt(a)rbt.ca> > > > > PGP Key: http://www.rbt.ca/rbtpub.asc > > > > ------------------------------------------------------------------------ > > Name: signature.asc > > signature.asc Type: application/x-unknown-content-type-asc_auto_file > > Description: This is a digitally signed message part > -- Rod Taylor <rbt(a)rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc

April 2, 2003

Re: valgrind for WINE

by Adam Gundy

At 19:45 01/04/03 -0600, Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: >Adam Gundy wrote: >> a new version of the valgrind patch has been uploaded to sourceforge - >> the only change is a small fix to the signal handling which should >> prevent "signal handler frame" uninitialized errors. >> >> http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… >> >> comments? bug reports? success stories? > >did test it yet. > >As a global note, I think it would be appreciated breaking the patch in >smaller bits... it makes it easier to track/follow what happens. For >example, I don't see any reason for including the msvcrtd patches into >this patch the reason msvcrtd is there is that you need to use it for valgrind to do any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c) is required to tell valgrind that freshly allocated blocks are uninitialized, and the freed blocks are now invalid. If you build a debug executable using MSVC you have to use MSVCRTD.DLL, hence the new spec file for msvcrtd.dll.so >I think that Alexandre is currently integrating (bit per bit) your >changes into wine. look for the patch about zeroing the request zones >(which is another implementation of your structure packing), as well as >local availability of the thread PID haven't seen these yet >on a more minor side of things, I would keep the VALGRIND prefix in heap.c not sure what you mean here, but the heap.c stuff appears to have been committed (slightly rewritten by the look of it...). To be of ANY use you need the MSVCRTD stuff as well though! >last point, using the .vg extension to the wine script may not be >optimal. it won't work (as it is written) for winelib programs (which >got started also thru the wine script) >one solution would be (to follow your idea) to link (for a winelib app >called foo) foo.vg to script wine (and change your rule something like >*.vg|*/*.vg). another option would be to embed this support as an option >to the wine script (like --valgrind) maybe, this was just a hack to make it easier to use "in tree". not sure people would want a "--valgrind" switch in a (presumably) production winelib piece of software - it would show the world all your bugs ;-) >how are your patches doing on the "other side" (I mean valgrind's) ? just starting to make progress into CVS commits - there appear to be several other patches which overlap with mine, so there will probably be some ordering and refactoring required... Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

April 2, 2003

Winemine colors

by Joshua Thielen

Hello, I was just going through my old mail and I noticed Shachar's email (below) on Jan. 26. Just to let you know, I do try to keep up with the wine devel discussions, but as you can see, I'm not very successful. I still have a bug assigned to me that is almost a year old now. I'd like to work on wine more, but I've been really busy with school lately. Hopefully, I'll have more time when I graduate. Anyway, I chose that green color in winemine specifically to make it annoying ;). Actually, at the time I didn't want it to have a boring old gray background, so I chose green in order to make it would look like grass (a mine field). But I guess it's pretty annoying. Do you have a color preference? Do you or anyone else have more suggestions for improving winemine? Maybe ideas for a 3D minesweeper game or something? I wrote it like four years ago, and I didn't know a whole lot about what I was doing (I was in Comp. Sci. 1 when I wrote it). I'd like it to be more fun than your typical minesweeper game. Also, when I originally submitted it, someone complained that it was slow. Is this still the case for anyone out there? Thanks, Josh -------------------------------- >From Shachar Shemesh on Jan. 26: Tom Wickline wrote: > I am in the process of updating section 3.1. ( Wine Static and > Shareable Files ) of the > Packagers Guide : > http://www.winehq.com/Docs/wine-pkg/pkg-components.shtml#PKG-STATIC > > Below is a list of what I have so far. This list is by no means done > or correct . > I would like to submit it here for overview. If you are aware of > something that > is out of place, incorrect, or just out right wrong could you please give > feed back on it. > > This could also serve to start as a mini Wine Dictionary :)) > That is not my current goal but if others think it could be of use > I could spend some time on one after the Packagers Guide is updated. > > Tom > > > -------------------------------------------- > > -- = files that are listed in this Doc but are not installed on my > system. > * = files are in this Doc and on my system > @ = files that are on my system but not in the Doc > # = files that are not in the Doc or on my System ( wineboot ) Then how do you know of their existance ;-). If wineboot is not installed, that's a bug. We should fix it. I'll try to help with the things I know. This is far from authorative on most, however. > @ regedit : A tool to browse/edit your regestory or for exporting a > windows registory to Wine. Not browse. At least, not yet. > # wineboot : A Winelib application that's executed by Wine on startup > of the first wine process of a particular user. > * wininit.ini processing > * registry RenameFiles entries > * RunServices* / RunOnce* / Run registry keys > * win.ini Load= / Run= entries > * StartUp folder processing the last two are not yet done. Also not yet done is for wineboot to automatically run when needed. Currently you have to manually run it after you install something. > @ winemine : A winmine clone "Windows Minesweeper" ??? Yep, using horrid green colors. I'm sorry if I have offended the author (Joshua Thielen, are you still with us?) > @ winepath : Specifies the path(s) in which to search for builtin dlls > and Winelib applications. I think this is an executable that, given a Unix path, will tell you what Wine sees it like (i.e. - you tell it ~/c/windows, and it tells you C:\Windows). I'm not sure on that one. > -- winesetup : This is a Tcl/Tk based front end that provides a user > friendly tool to edit and configure the WINECONFDIR/config file. Anyone knows where it is? It was never based on the winehq sources. Shachar __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

April 2, 2003

Re: valgrind for WINE

by Adam Gundy

At 12:17 01/04/03 -0800, you wrote: >Adam Gundy <arg(a)cyberscience.com> writes: > >> a new version of the valgrind patch has been uploaded to sourceforge - >> the only change is a small fix to the signal handling which should >> prevent "signal handler frame" uninitialized errors. >> >> http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… >> >> comments? bug reports? success stories? > >I played a bit with it, it works pretty well, and I have already fixed >a few bugs found with it. Great work! > >I have also applied those of your fixes that seemed correct, the rest >will need a bit more work The signal stuff in particular is not going >to work properly with NPTL, it would be really better if we could >somehow make valgrind use real threads. I have no idea if this is >possible though. which part of the signal stuff won't work? all that has happened is that the "kill( <pid>, SIGUSR1 )" has moved from the wineserver to the client (for 'local' threads). I thought that the NPTL stuff still wanted a PID-per-thread model just so it can do this? OTOH if you can *really* switch to a pure pthreads model, that should be no problem since valgrind comes with a pthread library... as to making valgrind use real threads, I think that is a BIG job, and unlikely to happen, since the only thing that wants 'real' threads is WINE - everything else is happy with pthreads. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

April 2, 2003

Re: valgrind for WINE

by Dimitrie O. Paun

On April 2, 2003 08:55 am, Adam Gundy wrote: > the reason msvcrtd is there is that you need to use it for valgrind to do > any checking of the heap - an instrumented malloc (see the changes to > ntdll/heap.c) is required to tell valgrind that freshly allocated blocks > are uninitialized, and the freed blocks are now invalid. What Eric meant is that the msvcrtd can go in as a separate patch. Yes, it is required by VALGRIND, but it's useful on it's own as well, so just submit that one individually. > maybe, this was just a hack to make it easier to use "in tree". not sure > people would want a "--valgrind" switch in a (presumably) production > winelib piece of software - it would show the world all your bugs ;-) We can disable that switch completely if we don't configure with VALGRIND. No problem there. -- Dimi.

April 2, 2003