- Wine-Devel - list.winehq.org

Re: get GetDateFormatW somewhat working...
by Vincent Béron Sept. 19, 2002

Sept. 19, 2002

Le jeu 19/09/2002 à 17:25, Arthur L. Jones a écrit : [...] > > notes: it seems like, if this ever worked correctly, that > OLE_GetFormatA could be implemented by just copying > the ascii buffer and sending it along to OLE_GetFormatW? That's the easiest way of implementing both the W and A variant of an API. There are numerous examples of such behavior in Wine. For the patch, the preferred format is unified (diff -u). You can add a line "diff -u" in your .cvsrc to do it automatically. Vincent

1 0

Problem with redraw/initialization in the X11 driver
by Martin Cracauer Sept. 19, 2002

Sept. 19, 2002

Hi, first of all let me say that I am impressed by the progress that wine made in the last months and I also see that working things don't get broken for long anymore. Congrats! I have one problem with a game and I think the problem might be easy to solve if you point me to the right piece of code. Basically the game (TacOps4) works fine, including all of OpenPlay.dll based networking, but there is a redraw problem with the X11 driver. When using the game in Wine, I see that Wine often draws white all over the main window of this application, and only parts which are redrawn manually by the game are rendered correctly. I think it is a safe guess that we see overcautious wine code in action here, initially the window to white with good intentions, but the application tries to optimize its redraw strategy and hence leaves all the white that wine draws. I tried switching on and off all the X11 driver options (dga etc.), but the problem was unaffected. The same problem appears in exactly the same way on Linux and FreeBSD. I am using XFree4.2 and the CVS version of DRI. I placed a screenshot showing the problem at http://www.cons.org/tmp/wine-tacops-problem.png You see that the main window is mostly white except for one item which I just dragged from the small window to the main window, where the game redrew just this area of the main window, and a second small area of the main window which the game engine redrew for whatever reason. Any suggestions about Wine code I should mess around with? Maybe there is explicit code which does this whitening that I could disable or make more clever? A demo of this game is available, showing the same symptoms, in can anybody wants to try it. ftp://ftp.battlefront.com/pub/demos/tacops4/tacops4demo_i.exe Mail me if you are unfamiliar with the game and want to see the bug fast, I don't want to clutter up this mail. Thanks! Martin

2 1

Replacing a DLL
by steve.lustbader＠philips.com Sept. 19, 2002

Sept. 19, 2002

I have a windows app that calls LoadLibrary on all the DLLs in a certain directory. It doesn't actually call any functions in the DLL; simply loading it causes the desired effects to take place. I'd like to replace one of those DLLs with a WineLib version that calls some Linux functions. I've compiled the WineLib dll with Winemaker, so now I have mydll.dll.so. It's written in C++, by the way. How can I replace the normal mydll.dll, such that the Windows program will load the winelib dll when I run it with Wine? -Steve

1 0

win32 types documentation
by Raul Dias Sept. 19, 2002

Sept. 19, 2002

Hi, I am having some difficulty into understanding some parts of wine source because of my lack of win32 knowledge. I am looking for undertanding into win32 types like WCHAR, LPWSTR, LPCWSTR and so on. I tryed to search msdn for this but I did not find any good doc about it. So, can someone point me good urls about this? thanks, Raul Dias

2 1

documentation dir
by Dimitrie O. Paun Sept. 19, 2002

Sept. 19, 2002

People, While I'm waiting for wine to compile, I figured I'd start a new flamewar :P I was looking through the documentation directory, and there are a few things that shouldn't be in there IMO. We are getting closer to 1.0, and we should clean up our act, me thinks... The CVS scripts are meant to clarify what I mean, and for Alexandre to use... (hint, hint :)) And now to the constructive part: -- get rid of old, obsolete files: Script: cvs rm -f documentation/{programs,winsock} cvs ci -m "Remove obsolete docs" documentation -- remove WineHQ stuff out of there There are other things that are on WineHQ, and they don't reside in there. Why do we keep stuff like db2html-winehq in there? If we _need_ it in there, it should be in tools/ but I don't see patch.py anywhere in the tree, and that one is used on WineHQ, so I suggest we keep all WineHQ things in one place (and outside the wine tree) Script: cvs rm -f documentation/{db2html-winehq,make_winehq} cvs ci -m "Remove WineHQ stuff" documentation -- rename installation-und-konfiguration.german We have already a README.fr, we should be consistent. Script: cp installation-und-konfiguration.german README.de cvs rm -f documentation/installation-und-konfiguration.german cvs add documentation/README.de cvs ci -m "Rename installation-und-konfiguration.german to README.de" documentation -- what's up with HOWTO-winelib? If it's already in .sgml, we should delete it. Else, we should integrate in the Winelib guide, and delete it. Anyone knows the its status? -- why do we have psdrv.reg in documentation? Shouldn't it be with the other conf files? -- documentation/shell32 should be moved as a README in the dlls/shell32 Script: cp documentation/shell32 dlls/shell32/README cvs rm -f documentation/shell32 cvs add dlls/shell32/README cvs ci -m "Rename documentation/shell32 to dlls/shell32/README" documentation dlls/shell32 -- what's up with wine.texinfo? Is it still maintained? Shouldn't we incorporate whatever is in there in the .sgml, and get rid of it? Anyone knows the its status? -- why do we have config files in documentation/samples? Shouldn't we move documentation/samples to to something like conf/ or etc/? -- the documentation/status idea was mine, but I now think it was misguided The information stays buried in there, and no one maintains it. We should salvage what's still good, and move it in a README file in the appropriate dll directory, or even directly in the .c file, where appropriate. Comments? -- Dimi.

4 6

.spec file format
by Gil Hauer Sept. 19, 2002

Sept. 19, 2002

Hello, I've reviewed the documentation on the web site as will as some of the documents in the distribution but I cannot seem to find this information. Is there a document that describes the format of the .spec files used in the dll directories? Thanks, Gil

2 1

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com Sept. 19, 2002

Sept. 19, 2002

The README section on inserting the stub dll into the wine tree seems a little out-dated. It tells me to run autoconf, but autoconf complains that it cannot find configure.in - is this step still needed? If I skip autoconf (which may be causing this problem), when I run make depend I get: cd `dirname dlls/__depend__` && make depend make[1]: Entering directory `/home/stevenlu/wine/dlls' cd `dirname errh_auto/__depend__` && make depend make[2]: Entering directory `/home/stevenlu/wine/dlls/errh_auto' make[2]: *** No rule to make target `depend'. Stop. make[2]: Leaving directory `/home/stevenlu/wine/dlls/errh_auto' make[1]: *** [errh_auto/__depend__] Error 2 make[1]: Leaving directory `/home/stevenlu/wine/dlls' make: *** [dlls/__depend__] Error 2 I ran the install script that winedump produced, but maybe that's not up-to-date with respect to the current wine build process? Or am I just doing something else wrong? -Steve Jon Griffiths <jon_p_griffiths To: Steven Edwards <steven_ed4153(a)yahoo.com> @yahoo.com> cc: wine-devel(a)winehq.com Sent by: (bcc: Steve Lustbader/ANR/MS/PHILIPS) wine-devel-admin Subject: Re: WineLib and DLLs @winehq.com Classification: 09/12/2002 05:58 PM Please respond to jon_p_griffiths Hi, >I'm writing a WineLib DLL that makes calls in my own Windows DLLs >(not Wine's DLLs). I have the header files for those DLLs, and the >Windows binaries for them. How do I link to them? Do I need to wrap >them in spec files? What do I need to put into my Makefile.in? look at tools/winedump. In spec mode it will generate everything you need to link to this dll - a makefile and dummy implementation, spec file and a script to insert it into your existing WINE tree (to link with). The README gives instructions for exactly this case (and some other more advanced ones). Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 1

Parent notifications
by Dimitrie O. Paun Sept. 19, 2002

Sept. 19, 2002

I've found this in control/edit.c HWND hwndParent; /* Handle of parent for sending EN_* messages. Even if parent will change, EN_* messages should be sent to the first parent. */ Is this true for all controls? Common controls as well? Can someone with a Windows box experiment, and see what's going on? TIA, Dimi.

1 0

Re: Direct3D v8 - Try2
by Alexandre Julliard Sept. 18, 2002

Sept. 18, 2002

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes: > I have made the above change and got it working (eventually!), and tidied up > a few other typos, functions etc. > > What is your feeling about using this as a starting point in the wine tree - > There are a number of places in the code which need work, but it would > enable others to start adding to it. Alternatively if there are any areas > you want fixed before it can go in, let me know and I'll see what I can do - > I dont fell 100% 'qualified' in this area, some of it is scrabbling around > in the manuals until I get something working! I have no problem putting it in the tree, even if it's a bit broken it's always a lot better than nothing. I'd prefer that you clean up a bit the file structure first though: you should try to group related interfaces in the same file, and cut down on the number of files, especially .h files. Anything that isn't used by multiple files should be declared static inside a single .c file. Also please don't use interface names for file names, use simpler (and lowercase) names like texture.c or buffer.c. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winaspi + libscg
by Rolf Kalbermatter Sept. 18, 2002

Sept. 18, 2002

>>I'm working on a rewrite of the winaspi module, using Joerg Schilling's >>libscg. (libscg is a scsi transport library, with support of many platforms, >>cdrecord, cdrdao uses it). I'm nearly finished, but I could test only >>winaspi32 (with nero and isobuster), I need a software that uses the 16 bit >>aspi interface to test it. Anyone knows such a software that uses wnaspi.dll? > >I don't think you will find too many of this type (16 bit software using >aspi) due to the fact that the aspi interface is newer than the 32 bit api. I'm not exactly sure about the historical timeframe but ASPI was quite early available for Win 3.1. At that time it was an Adaptec user space DLL calling into their low level driver. With Windows NT a 32 bit variant was released but I'm not sure if that was initially from Adaptec or MS, reusing most of the API definitions created by Adaptec safe from some 16 bit<->32 bit differences. However as the ASPI interface for Win 3.1 was indeed a proprietary solution few other manufacturers felt compelled to support it and consequently few applications safe from the Adaptec utilities made real use of it. But most standdard applications really just went through the BIOS in Win 3.1 for drive access. I do have somewhere an old Win 3.1 installation on a old HD which I could try to dust of and there were a few smaller applications from Adaptec such as a SCSI bus probe which made use of it. However it may be quite possible that you won't get them running on a modern system even before it tries to access Winaspi. Rolf Kalbermatter

1 0