- wine-devel - winehq.org

Unable to compile current CVS
by Ann and Jason Edmeades 29 Sep '02

29 Sep '02

No, we should be able to compile withiout mesa if we did before my patch. Unfortunately I dont know how to do this (I did warn alongside my patch) - Is there any chance you could work out how dlls/ddraw handles this issue so we can do the same. I suspect for non-gl enabled machines (until we go via a HAL) we should hava a d3d8.dll which just returns an error on the Direct3DCreate8 call. Jason

1 0

ToDo's
by Thomas Wickline 29 Sep '02

29 Sep '02

Hello, Here is the changes to ( National Language Support ) Does it look alright with everyone ? If not let me know and ill patch it again . Everything else is the same I removed BiDi from Aspect or Component: as well. Tom ---- Wine ToDo's as of 9/29/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management: * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support: * Make sure ASCII functions call the Unicode one and not the other way around. * BiDi support * Add support for Hebrew and Arabic * Add support for more keyboard layouts to x11drv * Figure out what should be done for better support of Chinese, Korean, Japanese -- snip

1 0

Re: wineoss patch
by Eric Pouech 29 Sep '02

29 Sep '02

Ove Kaaven a écrit : > > I can imagine Eric has a better patch for the following problem: > OSS/Commercial does not allow an open device to continue operation after a > SNDCTL_DSP_RESET, the device must be reopened (which is what their API > docs recommend). The following patch is what we have in WineX to get > around the issue, but it will only compile on ReWind and Wine if the > #define FULL_DUPLEX is enabled. But perhaps it's good enough if Eric > doesn't have a better one. And I have some fullduplex patches that I can > only submit after this issue is resolved. I think the best way is to store device parameters in all cases (full duplex or not) and then make use of them (transform the reset in close/open pair) moreover, full duplex infra has been around for a while, and didn't generate much complains... so I think we can remove now the support for the non FULLDUPLEX part finally, wine now as a notion of OSSDEVICE (shared by wavein and waveout) which could make some function defs a bit simpler I'll try to whip something out from Ove's first patch A+

1 0

Re: Implement {G|S}etWindowLongPtr
by Eric Pouech 29 Sep '02

29 Sep '02

György 'Nog' Jeney a écrit : > > Apply this patch and observe nearly the whole wine recompile :) > > ChangLog: > * include/winuser.h > * win/win.c > Implement {G|S}etWindowLongPtr I don't want to see a whole wine recompilation every day, so I think those defs #define SetWindowLong WINELIB_NAME_AW(SetWindowLong) +LONG_PTR WINAPI SetWindowLongA(HWND,INT,LONG_PTR); +LONG_PTR WINAPI SetWindowLongW(HWND,INT,LONG_PTR); +#define SetWindowLongPtr WINELIB_NAME_AW(SetWindowLongPtr) should be instead #define SetWindowLong WINELIB_NAME_AW(SetWindowLong) +LONG_PTR WINAPI SetWindowLongPtrA(HWND,INT,LONG_PTR); +LONG_PTR WINAPI SetWindowLongPtrW(HWND,INT,LONG_PTR); +#define SetWindowLongPtr WINELIB_NAME_AW(SetWindowLongPtr) A+

1 0

Exception while trying to install winace 2.2
by György 'Nog' Jeney 29 Sep '02

29 Sep '02

While trying to get the winace 2.2 installer to run on wine, I got the following exception without any messages on the console: First chance exception: page fault on read access to 0x23c94fed in 32-bit code (0x23c94fed). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:23c94fed ESP:40682e52 EBP:00400000 EFLAGS:00010646( R- 00 DI Z- -P1 ) EAX:00000000 EBX:40682e66 ECX:0000038b EDX:00420654 ESI:00000001 EDI:0044efb5 Stack dump: 0x40682e52 (_end+0x32cc32): 004209e2 40682e98 00420658 00000000 0x40682e62 (_end+0x32cc42): 00000000 00463047 0042066b 40682f44 0x40682e72 (_end+0x32cc52): 00463000 401111c0 00000001 40682f38 0x40682e82 (_end+0x32cc62): 40682e96 400fd024 00463042 00000600 0x40682e92 (_end+0x32cc72): 00463000 2f440246 c81a4068 66b12fc3 0x40682ea2 (_end+0x32cc82): c19d6f8a 25b92f81 51634d58 33c04011 0x40682eb2 (_end+0x32cc92): 0011: sel=008f base=401133c0 limit=00000fff 32-bit rw- Backtrace: =>0 0x23c94fed (_end+0x1bc38885) (ebp=00400000) 1 0x00000002 (ebp=00505a4d) *** Invalid address 0x00505a4d (wace22.exe.EntryPoint+0xa2a0b) 0x23c94fed (_end+0x1bc38885): *** Invalid address 0x23c94fed (_end+0x1bc38885) -- no code -- It seemd to me that the stack frame(s?) got corrupted so I debugged further. It seems that the app throws an exception and catches it later on. I set a breakpoint on EXC_CallHandler where the backtrace still looked fine. Just before wine calls the exception handler, it pushes edx and then edi onto the stack, then the handler gets called: call *%edx. This puts excecution into 0x420658 which calls 0x4206ac. The assembly code at 0x4206ac looks like this: 0x004206ac (wace22.exe.+0x1f6ac in C:\wace22.exe): xorl %eax,%eax 0x004206ae (wace22.exe.+0x1f6ae in C:\wace22.exe): popl %esi 0x004206af (wace22.exe.+0x1f6af in C:\wace22.exe): movl %fs:0x0(%eax),%ebx 0x004206b2 (wace22.exe.+0x1f6b2 in C:\wace22.exe): movl 0x0(%ebx),%ebx 0x004206b4 (wace22.exe.+0x1f6b4 in C:\wace22.exe): leal 0xffffffd6(%ebx),%esp 0x004206b7 (wace22.exe.+0x1f6b7 in C:\wace22.exe): popl %ebp This last pop is what makes the backtrace weird, before this the backtrace looks like: =>0 0x004206b7 (wace22.exe.+0x1f6b7 in C:\wace22.exe) (ebp=40570938) 1 0x400c84c0 (EXC_RtlRaiseException+0x10c(rec=0x405709dc, context=0x40570a34) [exception.c:214] in libntdll.dll.so) (ebp=405709c0) 2 0x400d26e9 (do_segv+0x1a5(context=0x40570d1c, trap_code=0x400d2b98, cr2=0x40570a50, err_code=0x1) [signal_i386.c:798] in libntdll.dll.so) (ebp=40570a2c) 3 0x400d2b4c (segv_handler+0x3c(__signal=0x2b, __context=0x2b) [[signal_i386.c:986] in libntdll.dll.so) (ebp=40570d28) 4 0x0000008f (ebp=00000000) But after it, it looks like this: =>0 0x004206c1 (wace22.exe.+0x1f6c1 in C:\wace22.exe) (ebp=00400000) 1 0x00000002 (ebp=00505a4d) *** Invalid address 0x00505a4d (wace22.exe.EntryPoint+0xa2a0b) Is this normal? If I just continue from this point then the first exception will be thrown but quite a lot of functions get called between here and that exception. The exception handler never does return. Any one have any ideas as to what might go wrong here? nog.

1 0

Unable to compile current CVS
by Guy L. Albertelli 29 Sep '02

29 Sep '02

It seems that the D3D8 code depends heavily on both GL/gl.h and GL/glx.h being present. My system RH 6.1 does not have those header files. Is GL a requirement for developers now?? Thanks, Guy Albertelli <<galberte(a)neo.lrun.com>> Bathed in his currents of liquid helium, self-contained, immobile, vastly well informed by every mechanical sense: Shalmaneser. Every now and again there passes through his circuts a pulse which carries the cybernetic equivalent of the phrase, "Christ, what an imagination I've got. " - Stand on Zanzibar by John Brunner

1 0

patch to MZ_Exec() PE executables
by Chris Morgan 28 Sep '02

28 Sep '02

Guess this got lost when I mailed it from my web mail account... Look reasonable? dlls/winedos/module.c: Chris Morgan <cmorgan(a)alum.wpi.edu> Add PE support to MZ_Exec().

2 1

Open-GL Mesa patches (http://cvs.winehq.com/patch.py?id=5527)
by Uwe Bonnes 28 Sep '02

28 Sep '02

Hallo, the Open-GL Mesa patches (http://cvs.winehq.com/patch.py?id=5527) in wine/dlls/ddraw/mesa_private.h unconditional inclused GL/gl.h and GL/glx.h. On my Suse V8.0 system ( with the mesa package installed and the mesa-devel package not installed) this leads to: make[2]: Wechsel in das Verzeichnis Verzeichnis »/home/bon/tmp/wine/compile/wine-realclean/wine/dlls/ddraw« gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTR ANT -I/usr/X11R6/include -o dsurface/main.o dsurface/main.c In file included from dsurface/main.c:27: mesa_private.h:32: GL/gl.h: Datei oder Verzeichnis nicht gefunden mesa_private.h:33: GL/glx.h: Datei oder Verzeichnis nicht gefunden make[2]: *** [dsurface/main.o] Fehler 1 Probably it's a bad idea to only install mesa and not mesa-devel, but I think wine should cope with this situation or at least warn the user about that. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: A problem reading configuration file
by Sylvain Petreolle 28 Sep '02

28 Sep '02

Me too. I made some programs with assembly under MS-DOS in the 90s before switching to Linux ;) > I think its normal. Findfirst finds the first entry, and findnext > returns only > the next :) > I'm sure it works that way. I have tried to check that in some > documentation, > but if I remember right then I have used those in something like > Borland > Delphi at the university. But I dont have Delphi at home... > > If that is ok, then do you have some idea, what could be the problem? > There was a patch applied few days ago on findnext... perhaps it's it. http://www.winehq.com/hypermail/wine-patches/2002/09/0243.html ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: A problem reading configuration file
by Sylvain Petreolle 28 Sep '02

28 Sep '02

Remarque : message transféré en pièce jointe. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Fix for msvcrt sscanf/swscanf
by Uwe Bonnes 28 Sep '02

28 Sep '02

>>>>> "Jukka" == Jukka Heinonen <jhei(a)iki.fi> writes: Jukka> Wine msvcrt sscanf and swscanf implementations incorrectly expect Jukka> strings to end with EOF. This crashes some applications which did Jukka> work with older versions of Wine that just forwarded msvcrt Jukka> sscanf to libc sscanf. Jukka> Changelog: Functions sscanf and swscanf now expect strings to be Jukka> terminated with null (0) instead of EOF (-1). I asked some weeks ago about the test framework for msvcrt, but nobody jumped on the waggon. The mix of msvcrt and libc was something I couldn't do myself. Perhaps somebody can come up with someting. It sure is important to codify findings like Jukkas. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: [Controversial] Developper only CVS sandbox
by Dan Kegel 28 Sep '02

28 Sep '02

I've strongly opposed to using ClearCase for Wine development :-) I'm also somewhat opposed to CVS. The big problem with CVS is that it makes it *too* easy to contribute changes, and too hard to disentangle changes later when trying to contribute them back to the main tree. (This kind of thing has caused huge nightmares in the past.) So all you folks that feel that creating and posting patches is hard -- the payoff is *each change is much easier to peer review*. That makes for much higher quality code! If you really want to use a CVS-like system, go have a look at Bitkeeper. It's free for open source projects, and it is the only source code control system that doesn't make it hard to disentangle changes later. - Dan

2 1

Re: RFC: Winsock todo's
by Dan Kegel 28 Sep '02

28 Sep '02

Martin Wilck wrote: > Although I had a relevant part in implementing the asynchronous IO in > winsock, I am not quite content with it because it is not really > asynchronous. And not really high-performance, I bet (though I wouldn't know, I haven't looked at the code or tested it). > Alexandre is against using threads. Me, too. glibc uses threads to emulate aio, and the performance is poor. On platforms that natively support AIO, I bet you *really* want to implement Wine AIO using Posix AIO if you can. > On Linux at least, Ben > LaHaise's asyncio can be expected to become part of the > 2.6 kernel series, and if that happens the wine asynchronous IO > functionality should be rewritten to use the asyncio API on systems that > support it. Yes. Exactly. > (I still havent't figured out whether aio will support > sockets, though). It will. SGI's kaio does already, and Ben's will support it when he's finished. That should give good performance. - Dan p.s. Looks like the threads implementation for the 2.6 kernel will rock, too. See http://www.kegel.com/c10k.html#threaded (Somebody remind me why Wine has its own threads implementation again? Is it because the semantics are too different from Posix threads?)

1 0

Status of *ongoing* wine improvements?
by Dan Kegel 28 Sep '02

28 Sep '02

The To-Do list Steven Edwards is putting together looks like a nice menu of Things That Need To Be Done But Have Not Been Started Yet. A similar list, of ongoing work, might be useful in a different way. Check out http://www.kernelnewbies.org/status/ It has a number of nice features: * status of each proposed enhancement (planned / started / alpha / beta / ready / merged) * each line is a link to a wine-devel post or web page describing the proposed work * each line has the names of people actually working on them * items changed since last week are bold * only items expected to be finished before the feature freeze for the next release are included This list might be pretty short for Wine, but it'd be a nice way of tracking progress. - Dan

1 0

Re: DIB engine
by Gavriel State 28 Sep '02

28 Sep '02

Ove Kaaven wrote: > Well, here is the DIB engine that a couple of people at TransGaming > (mostly David Hammerton, I think) did some work on a while ago, I finally > got around to review it and make sure it compiles against the current > ReWind (though perhaps it needs a few tweaks to compile against Wine). > It's not all that complete by any means, but we wanted to get it out > there, so feel free to comment on it (or even apply it to Wine if it's > good enough). Primary attribution should go to Jonathan Meunier, a co-op student who worked with us earlier this year. David Hammerton, Peter Hunniset, and I all assisted with it to one degree or another. If there is any general interest in pursuing DIB Engine work, we would of course appreciate it if developers are willing to license their contributions to ReWind. Ove seems to have forgotten to include the documentation, which includes some nice background on DIB issues in general, and should go into the documentation directory. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ gav(a)transgaming.com TRANSGAMING TECHNOLOGIES DIB ENGINE DOCUMENTATION (GDI RENDERER) Copyright (c) 2002 TransGaming Technologies Inc. SCENARIO -------- The Win32 API allows for a graphics format called DIBSections. DIBSections allow the application to write to the image in two ways: Direct Access and through GDI. Direct Access means that the application can simply write whatever data it likes to the image - the application has a pointer to the physical image bits, and can write to this with no problem. In ReWind's X11 Driver we can emulate this kind of access by using XImages. The GDI access allows the application to do a whole heap of extra stuff to its graphics, including special rendering such as lines, polygons, ellipses and so on. ReWind emulates such calls through the use of X11's renderer by using XPixmaps. With a DIBSection, the Win32 API allows both of these features to be used on a single image. This is currently supported by ReWind, but it can be slow at times and rather 'hacky'. This is achieved using the following method: o When a DIBSection is created, space is allocated for the application (where the application can directly write to). This is also an XImage. o Another XImage is created for 'conversions' (see depth conversion). o An XPixmap (which is a X Drawable) is created on the X Server. o The application-side data is memory protected to no access. Now, ReWind's X11 driver keeps track of which "image" is most up-to-date, it has 3 mods: gdimod, appmod and insync. (There is actually a 4th mod called 'auxmod' which is used for auxiliary tasks such as OpenGL). These mods represent different states, as follows: o gdimod means that the XPixmap has the most up-to-date version of the image, it was written to last. o appmod means that the application has the most up-to-date version, it has written the image data manually. o insync means that the both the images are up-to-date, they contain the same data. The application can then write into the memory which it is given direct access to, but when it tries to do so a segmentation fault is raised because the memory has been protected. This segmentation fault is caught by ReWind which it recognizes as an attempt to access the application data of a DIBSection. A "coercion" is now called on this DIBSection. If the DIBSection is in gdimod at the time of the segmentation fault, a copy is necessary before we allow the application to write to the DIBSection. The Pixmap is then fetched from X and placed into the XImage in the correct format. The Application is now free to write to the image data, the DIBSection is placed in appmod. A similar thing happens when a GDI painting function gets called, we ensure that the DIBSection is in gdimod (The Pixmap is up-to-date). X is then free to to its rendering. A Problem: Depth conversions and X Limitations: There are many other "nicer" ways that could, in theory, work. With some extensions X is able to render into a XImage, we could use Shared Memory Pixmaps or we could work on getting the upcoming on-the-fly X depth changing into XFree86 4.3. Unfortunately none of these are complete enough to work for our needs. One of the big things that many of them lack is palette support (8bit graphics). So, presently XPixmaps must be in the depth format that the users current X is running at. But the application only knows one way to draw to the DIBSection: The format it requested. This means we have to do depth conversions when we do our coercions from one format to another. This can be slow, particularly if we are constantly doing the conversions. One of the worst cases is when the application requested 8 bit paletted mode and X is running in 24bit mode. A copy from appmod to gdimod/insync involves indexing each color and placing it in the new XImage, then sending it over to X. A copy in the other direction involves a reverse palette lookup, for each pixel we have to cycle through the 256 possible colors and find the correct index for them. This gets quite harsh on X when doing a large image, for example take a 1024x768 screen at 24bits (padded to 32bits): That becomes a 3 megabyte copy every time, doing that often can really slow things down. DIRECT DRAW USAGE ----------------- One important use of DIBSections is DirectDraw. Although games may not explicitly use DIBSections themselves, ReWind does. In Rewind a DirectDraw surface is basically a DIBSection. This is because DirectDraw can be used much like a DIBSection: The application can draw directly to it, yet Win32 can still do GDI rendering to it. For this reason many Win32 DirectDraw applications suffer serious performance problems as a result of DIBSections. Several games you may wish to look at are StarCraft (not too bad because it uses a 640x480 surface) and Age of Empires 2 (badly effected, as it uses a 1024x768 paleted surface). A BETTER SOLUTIONS: THE DIBENGINE --------------------------------- A better solution for this problem has constantly been discussed and is the DIB Engine. The purpose of the DIB Engine is to implement a fully functional GDI renderer capable of doing all the things X is presently used for, plus others which are currently unimplemented in any way. The DIB Engine would basically be able to take care of all GDI rendering when needed itself by rendering into the application memory (at the depth requested by the application). This would save on the copying backwards and forwards most of the time. (Although we would still have the copy to X when blitting to the primary surface). A DIBEngine has to implement a lot of functionality and must include the raw functions to render things like lines, polygons, ellipses and so on to the image. Another functionality of a DIBEngine should be to understand the ROP modes given to the various blitting functions. ROP stands for Raster Operations and is a method by which an application can make customize a blit fairly extensively. In Win32 there are two types of ROP's: Binary ROP's and Tenerary ROP's. Tenerary ROP's allow for up to 256 different types of blitting and are described by a string in reverse polish notation. An example Tenerary ROP could be DPSoo which is described as "Destination OR'd with Brush (pattern) OR'd with Source" and then blitted into the source. That is a fairly simple ROP3 code. Currently there is no suitable external library which could be exploited to make a DIBEngine in ReWind. One of the more promising libraries, Microwindows, has problems with different depths and ultimately has to be hooked into the underlying driver and hence does not solve the problem of removing the coercions. TRANSGAMING'S DIBENGINE ----------------------- TransGaming Technologies has been developing a DIBEngine in order to finally solve all the problems discussed above. The DIBEngine developed by TransGaming is partially complete, but more work is still needed for it to be fully functional. Current features include: o Drawing of lines o Partial drawing of ellipses o Drawing of polygons (several of the implementations, such as Polygon, Polyline, etc) o Filling of polygons (including patterns) o Pattern blitting o ROP2 and ROP3 engines Most of the support is there to complete the DIBEngine, for example the incomplete primitives can make use of the pattern blitting and so on. There is still a some functionality that has to be completed, and the current TODO list is as follows: o Implement outlined and filled shapes. o Implement curved shapes (Ellipse, Chord, Pie, Arc, etc). o Complete other drawing functionality (Round Rect, SetPixal etc). o Implement the different pens (Varying thickness, dotted, geometric, etc). o Line drawing needs to implement draw_last_point flag. o Brushes can only be 8x8 in Windows 95, we need to care about this. o Implement of clipping regions (Win32 has many types of clipping including rectangles, elliptic and more). o Implement text/fonts. o Take care of SetBrushOrgEx Currently the DIBEngine only supports a 16bit X Server and 16 bit drawing this means we need to: o Implement drawing for all possible depths (modify underlying pixel draw functions only). o Support Paletted modes. o Currently X11DRV_CreateBitmap only supports the current X depth. If a DIBSection is created at 32bits, and thus we try to use a 32bit brush, the whole thing will break. We either need to do depth conversions before calling X11DRV_CreateBitmap or do something else. Some things which need fixing up include: o Find depth masks for HBITMAPs o Properly implement BitBlt/PatBlt's and StertchBlt's. BitBlt takes the destination's DC functions, but this may not be safe if the source is not a DIBSection (see the information below on hooking into ReWind). o Optimzation. Currently the DIBEngine is not as fast as X for most drawing functions. Speedups can be done in the area of the ROP parser, pixel drawing, line drawing and filling. The code contains some comments of specific areas that need work. o DLL Seperation: Ideally the DIBEngine should be placed into its own DLL. This will allow it to be used for different graphics drivers, amongst other things. HOOKING INTO REWIND ------------------- For each GDI function that exists there is a driver-specific wrapper function that does some simply checking / optimizing / calculations before sending it onto the drivers specific rendering functions. For the X11DRV these exist in graphics/x11drv/graphics.c. This is where we divert calls to the DIBEngine when necessary. For speed optimizations (minimizing the number of coercions that take place) we put several conditions on which renderer to use. If the DIBSection is in gdimod (eg, Pixmap is most up-to-date) we use the drivers (eg, x11's) renderer; if the DIBSection is in appmod we use the DIBEngine. It should be noted that by doing this, the term 'gdimod' is now redundant because infact a DIBSection could be in appmod yet have been last modified by a GDI function.

1 0

Re: DIB engine
by Huw Davies 27 Sep '02

27 Sep '02

On Sat, Sep 28, 2002 at 01:11:57AM +0200, Ove Kaaven wrote: > Well, here is the DIB engine that a couple of people at TransGaming > (mostly David Hammerton, I think) did some work on a while ago, I finally > got around to review it and make sure it compiles against the current > ReWind (though perhaps it needs a few tweaks to compile against Wine). Well I haven't looked at it yet, but hey cool guys! Cheers! Huw.

1 0

minor typo in winemaker
by Bill Medland 27 Sep '02

27 Sep '02

1 0

Printing with CUPS
by Mason Kidd 27 Sep '02

27 Sep '02

I'm having trouble printing using CUPS. When I try and print in notepad I get a dialog saying: Cannot print the Untitled file. Be sure that your printer is connected properly and use Control Panel to verify that the printer is configured properly. My setup is Redhat 7.3 with the following CUPS packages: cups-libs-1.1.14-15 cups-drivers-hpijs-1.1-0.20020313.3 cups-devel-1.1.14-15 cups-drivers-pnm2ppa-1.1-0.20020313.3 cups-1.1.14-15 cups-drivers-1.1-0.20020313.3 I am printing to a HP Laserjet 1100 using the "HP LaserJet 1100, Foomatic + gimp-print" driver. This is setup to print using IPP to a print server that is also running CUPS(same version). I have not modified any of the printing or fonts options in the wine config file, since the instructions say it is automatic. I am printing from Notepad. Doing a trace of the PSDRV, it reads all of the AFM files and detects the fonts ok. Also, during ParsePPD it finds all of the paper sizes correctly. But then I get a message: trace:psdrv:PSDRV_FindPrinterInfo No 'Paper Size' for printer 'hplj1100' trace:psdrv:PSDRV_FindPrinterInfo No 'FontSubTable' for printer 'hplj1100' And then when it tries to print: trace:psdrv:PSDRV_CreateDC (WINEPS hplj1100 LPT1: (nil)) trace:psdrv:PSDRV_UpdateDevCaps ImageableArea = 0,0 - 0,0: PageSize = 0x0 trace:psdrv:PSDRV_UpdateDevCaps devcaps: horzSize = -2147483648mm, vertSize = -2147483648mm, horzRes = 0, vertRes = 0 Which doesn't seem right. It then selects the pen and brush, and looks like it will print, and the it calls DeleteDC. I have attached the full trace, with +psdrv and +commdlg. It really seems like it is almost working, but something is wrong with the paper size. How can I find why it sets everything up and then deletes the DC? Anyone have any ideas? Mason Kidd

1 0

Re: dx8 submission
by Sylvain Petreolle 27 Sep '02

27 Sep '02

Hi Jason, I tried to compile your directx8 code.(try 3) For now it doesn't compile, complaining about wine_gl.h. Relevant part of 'make depend' log : make[2]: Entre dans le répertoire `/home/wine/dlls/d3d8' ../../tools/makedep -I. -I. -I../../include -I../../include -C. d3d8_main.c directx.c device.c resource.c vertexbuffer.c indexbuffer.c volume.c swapchain.c surface.c basetexture.c texture.c cubetexture.c volumetexture.c wine_gl.h: No such file or directory wine_gl.h was first included from d3d8_private.h:9 d3d8_private.h was first included from d3d8_main.c:25 Where could I find this file ? I have latest CVS and didn't find it. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

4 6

interprocess messages
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

Hi folks, As I was browsing aimlessly (not quite, but for the purpose of the story, it'll do :)) through windows/win.c, I run into this: /******************************************************************* * GetWindowTextW (USER32.@) */ INT WINAPI GetWindowTextW( HWND hwnd, LPWSTR lpString, INT nMaxCount ) { if (WIN_IsCurrentProcess( hwnd )) return (INT)SendMessageW( hwnd, WM_GETTEXT, nMaxCount, (LPARAM)lpString ); /* when window belongs to other process, don't send a message */ if (nMaxCount <= 0) return 0; get_server_window_text( hwnd, lpString, nMaxCount ); return strlenW(lpString); } My question is: shouldn't we alwas call WM_GETTEXT here, and do the switch between current process/other process in the lower levels? What if the application sends the WM_GETTEXT message, and bypasses the GetWindowTextW? Then it wouldn't work, right? Just curious how all these are gonna play out... -- Dimi.

2 1

How to tell winemaker and winebuild what I want to tell it
by Bill Medland 27 Sep '02

27 Sep '02

Anyone able to tell me what I am doing wrong here before I spend days trying to figure it out? My winelib wrapper wants to call MultiByteToWideChar and DOSFS_GetFullName. As far as I am aware they are available from ntdll.dll (ntdll.dll.so) So I want to to get the build to "link" to ntdll.dll I thought it should simply require "-intdll" in the argument to winemaker, but during the link I still get complaints about not finding those two functions. What am I doing wrong? Bill p.s. Thanks to Francois for the fixes to Winemaker

2 5

patch to MZ_Exec() PE executables
by chrismorgan＠rcn.com 27 Sep '02

27 Sep '02

Look reasonable to all of the experts? ;-) dlls/winedos/module.c: Chris Morgan <cmorgan(a)alum.wpi.edu> Add PE support to MZ_Exec(). Index: module.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.21 diff -u -r1.21 module.c --- module.c 30 Aug 2002 00:03:25 -0000 1.21 +++ module.c 27 Sep 2002 18:33:58 -0000 @@ -342,14 +342,54 @@ */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { + DWORD binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + /* 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? */ 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 PE executables */ + if(binType == SCS_32BIT_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); + + cmdline[strlen(cmdline) - 1] = 0; /* 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); + return TRUE; + } else + { + FIXME("EXEC type of %d not implemented for PE executables\n", func); + return FALSE; + } + } /* if(binType == SCS_32BIT_BINARY) */ + + /* handle dos executables */ switch (func) { case 0: /* load and execute */ case 1: /* load but don't execute */

1 0

InitThreadInput16
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

OK, This DLL stuff is a bit confusing. In dlls/user/user32.spec we have 409 pascal16 InitThreadInput(word word) InitThreadInput16 so the exported name is InitThreadInput, right? Then how come in ./dlls/x11drv/desktop.c we call it like so: win->hmemTaskQ = InitThreadInput16( 0, 0 ); Shouldn't this yield an error? -- Dimi.

2 5

WM_STYLECHANG{ING/ED}
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

Hi folks, In my relentless quest for speed :), I discovered that we don't send a WM_STYLECHANGED message when we flip the WS_VISIBLE, or WS_VSCROLL, and maybe a bunch of others, I haven't checked. Shouldn't we send such a message, when we touch *any* WS_[EX_]* bits? -- Dimi.

2 3

-gstabs and '#warning "8 as alignment is not supported"'
by Greg Turner 27 Sep '02

27 Sep '02

OK, I did this: Index: configure =================================================================== RCS file: /home/wine/wine/configure,v retrieving revision 1.341 diff -u -r1.341 configure --- configure 25 Sep 2002 03:29:55 -0000 1.341 +++ configure 27 Sep 2002 15:20:40 -0000 @@ -1998,7 +1998,7 @@ CFLAGS=$ac_save_CFLAGS elif test $ac_cv_prog_cc_g = yes; then if test "$GCC" = yes; then - CFLAGS="-g -O2" + CFLAGS="-gstabs -O2" else CFLAGS="-g" fi and sure enough, debug symbols loaded for me. The only remaining annoyance: winedbg doesn't automagically find the sources like gdb. Presumably, I can fix this by issuing "dir" commands to winedbg. So I'm happy (although it'd be nice to not have to issue those "dir" commands). Thanks! Can anyone think of a reason not to submit this as a patch? I tried -gstabs in gcc 2.96 (the only other gcc readily available to me) and it was happy, so presumably its pretty portable, and it looks like the configure change above would only apply to gcc, which seems like precisely the right thing to me. Now one other question for y'all wine gurus out there: I was looking for the alignment issue I mentioned before, and it turns out not to be an "-malign=" problem like I was suspecting. Instead, I was seeing "8 as alignment is not supported" warnings from include/pshpack8.h: # if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) || defined(_MSC_VER) # pragma pack(8) # warning "8 as alignment is not supported" # elif !defined(RC_INVOKED) # error "Adjusting the alignment is not supported with this compiler" # endif I don't understand, if the alignment isn't supported, why the #pragma pack(8) is there...? Anyhow, since it looks like everybody using gcc gets the same warning, it's probably not a gcc3.2 bug... but I was wondering if anyone could clarify what's going on, and whether this indicates a problem in crypt32.dll.so (the affected wine dll). Thanks for your patience and help, -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

1 0

Re: winemaker: wineapploader changes
by Alexandre Julliard 27 Sep '02

27 Sep '02

Francois Gouget <fgouget(a)codeweavers.com> writes: > However, looking for wine in bindir does not make sense: > * I don't install the Winelib applications I compile using Winelib. So > * I leave prefix to the default value: /usr/local > > * I always build my application using a Wine source tree. This means > * that there is strictly nothing of interest in /usr/local/bin. > > * configure.ac goes to great length to figure out where wrc, winebuild > * and *wine* are located. So at the end of configure.ac we know very > * well what the path to wine is. It's '$WINE'. There seems to be some confusion here. We have two very different problems: one is how to make things work on the build machine, and one is how to make things work when installed. configure can only detect where things are on the build machine, but in general that's not the right paths to put in the installed binaries. The installed stuff goes in $(prefix), and I think it makes sense to expect that Wine itself will be installed there too. Note that in Wine wineapploader is only used for make install; running from inside the tree is a different problem and is done by a different script. I think winemaker should do the same thing. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winedbg is not finding debug symbols, anybody know what I'm doing wrong?
by Greg Turner 27 Sep '02

27 Sep '02

Eric POUECH wrote... > but I assume you double checked that more likely, aren't you using gcc 3.2 > by any chance ? if so, you need to force ELF symbol emission, not > Dwarf II which became default in 3.2 Bingo. Guilty as charged. Thank you SO MUCH for this, I should have figured gcc3.2 was the culprit, that thing is feisty! I'll take a look at whether I can find a generic solution to this and post a patch. Now that you mention it, I think gcc3.2 has some other interesting warnings, something about some alignment thingys not supported anymore (probably I just change "-m$X" to "-f$X" to fix), I'll see about those too, could well be important... -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

2 1

Re: Unimplemented function... Cause of exception?
by Andriy Palamarchuk 27 Sep '02

27 Sep '02

--- John Coppens <jcoppens(a)usa.net> wrote: > Hello. > > I'm trying to run WinPLACE with the last wine > package. The composition part > works, but the compiler doesn't. I get: > > fixme:int:DOSVM_Int10Handler Get Font Information - > Not Supported (BH: 0x0) > wine: Unhandled exception, starting debugger... The fixme message may or may not have the relation to the exception. What does debugger say about the exception? Run "bt" (backtrace) command in the debugger window and report what you found. Also you can get more information about the cause of the crash from relay trace. See: http://www.winehq.org/docs/wine-devel/dbg-param.shtml http://www.winehq.org/fom-meta/cache/266.html Andriy Boston, MA, USA As an employee of an oil company, let me assure you that nothing, and I mean NOTHING scares a big company more than a noisy, smelly, obnoxious, disaffected pressure group. Now go away and chain yourself to someone important's front door. TheRegister. Unknown __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com

2 1

Where is the specfile documented nowadays?
by Bill Medland 27 Sep '02

27 Sep '02

I've just come back to WineLib after a long time and discovered that things have changed a bit. (As a result my code finds the builtin dll but complains that it loaded the so but the dll is not found; I guess it hasn't been named or something) I guess we need to update the winelib documentation and the "binary dlls" part. As I understand it the spec file format has changed significantly over the past year and half the contents go somewhere else. In particular all that seems to go in the spec file nowadays is the entrypoint and the actual functions. Can someone point me at the current documentation or is there none. Bill

4 8

dlls/xxx/xxx_main.c
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

Can we please rename all these dlls/xxx/xxx_main.c to dlls/xxx/xxx.c It should be possible now, right? Should I send a patch in? -- Dimi.

2 1

[Controversial] Developper only CVS sandbox
by Lionel Ulmer 26 Sep '02

26 Sep '02

Hi all, As Dimi is not the only one that can start flames on wine-devel, let's start a new one :-) When I see the work that is starting to go on on D3D8 or even on my old D3D code, I think that it would be nice if there was some CVS 'sandbox' where Wine developper could interact on shared code without going the Alexandre round-trip. This would be much less painful than sending patches back and forth between developpers. This sandbox would be closed (ie it would be a developper only Wine tree) to NOT start another Wine fork and all development on this sandbox would be merged back in Wine when they are ready (and then would still go the Alexandre way of course). Now, what does the Wine community think about this ? If people agree, what would be the best way to handle this ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

5 5

winedbg is not finding debug symbols, anybody know what I'm doing wrong?
by Greg Turner 26 Sep '02

26 Sep '02

Whenever I run winedbg (or when wine runs it in response to an exception), it fails to find debug symbols. Looking at disassembled code is making my brain numb. I "export STRIP=false" before configure to ensure that the Makefile doesn't strip anything, and gdb finds everything just fine. So what am I doing wrong? The doc says winedbg should know all about this, and I see examples of people's winedbg runs on the internet where winedbg is automagically loading tons of symbols for them (I only seem to get libntdll.dll.so working). Here's a typical run: wine: Unhandled exception, starting debugger... WineDbg starting on pid 8078e48 No debug information in ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000b0a0 Loaded debug information from ELF '/usr/local/lib/libntdll.dll.so' (0x4002e000) No debug information in ELF '/usr/local/lib/libwine.so' (0x40161000) No debug information in ELF '/usr/local/lib/libwine_unicode.so' (0x4017a000) No debug information in ELF '/lib/libm.so.6' (0x40244000) No debug information in ELF '/lib/libc.so.6' (0x40268000) No debug information in ELF '/lib/libdl.so.2' (0x403a3000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) No debug information in ELF '/usr/local/lib/wine/kernel32.dll.so' (0x406e3000) No debug information in ELF '/usr/local/lib/wine/user32.dll.so' (0x407a1000) No debug information in ELF '/usr/local/lib/wine/gdi32.dll.so' (0x40909000) . . . Wine-dbg>step Single stepping until exit from function, which has no line number information. First chance exception: c0000025 in 32-bit code (0x4010b7ee). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:4010b7ee ESP:406caa70 EBP:406cab10 EFLAGS:00000246( - 00 I Z- -P1 ) EAX:406caaac EBX:40148e70 ECX:406ca754 EDX:00000000 ESI:406d0ca4 EDI:406cab1c Stack dump: 0x406caa70 (NTDLL.DLL.memcpy+0x3e1060): 406d0c9c 406cab20 406cab00 71188dc9 0x406caa80 (NTDLL.DLL.memcpy+0x3e1070): 4010b0f4 403b0814 00000000 406caa9c 0x406caa90 (NTDLL.DLL.memcpy+0x3e1080): 400c0f27 402786da 40273548 4026b208 0x406caaa0 (NTDLL.DLL.memcpy+0x3e1090): 401793e0 00000002 00000000 c0000025 0x406caab0 (NTDLL.DLL.memcpy+0x3e10a0): 00000001 406cae7c 40007f5e 00000000 0x406caac0 (NTDLL.DLL.memcpy+0x3e10b0): 40309451 016cab74 00000000 406cab20 0x406caad0 (NTDLL.DLL.memcpy+0x3e10c0): 0011: sel=008f base=4015f140 limit=00000fff 32-bit rw- Backtrace: =>0 0x4010b7ee (EXC_RtlRaiseException+0x28a in libntdll.dll.so) (ebp=406cab10) 1 0x40121c29 (NTDLL.DLL.__wine_call_from_32_regs+0xb5 in libntdll.dll.so) (ebp=406cae6c) 2 0x4010b55d (NTDLL.DLL.RtlRaiseException+0x5 in libntdll.dll.so) (ebp=406caed0) 3 0x499cd236 (URLMON.DLL.CopyBindInfo in urlmon.dll.so) (ebp=406caee0) 4 0x71119951 (BROWSEUI.DLL.EntryPoint+0x955 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406caf04) 5 0x711198fd (BROWSEUI.DLL.EntryPoint+0x901 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406cbf74) 6 0x7111988d (BROWSEUI.DLL.EntryPoint+0x891 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406ccfcc) 7 0x7112ac78 (BROWSEUI.DLL.DllGetClassObject+0x2471 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406ccfec) . . ( several winedbg commands snipped here ) . 0x499cd051 (URLMON.DLL..data+0xb051 in urlmon.dll.so): subl $4,%esp Wine-dbg>symbolfile /usr/local/lib/wine/urlmon.dll.so Reading symbols from file /usr/local/lib/wine/urlmon.dll.so Wine-dbg>list Enter path to file '': Wine-dbg>step Single stepping until exit from function, which has no line number information. . . . Whatever I do, even if winedbg makes a show of loading my symbols, it never seems to synch up with my source files, except maybe for libntdll.dll.so... anyone got ideas? Thanks, -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

2 1

Re: [patch] Listview error handling
by Dimitrie O. Paun 26 Sep '02

26 Sep '02

On September 26, 2002 12:56 pm, Paul Rupe wrote: > This fixes a problem in my previous listview patch reported by Rein Klazes. > > Changelog: > Paul Rupe <prupe(a)myrealbox.com> > Remove freed sublist on failure in LISTVIEW_InsertItemT > + HDPA hdpaSubItems = NULL; I don't understand what you want to do. Why is this needed? Why did you change the code in the first place? -- Dimi.

1 0

Re: wine/dlls/comctl32 listview.c
by Rein Klazes 26 Sep '02

26 Sep '02

On Tue, 24 Sep 2002 22:20:02 -0500, you wrote: > ChangeSet ID: 5531 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/09/24 22:20:02 > > Modified files: > dlls/comctl32 : listview.c > > Log message: > Paul Rupe <prupe(a)myrealbox.com> > - Initialize memory to prevent crashes when -debugmsg +listview is on. > - Fix various array bounds related errors. > > Patch: http://cvs.winehq.com/patch.py?id=5531 This part causes trouble here: | @@ -6591,11 +6599,6 @@ | is_sorted = (lStyle & (LVS_SORTASCENDING | LVS_SORTDESCENDING)) && | !(lStyle & LVS_OWNERDRAWFIXED) && (LPSTR_TEXTCALLBACKW != lpLVItem->pszText); | | - nItem = DPA_InsertPtr( infoPtr->hdpaItems, | - is_sorted ? GETITEMCOUNT( infoPtr ) + 1 : lpLVItem->iItem, | - hdpaSubItems ); | - if (nItem == -1) goto fail; | - | if (!LISTVIEW_SetItemT(infoPtr, lpLVItem, isW)) goto fail; | | /* if we're sorted, sort the list, and update the index */ | @@ -6606,6 +6609,14 @@ | if (nItem == -1) goto fail; | } | | + /* Add the subitem list to the items array. Do this last in case we go to | + * fail during the above. | + */ | + nItem = DPA_InsertPtr( infoPtr->hdpaItems, | + is_sorted ? GETITEMCOUNT( infoPtr ) + 1 : lpLVItem->iItem, | + hdpaSubItems ); | + if (nItem == -1) goto fail; | + | (before there were no failed calls and the list is not sorted) I did not look very hard at the cause, but it looks that LISTVIEW_SetItemT() depends on the inserted subitems in function set_main_item. Rein. -- Rein Klazes rklazes(a)xs4all.nl

3 2

RFC: Wine and PAM integration
by Andriy Palamarchuk 26 Sep '02

26 Sep '02

I played a couple of days with PAM (Pluggable Authentication Modules). I do not have big experience in this area and want to know your opinion about my ideas. *** PAM short explanation *** PAM <From PAM for Linux documentation> Linux-PAM (Pluggable Authentication Modules for Linux) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users. It is possible to switch between the authentication mechanism(s) without (rewriting and) recompiling a PAM-aware application. Indeed, one may entirely upgrade the local authentication system without touching the applications themselves. </From PAM for Linux documentation> PAM-aware application requests authorization using predefined id - PAM service name. System administrator configures the application authorization bas PAM service name identifies set of authorization parameters. For more information see http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/ Note, that application does not see parameters of the authorization process, e.g password, Windows NT domain name, authorization server. The application only knows user name and service name. *** PAM and Wine *** Integration with PAM allows Wine to provide authentication services for Windows applications through Windows API. PAM has modules for native Unix authentication, Samba, flat files, relational databases. Example: Windows ftp server application, running under Wine can be configured to use any method of authorization, provided by PAM - Windows domain, flat file, relational database. This authorization can be made different from the authorization, required to run wine itself and different from default authorization for Wine applications. Following PAM services can be configured for Wine from more general to more detailed: * PAM service for Wine itself * Default Wine Applications service - default service which provides authentication for Windows applications. Exact name of the service will be specified in the Wine configuration is used if not specified. * Application-Specific Service Name specified in the AppDefaults section of the .wine/config file for given application. Default Application service is used if not specified Questions, problems: Do we have requirement for wineserver to work across user boundaries? If no, then we probably don't need PAM service for Wine itself. As you see Wine won't know anything about NT domains. I was thinking about passing service name through domain name parameter. Example: Call LogonUser accepts lpszDomain parameter. Instead of the domain name DOMAIN1 user provides to the application PAM service name SERVICE1. PAM service SERVICE1 is configured to use Samba module for authentication in NT domain DOMAIN1. PAM provides authorization and nothing else. To get more information from the authorization provider you should access it directly. E.g. with PAM only it is impossible to get list of users, groups from Windows NT domain, which user belongs to which group. Even more, it is impossible to know that some PAM service underneath uses NT domain and name of this domain. I can't imagine how to implement with PAM scenario like this - Windows application gets list of users belonging to some group, presents it to the user, then does authentication for one of user names. On other hand it is possible to do that with Samba. It seems it is better to ingegrate Wine with each protocol individually - implement PAM-like architecture inside Wine, but this architecture will provide much more information to Wine. The downside - this is much more complex approach than PAM. Andriy __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com

3 9

Modal VB-Dialog hangs
by Fabian Cenedese 26 Sep '02

26 Sep '02

Hi I have a problem with a VB6 app. It opens a second dialog with modal flag. After this everything hangs (WaitForMultipleObject), all windows in wine are frozen. I tried to debug it, I also read the tips and hints in the FAQ for frozen programs but I still don't get it. Would be great if anybody more wise :) could have a short look at it. I made a simple testproggy, available here (project and exe): http://www.indel.ch/ftp/vbmodtest.zip I was testing with wine-20020904 with SuSE 8.0 (2.4.18) Thanks Fabi

3 4

RE: [Controversial] Developper only CVS sandbox
by Patrik Stridvall 26 Sep '02

26 Sep '02

> As Dimi is not the only one that can start flames on > wine-devel, let's start > a new one :-) Unfortunately your topic is not controversial enough. :-) > When I see the work that is starting to go on on D3D8 or even > on my old D3D > code, I think that it would be nice if there was some CVS > 'sandbox' where > Wine developper could interact on shared code without going > the Alexandre > round-trip. This would be much less painful than sending > patches back and > forth between developpers. Makes sense. > This sandbox would be closed (ie it would be a developper > only Wine tree) to > NOT start another Wine fork and all development on this > sandbox would be > merged back in Wine when they are ready (and then would still go the > Alexandre way of course). > > Now, what does the Wine community think about this ? If > people agree, what > would be the best way to handle this ? Obviously anybody that have the resources can setup a CVS server and give accounts to others. So why discuss it at all. Do it yourself or if you lack the resources try to convice somebody that do to host it for you. If people think it is a good idea they will use it and if they want write access they will ask you for an CVS account. If not, well, I think you will notice the lack of intrest... :-) In short: Action speaks louder than words. BTW, Wine already have a SourceForge account http://sourceforge.net/projects/wine/ (registered by Dimitrie it seems). Why not use it? SourceForge provides CVS access IIRC.

6 8

re: d3d8header patch
by Ann and Jason Edmeades 26 Sep '02

26 Sep '02

Hi, Just fyi, according to the msdn: http://msdn.microsoft.com/library/en-us/dx8_c/directx_cpp/Graphics/Reference /CPP/D3DX/Interfaces/ID3DXFont/ID3DXFont.asp It would appear those should go in a new header d3dx8core.h. If you need to pick them up by people who include d3dx8.h, add a #include <d3dx8core.h> into d3dx8.h. This assumes we try to keep our definitions in the same location as windows... Jason

3 3

MZ_FillPSP() in dlls/winedos/module.c
by chrismorgan＠rcn.com 26 Sep '02

26 Sep '02

I have a script that passes a long argument string when calling a command handler(command.com or other comspec replacement). This code inside of MZ_FillPSP() if(length > 126) { ERR("Command line truncated! (length %d > maximum length 126)\n", length; length = 126; } is breaking my application by truncating the 200+ character argument at 126 characters. Do we still need to truncate at 126? Afaict having more than 126 characters may exceed some command.com default. Can someone shed more light on the historical reasons behind this code and whether more intelligent truncation can be performed? Thanks, Chris

4 5

Problem Saving Template with Word 2000
by Mason Kidd 25 Sep '02

25 Sep '02

Hi, I am using Word 2000 SR-1 on a fake windows install of wine 20020904. It runs fine except for one problem. When I exit the program, it tries to save the Normal.dot file to C:\windows\Application Data\Microsoft\Templates\Normal.dot and fails, with this error: The disk is full or too many files are open. (C:\windows\...\Templates\Normal.dot) If I click on Ok, and then try to save the template to a different location, even on a different partition, it gives the same error. I see this error in my xterm: err:shell:SHGetFileInfoA pidl is null! Is this related? I found bug number 956 that talks about this. Is this where I should start? It would seem to me that this would be a bug that Codeweavers had already dealt with, so do any of you guys know where to point me? Thanks. Mason Kidd

2 3

rfc: 16bit USER function
by Michael Stefaniuc 25 Sep '02

25 Sep '02

Hello, i would like to move USER functions of the type $type WINAPI $function16(@args) { return $function(@args); } from windows/*.c to dlls/user/user16.c but i don't know if that's the right place to put them because there are already some dlls/user/*16.c files. bye michael -- 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 1

Re: RESEND: Handle shortened *optval arg. in WS_setsockopt / WS_SO_RCVTIMEO
by Greg Turner 25 Sep '02

25 Sep '02

hmm, somehow this failed to make it through to the list.... Trying again... ---- awesome, thanks for your input Rein! I am no unix sockets guru (nor, obviously, am I a winsock guru ;) so this is really helpful, I'll try and submit a revision to my revision (which is apparently already in wine). That explains the time value out I was seeing of 10,000! 3 hours sounded like an awfully long time to me so I probably should have guessed those were mili's :). Basically, from your advice, I see two options. One, the obvious one, which I'll implement for now, is to convert miliseconds-> <seconds,miliseconds> and be done with it. The other would be a "correct" solution that actually works -- judging by your post, just converting the arguments won't, and I'll need to learn a little bit more about wine-winsock to make it do the right thing. I'll do the easy thing, post it to patches, then look into do_block and get back to the list if I find that this is all beyond my abilities (a quite probable scenario ;) Thanks again for the hand-holding, keep it coming, please, as I may be somewhat "out of my league" here, and I don't want to screw up wine out of ignorance. -- Greg Turner <gmturner007(a)ameritech.net> "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993 Rein Klazes wrote: >On Tue, 24 Sep 2002 16:10:43 -0500, you wrote: > > > > >>+ if (level == SOL_SOCKET && optname == SO_RCVTIMEO && optlen < sizeof(struct timeval)) { >>+ if (optlen == sizeof(time_t)) { >>+ /* Apparently WinSock will accept a shortened struct timeval. >> >> > >In Unix the arg optval points to a struct timeval, in windows to a >(32bit) int, no mystery here. The latter is the timeout in >milliseconds. Further a non-zero timeout less then 500 (msec) is taken >as 500 msec. > > > >>+ FIXME: should we do the same for SO_SNDTIMEO? */ >> >> > >Of course, its the same issue. > > > >>+ WARN("Short struct timeval in SO_RCVTIMEO: assuming time_t\n"); >>+ tval.tv_sec = *(time_t*)optval; >>+ tval.tv_usec = 0; >> >> > >You will need to convert from milliseconds here. > > >Unfortunately this does not work (a recv timing out). The socket in >wine is non-blocking internally, any blocking will be done in the >function do_block() using a select(). SO_RCVTMO has no effect there. > >Rein. > -- Greg Turner <gmturner007(a)ameritech.net> "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

1 0

ToDo's
by Thomas Wickline 25 Sep '02

25 Sep '02

Thanks to everyone who has gave feedback on this. Here is a draft of eveything up to today. As always in need of feedback ;) Tom Wine ToDo's as of 9/25/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management: * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support: * ASCII function work Winsock: * Winsock1 calls,in particular select(),use direct system calls instead of using related wine APIs * More unit tests need to be written * Make sure OOB data is handled properly. Check client-size blocking. * WS2: "provider" interface * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec. DirectSound: * Make the latency configurable (tunable). * More intelligent prebuffering. * Complete support for hardware secondary buffers through the HAL (for a future ALSA multimedia wave audio driver). * 3D sound buffers. * Sound capture (recording). Sound drivers: * Alsa driver (on final 0.9 interface) Video: * Implement native codecs (RLE...) * DIB engine to do 32-bit graphics manipulation DDE: * Enhance memory management issues (interprocess sending) Wineconsole: * Add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) Native programs: * Winhelp: fix invocation thru WinHelp * Winedbg: make winedbg use dbghelp DLL File management: * Implement NT file namespace * UNC support * Allow flexibility in FS "mounting" (for example, SMB shares) TrueType fonts: * Libfontconfig support Tools: * Wine installation process should install and configure wine * Winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions: * Write a proper Users Guide Introduction * Documentation updates Aspect or Component: * More DLL Separation * BiDi support * Review of Wine Server Protocol * Finalize Server Protocol * PAM (Pluggable Authentication Modules) * Visual C++'s native COM support * Add DWARF2 support * Speed up PDB support * Create replacement of browser component (Internet Explorer/I Porting issues for Mingw/Cygwin/MS_VC * Better seperation of win16/32 code. * Remove/rewite win16/9x api dependancy on newer code * Remove/rewrite wineisms from code * Documentation fixes low priority items: * VxD support with dynamic loading Add links to: Tasklets: http://bugs.winehq.com/buglist.cgi?keywords=tasklet tasklist: http://bugs.winehq.com/buglist.cgi?keywords=tasklist For a full list of .9/1.0 task's

3 3

Re: ToDo's
by Steven Edwards 25 Sep '02

25 Sep '02

Eric POUECH wrote: >>Here is the status of what I have so far on the ToDo's. >>I am not sure what section to put alot of this in so I just made >>Tools , Instructions & Aspect or Component for now. >>As much feedback as possiable is welcomed . >> >> > >here's some feedback: > >Sound drivers >- Alsa driver (on final 0.9 interface) > >Video: >- implement native codecs (RLE...) > >DDE: >- enhance memory management issues (interprocess sending) > >wineconsole: >- add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) > >file management: >- implement NT file namespace >- UNC support >- allow flexibility in FS "mounting" (for example, SMB shares) >(NB: I think we should make that clearer and not keep it shadowed in the Aspect/component list) > >(native) programs: >- winhelp: fix invocation thru WinHelp >- winedbg: make winedbg use dbghelp DLL (and implement it of course) > >--8<--------- >remove the Multimedia wave audio section >SEH support has been lately enhanced, is there still known issues ? >IMO, Dwarf2 support should not be added to winedbg. use of gdb proxy should be required instead. (even if it means adding PDB support to gdb, but that'd be a better investment) > >we should make clear what the low priority items are (VxD support with dynamic loading for example) > >A+ > > I dont know if any of these are in any of the TODOs but here goes. all of these would go under porting issues for Mingw/Cygwin/MS_VC - Better seperation of win16/32 code. - remove/rewite win16/9x api dependancy on newer code - remove/rewrite wineisms from code - documentation fixes I think all of this is high priortity but I am biased =) Thanks Steven

2 2

Hand Cursor
by Gustavo Junior Alves 25 Sep '02

25 Sep '02

The "hand cursor" hotspot is in wrong position (lower-right instead in the finger). Where I find information abou how I can fix it? Thanks, Gustavo

2 1

Re: RESEND: Handle shortened *optval arg. in WS_setsockopt / WS_SO_RCVTIMEO
by Rein Klazes 25 Sep '02

25 Sep '02

On Tue, 24 Sep 2002 16:10:43 -0500, you wrote: > + if (level == SOL_SOCKET && optname == SO_RCVTIMEO && optlen < sizeof(struct timeval)) { > + if (optlen == sizeof(time_t)) { > + /* Apparently WinSock will accept a shortened struct timeval. In Unix the arg optval points to a struct timeval, in windows to a (32bit) int, no mystery here. The latter is the timeout in milliseconds. Further a non-zero timeout less then 500 (msec) is taken as 500 msec. > + FIXME: should we do the same for SO_SNDTIMEO? */ Of course, its the same issue. > + WARN("Short struct timeval in SO_RCVTIMEO: assuming time_t\n"); > + tval.tv_sec = *(time_t*)optval; > + tval.tv_usec = 0; You will need to convert from milliseconds here. Unfortunately this does not work (a recv timing out). The socket in wine is non-blocking internally, any blocking will be done in the function do_block() using a select(). SO_RCVTMO has no effect there. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 25 Sep '02

25 Sep '02

>>> Does it matter that the dll is exporting C++ classes, not straight C >>> functions? >> >>That could make things slightly more complicated, since MS and gcc use >>different name mangling systems. if you declare functions with extern "C" >>linkage you should be OK. However there are differences in how gcc and MS >>call methods on objects (and in the vtable layout etc), so in general its not >>advised to mix win32 c++ dlls with a winelib exe and vice versa (i.e you >>should implement mydll.dll as a real wine dll rather than as just a stub for >>linking). > >Actually, it's a win32 c++ app with lots of win32 c++ dlls and one winelib >c++ dll. The winelib dll depends on two other win32 c++ dlls, which the app >also depends on. I'm trying to avoid turning those other dlls into winelib >dlls, since one of them uses ATL. Am I trying to do something that can't >really be done? Is it possible to make the stub dll that winelib generates I mean take the stub that _winedump_ generates and have it forward the calls >forward calls to the win32 dll (ie, give it both the gcc mangled name and the >msvc mangled name)? > >-Steve

1 0

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 25 Sep '02

25 Sep '02

>> Does it matter that the dll is exporting C++ classes, not straight C >> functions? > >That could make things slightly more complicated, since MS and gcc use >different name mangling systems. if you declare functions with extern "C" >linkage you should be OK. However there are differences in how gcc and MS >call methods on objects (and in the vtable layout etc), so in general its not >advised to mix win32 c++ dlls with a winelib exe and vice versa (i.e you >should implement mydll.dll as a real wine dll rather than as just a stub for >linking). Actually, it's a win32 c++ app with lots of win32 c++ dlls and one winelib c++ dll. The winelib dll depends on two other win32 c++ dlls, which the app also depends on. I'm trying to avoid turning those other dlls into winelib dlls, since one of them uses ATL. Am I trying to do something that can't really be done? Is it possible to make the stub dll that winelib generates forward calls to the win32 dll (ie, give it both the gcc mangled name and the msvc mangled name)? -Steve

1 0

Re: d3d8 header patch.
by Dimitrie O. Paun 25 Sep '02

25 Sep '02

On September 25, 2002 09:13 am, Yong Chi wrote: > I gave a .txt extension this time to make sure that the attachment got > treated as a text file. =) Excellent. But you didn't send it in the right format. Do cvs diff -u include/d3d8.h You should add diff -u to your .cvsrc file. -- Dimi.

2 1

another MZ_Exec() problem...
by chrismorgan＠rcn.com 25 Sep '02

25 Sep '02

Inside of MZ_Exec() I call out to CreateProcessA() if the executable is PE. I've set the lpEnvironment parameter of CreateProcessA() to null to have it inherit the environment of the caller but this isn't working correctly. The path and other environment variables aren't being inherited. Ideas on how to either get CreateProcessA() to inherit properly or where I can find the environment settings? I noticed the env_ptr in the parmeter block but I'm unsure if this is what I'm looking for or where to find more information about it. Thanks, Chris

3 2

Re: d3d8 header patch.
by Uwe Bonnes 25 Sep '02

25 Sep '02

>Hello! >I gave a .txt extension this time to make sure that the attachment got > treated as a text file. =) Now again as a unified diff (diff -u), and everybody is hapy :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

how to declare COM class?
by Yong Chi 25 Sep '02

25 Sep '02

Hello! I am one of those lurkers who finally decide to write code after many attempts. I declared a COM class best I can from looking at other COM class but I am getting syntax errors. I could not find any guide/manual on COM development. Can someone help or point to a guide on COM development? Thanks in advance...

4 4

Re: Listview Large Icon (LVS_ICON) rewrite.
by Dimitrie O. Paun 25 Sep '02

25 Sep '02

On September 24, 2002 12:07 am, Guy L. Albertelli wrote: > This is a major rewrite of the LVS_ICON (large icon) code. Not everything > is working correctly yet. Known problems: > 1. Focus rectangles are left drawn incorrectly when scrolling window. I think I know what the problem is, I'll try to fix it. > 2. Background is incorrect for at least Outlook (white instead of grey). Hm, I don't have Outlook. Any pointers and/or ideas? > 3. Scrolling in Outlook is not correct. What's the problem with this one? I might be able to fix it... -- Dimi.

2 1

Re: [patch] Listview fixes
by Dimitrie O. Paun 24 Sep '02

24 Sep '02

On September 24, 2002 05:43 pm, Paul Rupe wrote: > - Initialize memory to prevent crashes when -debugmsg +listview is on > + ZeroMemory(&lvItem, sizeof(lvItem)); Guys, *Please* stop adding these ZeroMemory calls! They just hide bugs, it is almost always the wrong fix (for the listview at least). Alexandre, you can apply the patch, I'll go through the ZeroMemory one more time anyway... -- Dimi.

1 0

ToDo's
by Thomas Wickline 24 Sep '02

24 Sep '02

Hello, Here is the status of what I have so far on the ToDo's. I am not sure what section to put alot of this in so I just made Tools , Instructions & Aspect or Component for now. As much feedback as possiable is welcomed . Tom ----------------------- Wine ToDo's as of 9/24/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support * ASCII function work Winsock * Winsock1 calls,in particular select(),use direct system calls instead of using related wine APIs * More unit tests need to be written * Make sure OOB data is handled properly. Check client-size blocking. * WS2: "provider" interface * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec Multimedia wave audio * Open Sound System: Support for full-duplex. Fix bugs. * Drivers for other APIs (ALSA, Esound, others). DirectSound * Make the latency configurable (tunable). * More intelligent prebuffering. * Complete support for hardware secondary buffers through the HAL (for a future ALSA multimedia wave audio driver). * 3D sound buffers. * Sound capture (recording). Tools * wine installation process should install and configure wine * winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions * Write a proper Users Guide Introduction * Documentation updates Aspect or Component * More DLL Separation * BiDi support * Review of Wine Server Protocol * Finalize Server Protocol * VxD support * PAM (Pluggable Authentication Modules) * SEH support * Visual C++'s native COM support * Complete the SMB code (Server Message Block) * Implement WinNT file handling * Add DWARF2 support * Implement a DIB engine * Speed up PDB support * Network UNC path handling * Libfontconfig support * Create replacement of browser component (Internet Explorer/I Add links to: Tasklets: http://bugs.winehq.com/buglist.cgi?keywords=tasklet tasklist: http://bugs.winehq.com/buglist.cgi?keywords=tasklist For a full list of .9/1.0 task's

2 1

RFC: Winsock todo's
by Martin Wilck 24 Sep '02

24 Sep '02

This is a RFC for comments. I may currently be the "offical" winsock maintainer in wine, but I wrote only a very small part of the code. I invite everybody, especially the authors of the other parts of winsock, to comment on these opinions. On Son, 2002-09-22, 18.48 Thomas Wickline wrote: > Can you give me a update on winsock todo's ? > And any other todo that you are aware of .. I have received very few bug reports lately, so I guess the basic Winsock functionality is working. A few important patches went in after the latest CVS snapshot, though. In general, the Winsock implementation in wine has a few parts that look really hackish and would need substantial cleanup. IMO this applies to the async.c file in total, but maybe I am doing injustice to authors of that file. I just find the code is really hard to read. Things like the User-space callbacks in WSAAccept() are impossible to implement correctly because the Unix accept() system call doesn't support callbacks. I do not like the fact that some Winsock1 calls, in particular select(), use direct system calls instead of using related wine APIs, e.g. WaitforMultipleEvents(). Actually if you have sockets with overlapped IO this may cause havoc. Changing this seems to be an average-difficulty task, suitable for contributors with some insight into wine internals. I'd like to see this fixed before 1.0. There are quite a few stubs left in ws2_32.spec. Some of these can probably be implemented easily and would be good work for beginners or casual wine contributors looking for a simple task, e.g. WSADuplicateSocketW(), WSAAddressToString[AW], WSAHtonl(). More unit tests need to be written, also a nice task for people interested in Winsock. Wine has no concept of the Winsock2 "provider" interface. All calls to these functions are either stubs or dummy functions, such as WSAEnumProtocols(). I had a patch for this, but never got it ready for prime-time. It is unrealistic to support a "real" provider interface, allowing (like Windows) to hook new protocol handlers in the network stack, but at least we should pass some realistic information to clients. Should be done for 1.0. There is no such thing as a QOS or socket group concept in wine either, but these seem to be rarely-used features -> post-1.0, if needed at all. Although I had a relevant part in implementing the asynchronous IO in winsock, I am not quite content with it because it is not really asynchronous. Alexandre is against using threads. On Linux at least, Ben LaHaise's asyncio can be expected to become part of the 2.6 kernel series, and if that happens the wine asynchronous IO functionality should be rewritten to use the asyncio API on systems that support it. (I still havent't figured out whether aio will support sockets, though). A non-winsock todo that comes to my mind is support for NT security concepts such as tokens. But that would be a big one and should probably also be postponed after 1.0 Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

Re: Edit updates
by Dimitrie O. Paun 24 Sep '02

24 Sep '02

On September 24, 2002 02:09 am, Dimitrie O. Paun wrote: > This patch is trying to bring the edit.c in line > with the other controls. There is a problem with this patch, please don't apply. -- Dimi.

1 0

Using winbind with Wine
by Martin Wilck 24 Sep '02

24 Sep '02

Hello, There has been a discussion on wine-devel about using winbind for purposes like user authorization, retrieving user and group information, and more. It seemed reasonable to use PAM and NSS for the basic lookups and leave it to the sysadmin to configure these services to use winbind. Winbind offers some more functionality than that, though, such as SID lookups. Continuing along that line, it would be desirable to have a more generic interface than what winbindd currently offers - actually it would be nice to be able to access all RPC calls that samba supports through an interface like winbindd's. * Are there any plans by the Samba team to extend winbindd in this direction? * If no, would the Samba team accept patches from wine developers implementing such extensions to winbindd? * Does winbind support client requests (from the Unix side) where strings are in Unicode format, i.e. could wine pass Unicode strings from Windows applications to windbind directly? * If no, would it be possible to extend winbindd to support this without modifying the samba libraries? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

winebootup
by Raul Dias 24 Sep '02

24 Sep '02

Hi, What happened to winebootup? >From documentation/packaging.sgml: <varlistentry><term><filename>winebootup</filename></term> <listitem> <para> Winelib app to be found in programs/. It'll be called by the winelauncher wine wrapper startup script for every first-time wine invocation. Its purpose is to process all Windows startup autorun mechanisms, such as wininit.ini, win.ini Load=/Run=, registry keys: RenameFiles/Run/RunOnce*/RunServices*, Startup folders. </para> </listitem> </varlistentry> and it not under wine's tree. Does it exist? (or ever did?) Is there something similar to handle RunOnce keys? I just want to avoid doing a duplicated work. []'s Raul Dias

2 1

Re: Correct and update executable types in PathIsExe
by Jeff Smith 24 Sep '02

24 Sep '02

I was just going by what MSDN says. Screensavers (SCR) are just like regular executables with a standard (I believe) command-line arguement interface. I really know next to nothing about SCF files. BTW, my version of Windows (95-OSR-2.1) is so old, it doesn't even have .cmd -- Jeff Smith >From: Alexandre Julliard <julliard(a)winehq.com> >To: "Jeff Smith" <whydoubt(a)hotmail.com> >CC: wine-devel(a)winehq.com >Subject: Re: Correct and update executable types in PathIsExe >Date: 23 Sep 2002 11:13:43 -0700 > >.pif is clearly right, but are you sure about .scr and .scf? My >version of Windows doesn't do that. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

1 0

Re: winapi update
by Alexandre Julliard 24 Sep '02

24 Sep '02

Patrik Stridvall <ps(a)leissner.se> writes: > Fixed some issues found by winapi_check. I'd prefer that we didn't add standard headers on the dll separation hacks. We don't want to give the impression that these functions are legitimate exports. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: export {Start,End}GraphicsExposures from x11drv
by Alexandre Julliard 23 Sep '02

23 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Fundamentally, the main purpose of a USER driver is to deal > with windowing, and as such, it needs to be able to compute > invalidated areas. It thus makes sense to for it to export > functions that let you query this information. > > The start/end interface used by x11drv makes sense, and it > looks sane enough to be exported. I disagree. Graphics exposures are a very X11 specific concept, they don't belong in the generic driver interface. This kind of change leads to the approach that we used before: do everything in USER and add a few strategically placed calls to x11drv where we really need it. That's the wrong approach, because it cannot be adapted to other drivers except by adding more and more driver calls all over USER. The new approach is to put the driver in charge as much as possible; this means a lot more work is done inside the driver functions, which in turn gives a lot more flexibility. Of course reconciling that with dll separation is not always trivial, but that's part of the fun... -- Alexandre Julliard julliard(a)winehq.com

2 9

Re: Correct and update executable types in PathIsExe
by Alexandre Julliard 23 Sep '02

23 Sep '02

"Jeff Smith" <whydoubt(a)hotmail.com> writes: > Looking at PathIsExe, I thought PID was probably supposed to be PIF > (Program Information File). I checked MSDN, and found this was the > case. I also found two more types that need to be recognized: SCR > (SCReensaver) and SCF (Shell Command File?). .pif is clearly right, but are you sure about .scr and .scf? My version of Windows doesn't do that. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Correct and update executable types in PathIsExe
by Rolf Kalbermatter 23 Sep '02

23 Sep '02

>Jeff Smith" <whydoubt(a)hotmail.com> writes: > >> Looking at PathIsExe, I thought PID was probably supposed to be PIF >> (Program Information File). I checked MSDN, and found this was the >> case. I also found two more types that need to be recognized: SCR >> (SCReensaver) and SCF (Shell Command File?). > >.pif is clearly right, but are you sure about .scr and .scf? My >version of Windows doesn't do that. It doesn't do it always. I had it once and disabled it immediately since I use an application with its own .scf file types. When enabled it captors the scf files directly on shell level and it wasn't possible to select scf files in the file dialog anymore!!! They are really text files in the way of Ini files. It may be possible that it comes with certain versions of Internet Explorer or Active Desktop or whatever. The scf extension when enabled is linked to SHCmdFile which starts explorer.exe without command arguments and then probably passes a DDE execute command to App: Folders, Topic: AppProperties with the command [ShellFile("%1","%1",%S)]. It is therefore not a Windows executable but really a shell extension feature. SCR files really are special exes. They are usually started by the screen saver control panel or system and not by a user double click. Windows adds links to the HKR keys to execute them as executable but again this happens on the shell level and not in the kernel. The file without any arguments started should display the configuration dialog if any. For the Test case the shell calls the file with argument /S. Installation is done by calling "rundll32.exe desk.cpl,InstallScreenSaver %l". I would not recommend trying to enable scf files at all in Wine. They are certainly no executables. I have no idea how the Wine pholosophy is in terms of enabling and supporting Windows shell features in Wine itself. It seems not useful to do that other than in the internal Wine browser/explorer eventually with help of Shell32. I would believe that Windows makes those types only indirectly executable through their registry entry and the shell which can interprete and resolve them. Rolf Kalbermatter

1 0

Name Mangling in WineLib
by steve.lustbader＠philips.com 23 Sep '02

23 Sep '02

I'm building a WineLib dll in C++ that gets called by a Windows app run by wine. Is there a way to specify how exported function and class names get mangled when compiling with winelib? The Windows app expects MSVC mangled names, so it can't find the exported symbols in my dll, since the names are mangled differently. I'd like to be able to make my dll export the MSVC style names, instead of g++ names. I think spec files used to provide similar functionality, but not any more... -Steve

1 0

PE support in MZ_Exec() /winedos/module.c
by Chris Morgan 23 Sep '02

23 Sep '02

I have a .com application that is calling out to dos int21 4Bh to load and execute a program. MZ_Exec assumes this program is always going to be a dos executable and the application fails to run and complains that it is a pe executable. So I've started to try and add support for correctly handling pe executables. So far I have a patch like below but I'm thinking that a lot more needs to be done in order to fulfill the dos requirements of this function and kind of wanted some opinions on this. This compiles but I haven't tested it since the program is at work, just wanted to get some feedback. Thanks, Chris 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 22 Sep 2002 03:28:00 -0000 @@ -39,6 +39,7 @@ #endif #include "windef.h" #include "wine/winbase16.h" +#include "wine/winbase.h" #include "wingdi.h" #include "winuser.h" #include "winerror.h" @@ -342,16 +343,29 @@ */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { + enum binary_type binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + /* 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? */ HANDLE hFile = CreateFileA( filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); BOOL ret = FALSE; + + binType = MODULE_GetBinaryType(hFile); + if (hFile == INVALID_HANDLE_VALUE) return FALSE; switch (func) { case 0: /* load and execute */ + if(binType == BINARY_PE_EXE) + { + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, filename, NULL, NULL, FALSE, + 0, NULL, NULL, &st, &pe); + } case 1: /* load but don't execute */ { /* save current process's return SS:SP now */

4 3

Standard load address for a Win32 program (0x00400000) not available
by Per Wigren 23 Sep '02

23 Sep '02

Hi! I'm trying to run Streambox VCR, but I get this error: err:win32:do_relocations Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load 'F:\x\vcr.exe' as Win32 binary I DO have some security-patches in the kernel.. If that is the problem, what patches should I disable? Regards Per Wigren

2 2

GetCursorPos & NTCurrentTeb question
by Rick Romero 23 Sep '02

23 Sep '02

I'm trying to track down the buttonup issue for Foxpro, and I've found an inconsistency, but I can't track it down. I started with GetCursorPos. It assigns PosX to pt->x, and PosY to pt->y, then calls X11drv.GetCursorPos, and assigns the current mouse coords to pt->x and pt->y. The problem is when the button is clicked, PosX and PosY retain the original values forever: A second or so after the left button is clicked: *Input.c current GetCursorPos (490,172) && (490,172) PosX,PosY && pt->X,pt->y *Button1Mask / state 256 / 16 (button is now up) *trace:cursor:X11DRV_GetCursorPos pointer at (489,186) (Where X says the pointer is) *-userdrivercall complete- (X11) Now: (490, 172)- 489,186- PosX,PosY && pt->X,pt->y (* my traces are just printf's) Even though the values are updated, they never get reassigned to PosX and PosY. I'm not sure WHERE that's supposed to happen, nor have I been able to figure out where GetCursorPos is called from. Is it possible that the values, and GetCursorPos are dealt with INTERNAL to MS FoxPro? I also am finding that the Wine server is returning Status Pending, then Status Timeout in WaitforMultipleObjectsEX in synchro.c. This happens a couple times when FoxPro starts up, but is eventually 'broken' out of. The Status_Pending triggers a call to wait_reply() in WaitforMultipleObjectsEx which does: ret = read( NtCurrentTeb()->wait_fd[0], &reply, sizeof(reply) ); GetCursorPos is called about 180 times before ret is set. I can't seem to find any reference to NTCurrentTeb in Wine (grep -nr), even though I found mention of it in the archive. Seems like an internal OS call. I don't know what's calling GetCursorPos, I don't know where pt->x gets assigned to PosX (but that's just a side effect, the mouse moves, it's the button that's stuck), and I don't know why wait_reply is getting a STATUS_TIMEOUT. Any ideas for me? Thanks, Rick

1 0

Re: Listview updates
by Dmitry Timoshkov 23 Sep '02

23 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > @@ -1034,13 +1035,13 @@ > /* Update Vertical Scrollbar */ > nListHeight = infoPtr->rcList.bottom - infoPtr->rcList.top; > scrollInfo.fMask = SIF_POS; > - if (GetScrollInfo(infoPtr->hwndSelf, SB_VERT, &scrollInfo) == FALSE > + if (GetScrollInfo(infoPtr->hwndSelf, SB_VERT, &scrollInfo) Exclamation mark (!) is missing... -- Dmitry.

1 0

wininet test fails under Win2K SP3 - compiled with gcc 3.2
by Steven Edwards 23 Sep '02

23 Sep '02

$ ./wininet_test.exe http http.c:86:Starting with flags 0x10000000 http.c:88:InternetOpenA <-- http.c:91:InternetOpenA --> http.c:95:InternetConnectA <-- http.c:74:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0022EB 34 4 http.c:98:InternetConnectA --> http.c:103:HttpOpenRequestA <-- http.c:74:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0022ED A4 4 http.c:109:HttpOpenRequestA --> http.c:111:HttpSendRequestA --> http.c:118:HttpSendRequestA <-- http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESOLVING_NAME(10) 0119FB DC 15 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_NAME_RESOLVED(11) 0119FBC C 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0119FC48 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0 119FDDC 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000 000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0119FD84 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 011 9FE04 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 011 9FE40 8 http.c:125:Option 0x17 -> 1 0 http.c:129:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:134:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Mon, 23 Sep 2002 06:45:41 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html http.c:139:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:143:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) http.c:148:Option 0x1 -> 1 text/html http.c:151:Entery Query loop http.c:168:ReadFile -> 1 743 http.c:168:ReadFile -> 1 7728 http.c:157: Test failed: InternetQueryDataAvailable failed http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 011 9FE40 8 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CLOSING_CONNECTION(50) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTION_CLOSED(51) 000 00000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 5C 4 http.c:74:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 8C 4 http.c:176: Test failed: InternetCloseHandle failed http.c:86:Starting with flags 0x0 http.c:88:InternetOpenA <-- http.c:91:InternetOpenA --> http.c:95:InternetConnectA <-- http.c:74:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0022EB 34 4 http.c:98:InternetConnectA --> http.c:103:HttpOpenRequestA <-- http.c:74:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0022ED A4 4 http.c:109:HttpOpenRequestA --> http.c:111:HttpSendRequestA --> http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0022EBEC 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0 022EBC8 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000 000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0022ECD0 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 002 2ECB4 4 http.c:118:HttpSendRequestA <-- http.c:125:Option 0x17 -> 1 0 http.c:129:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:134:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Mon, 23 Sep 2002 06:45:41 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html http.c:139:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:143:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) http.c:148:Option 0x1 -> 1 text/html http.c:151:Entery Query loop http.c:168:ReadFile -> 1 743 http.c:168:ReadFile -> 1 436 http.c:168:ReadFile -> 1 3728 http.c:168:ReadFile -> 1 644 http.c:168:ReadFile -> 1 3736 http.c:168:ReadFile -> 1 2097 http.c:168:ReadFile -> 1 403 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 5C 4 http.c:74:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 8C 4 http.c:176: Test failed: InternetCloseHandle failed http: 23 tests executed, 0 marked as todo, 3 failures. Administrator@PH33R /g/src/wine-dev/wine/dlls/wininet/tests $

1 0

Re: ASIO and wine
by Thomas Wickline 23 Sep '02

23 Sep '02

Tom Hibbert wrote: >On Sun, Sep 22, 2002 at 11:44:53AM -0400, Thomas Wickline wrote: > > >>Cubase will not run with wine as it need's VxD support .. >>ASIO (Audio Stream Input Output) needs Communication between >>audio software and a piece of audio hardware and this is where >>the VxD problem comes in .. >> >>Can someone here confirm this ?? >> >>Tom >> >> > > >Cubase SX is pure 32bit.. i would have thought it didnt use VxDs which >AFAIK were obseleted with win2k... > > I am not 100% sure this was only my thoughts of what would/could happen .. That is why I ask for someone else to confirm . Tom

1 0

email to webmaster@winehq.com dead?
by Andreas Schuldei 22 Sep '02

22 Sep '02

i and others have mailed to webmaster(a)winehq.com to report changes in the daily wine builds for debian. (it was about the fact that i should not read gluck.debian.org but people.debian.org in the apt/sources.list lines) that has been quite a while. i do still get mails by confused users which do not know how to fix their download of wine packages. could someone fix that, please?

1 0

Re: FD_ZERO and FD_SET problems.
by Michael Stefaniuc 22 Sep '02

22 Sep '02

Could you please resubmit it as unified diff (diff -u)? The diff's are more readable and are more robust regarding to changes in the target file. bye michael On Fri, Sep 20, 2002 at 08:10:41PM -1000, Patrick J. McNerthney wrote: > I hope I am doing this correctly. I am porting some Win32 software > using WineLib and ran into some problems with the WinSock headers, > specifically with regards to the use of FD_ZERO and FD_SET (they just > wouldn't compile at all). Attached is the patch that resolved my > problems. > > ChangeLog > Fixed if statement in __WS_FD_SET2 which did not have it's outer set > of parenthesis. > Removed parentheses around type to be cast in __WS_FD_SET macro. > Removed WS macro usage from within other macros because the WS macro > is undefined when these macros are expanded. > > Pat McNerthney > Icicle Software, Inc. -- 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 1

ASIO and wine
by Tom Hibbert 22 Sep '02

22 Sep '02

Hello, I am very interested in creating a home studio system with Linux. I get 1/4 the latency i do using Windows with the same hardware.. there is more control.. etc etc.. there are many reasons why I want to do this. I would especially like to use Cubase SX. The main barrier hampering this (besides copy protection ;) is the lack of ASIO support under Wine. Secondly, timing issues, but that is easy to tweak by the user. I am wondering if there are any progects or plans to implement ASIO in Wine/WineX. If so, I would like to contribute. If not, I will have to go to university and study computer science as well as electronic music. ;) Oh, yes - i know there are a lot of quality open source audio products (Audacity, Psycle, Csound, MAX/MSP come to mind...) I am mainly interested in seeing some VST implementation on Linux because VST is a very widely used and mature base for software synthesisers and effects. I'm told the only barrier to a NATIVE VST-capable app (Yes, the code is all there in the Audacity sources AFAIK) is the porting of a library known as libvstgui... why not run this through Winelib is the next thing i am going to ask the developers of that particular product :) Tom Hibbert Work: someday Home: +649 815 1838 Obtain my GPG Key from: http://cryptocracy.hn.org/pubkey.txt

2 2

Re: fix listview trace crash
by Dimitrie O. Paun 22 Sep '02

22 Sep '02

On September 21, 2002 02:46 am, Rein Klazes wrote: > Hi, > > With these fixes the original reason to debug disappeared as well ;-) > > dlls/comctl32/ : listview.c > Fix some crashes running with --debugmsg +listview > + ZeroMemory(&item, sizeof(item)); We shouldn't need these. In fact, they just hide bugs, and most of them are superfluous anyways. The first hunk is a good find though, I've integrated it in my patch. Alexandre, please use this one instead. ChangeLog -- Fix outputing of a text pointer in debug mode (by Rein Klazes) -- Remove a large bunch of superfluous ZeroMemory calls -- Fix couple of bugs Index: dlls/comctl32/listview.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.148 diff -u -r1.148 listview.c --- dlls/comctl32/listview.c 18 Sep 2002 18:29:28 -0000 1.148 +++ dlls/comctl32/listview.c 21 Sep 2002 15:08:20 -0000 @@ -337,7 +337,7 @@ wstr = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); if (wstr) MultiByteToWideChar(CP_ACP, 0, (LPCSTR)text, -1, wstr, len); } - TRACE(" wstr=%s\n", debugstr_w(wstr)); + TRACE(" wstr=%s\n", text == LPSTR_TEXTCALLBACKW ? "(callback)" : debugstr_w(wstr)); return wstr; } @@ -423,7 +423,7 @@ " pszText=%s, cchTextMax=%d, iImage=%d, lParam=%lx, iIndent=%d}", lpLVItem->mask, lpLVItem->iItem, lpLVItem->iSubItem, lpLVItem->state, lpLVItem->stateMask, - debugtext_tn(lpLVItem->pszText, isW, 80), + lpLVItem->mask & LVIF_TEXT ? debugtext_tn(lpLVItem->pszText, isW, 80) : 0, lpLVItem->cchTextMax, lpLVItem->iImage, lpLVItem->lParam, lpLVItem->iIndent); return buf; @@ -605,6 +605,7 @@ BOOL bReturn; item.iItem = iItem; + item.iSubItem = 0; item.mask = LVIF_PARAM; LISTVIEW_GetItemT(infoPtr, &item, TRUE, TRUE); @@ -865,7 +866,6 @@ } /* get item */ - ZeroMemory(&item, sizeof(item)); item.mask = LVIF_TEXT; item.iItem = idx; item.iSubItem = 0; @@ -1557,7 +1557,6 @@ if (adj_sel_only) return TRUE; /* set the selection on items */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.state = LVIS_SELECTED; lvItem.stateMask = LVIS_SELECTED; for(i = lower; i <= upper; i++) @@ -1576,7 +1575,7 @@ LVITEMW lvItem; INT index, i; - ZeroMemory(&lvItem, sizeof(lvItem)); + lvItem.state = 0; lvItem.stateMask = LVIS_SELECTED; remsel.lower = lower; @@ -1734,7 +1733,6 @@ INT oldFocus = infoPtr->nFocusedItem; LVITEMW lvItem; - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.state = LVIS_FOCUSED; lvItem.stateMask = LVIS_FOCUSED; LISTVIEW_SetItemState(infoPtr, nItem, &lvItem); @@ -1830,8 +1828,8 @@ if (nFirst == -1) nFirst = nItem; - item.stateMask = LVIS_SELECTED; item.state = LVIS_SELECTED; + item.stateMask = LVIS_SELECTED; /* FIXME: this is not correct LVS_OWNERDATA * See docu for LVN_ITEMCHANGED. Is there something similar for @@ -1889,8 +1887,6 @@ POINT ptItem; RECT rcSel; - item.stateMask = LVIS_SELECTED; - if ((uView == LVS_LIST) || (uView == LVS_REPORT)) { if (infoPtr->nSelectionMark == -1) @@ -1910,6 +1906,8 @@ nFirst = nLast = -1; } + item.stateMask = LVIS_SELECTED; + for (i = 0; i <= GETITEMCOUNT(infoPtr); i++) { if (nFirst > -1) @@ -2397,8 +2395,6 @@ lpSubItem = (LISTVIEW_SUBITEM *)COMCTL32_Alloc(sizeof(LISTVIEW_SUBITEM)); if (!lpSubItem) return FALSE; - ZeroMemory(lpSubItem, sizeof(LISTVIEW_SUBITEM)); - /* we could binary search here, if need be...*/ for (i = 1; i < hdpaSubItems->nItemCount; i++) { @@ -2692,7 +2688,6 @@ TRACE("(hdc=%x, nItem=%d)\n", hdc, nItem); /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_STATE | LVIF_INDENT; lvItem.stateMask = LVIS_SELECTED | LVIS_STATEIMAGEMASK; lvItem.iItem = nItem; @@ -2874,7 +2869,6 @@ hdc, nItem, rcItem.left, rcItem.top, rcItem.right, rcItem.bottom); /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_STATE; lvItem.stateMask = LVIS_SELECTED | LVIS_FOCUSED; lvItem.iItem = nItem; @@ -3752,7 +3746,7 @@ /* remove it from the selection range */ - ZeroMemory(&item,sizeof(item)); + item.state = LVIS_SELECTED; item.stateMask = LVIS_SELECTED; LISTVIEW_SetItemState(infoPtr,nItem,&item); @@ -3858,10 +3852,10 @@ else { ZeroMemory(&lvItemRef,sizeof(LISTVIEW_ITEM)); - ZeroMemory(&item,sizeof(item)); item.iItem = nItem; item.iSubItem = 0; item.mask = LVIF_PARAM | LVIF_STATE; + item.stateMask = ~0; ListView_GetItemW(infoPtr->hwndSelf, &item); lvItemRef.hdr.iImage = item.iImage; lvItemRef.state = item.state; @@ -3873,7 +3867,7 @@ dispInfo.item.mask = 0; dispInfo.item.iItem = nItem; dispInfo.item.state = lpItem->state; - dispInfo.item.stateMask = 0; + dispInfo.item.stateMask = 0; /* FIXME: why not copy the state mask in here? */ dispInfo.item.pszText = pszText; dispInfo.item.cchTextMax = textlenT(pszText, isW); dispInfo.item.iImage = lpItem->hdr.iImage; @@ -3940,11 +3934,10 @@ else { LVITEMW item; - ZeroMemory(&lvItemRef,sizeof(LISTVIEW_ITEM)); - ZeroMemory(&item, sizeof(item)); item.iItem = nItem; item.iSubItem = 0; item.mask = LVIF_PARAM | LVIF_STATE; + item.stateMask = ~0; ListView_GetItemW(infoPtr->hwndSelf, &item); lvItemRef.hdr.iImage = item.iImage; lvItemRef.state = item.state; @@ -3953,7 +3946,6 @@ } /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT; lvItem.iItem = nItem; lvItem.iSubItem = 0; @@ -3966,7 +3958,7 @@ dispInfo.item.mask = 0; dispInfo.item.iItem = nItem; dispInfo.item.state = lpItem->state; - dispInfo.item.stateMask = 0; + dispInfo.item.stateMask = 0; /* FIXME: why not copy the state mask in here? */ dispInfo.item.pszText = lvItem.pszText; dispInfo.item.cchTextMax = lstrlenW(lvItem.pszText); dispInfo.item.iImage = lpItem->hdr.iImage; @@ -4218,8 +4210,6 @@ if ((nItem >= -1) && (lpFindInfo != NULL)) { - ZeroMemory(&lvItem, sizeof(lvItem)); - if (lpFindInfo->flags & LVFI_PARAM) { lvItem.mask |= LVIF_PARAM; @@ -5131,7 +5121,6 @@ if (uView & LVS_REPORT) { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_INDENT; lvItem.iItem = nItem; lvItem.iSubItem = 0; @@ -5544,9 +5533,9 @@ TRACE("(nItem=%d)\n", nItem); - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT; lvItem.iItem = nItem; + lvItem.iSubItem = 0; lvItem.cchTextMax = DISP_TEXT_SIZE; lvItem.pszText = szDispText; if (LISTVIEW_GetItemW(infoPtr, &lvItem, TRUE)) @@ -5603,10 +5592,10 @@ if ((nItem >= 0) && (nItem < GETITEMCOUNT(infoPtr))) { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iItem = nItem; - lvItem.stateMask = uMask; + lvItem.iSubItem = 0; lvItem.mask = LVIF_STATE; + lvItem.stateMask = uMask; if (LISTVIEW_GetItemW(infoPtr, &lvItem, TRUE)) uState = lvItem.state & uMask; } @@ -6352,8 +6341,6 @@ if ( !(lpItem = (LISTVIEW_ITEM *)COMCTL32_Alloc(sizeof(LISTVIEW_ITEM))) ) return -1; - ZeroMemory(lpItem, sizeof(LISTVIEW_ITEM)); - /* insert item in listview control data structure */ if ( (hdpaSubItems = DPA_Create(8)) ) nItem = DPA_InsertPtr(hdpaSubItems, 0, lpItem); @@ -6718,7 +6705,6 @@ } else { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iSubItem = iCol; lvItem.mask = LVIF_TEXT; lvItem.cchTextMax = DISP_TEXT_SIZE; @@ -6783,7 +6769,6 @@ SelectObject(hdc, old_font); /* restore the old font */ ReleaseDC(infoPtr->hwndSelf, hdc); - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iSubItem = iCol; lvItem.mask = LVIF_TEXT; lvItem.cchTextMax = DISP_TEXT_SIZE; @@ -7190,14 +7175,13 @@ BOOL bResult = TRUE; LVITEMW lvItem; - TRACE("(nItem=%d, lpLVItem=%s)\n", - nItem, debuglvitem_t(lpLVItem, TRUE)); + TRACE("(nItem=%d, lpLVItem=%s)\n", nItem, debuglvitem_t(lpLVItem, TRUE)); - ZeroMemory(&lvItem, sizeof(lvItem)); + lvItem.iItem = nItem; + lvItem.iSubItem = 0; lvItem.mask = LVIF_STATE; lvItem.state = lpLVItem->state; lvItem.stateMask = lpLVItem->stateMask ; - lvItem.iItem = nItem; if (nItem == -1) { @@ -7227,24 +7211,18 @@ */ static BOOL LISTVIEW_SetItemTextT(LISTVIEW_INFO *infoPtr, INT nItem, LPLVITEMW lpLVItem, BOOL isW) { - BOOL bResult = FALSE; - LVITEMW lvItem; + LVITEMW lvItem; - TRACE("(nItem=%d, lpLVItem=%s, isW=%d)\n", - nItem, debuglvitem_t(lpLVItem, isW), isW); + TRACE("(nItem=%d, lpLVItem=%s, isW=%d)\n", nItem, debuglvitem_t(lpLVItem, isW), isW); - if ((nItem >= 0) && (nItem < GETITEMCOUNT(infoPtr))) - { - ZeroMemory(&lvItem, sizeof(LVITEMW)); - lvItem.mask = LVIF_TEXT; - lvItem.pszText = lpLVItem->pszText; + if ((nItem < 0) && (nItem >= GETITEMCOUNT(infoPtr))) return FALSE; + lvItem.iItem = nItem; lvItem.iSubItem = lpLVItem->iSubItem; - if(isW) bResult = ListView_SetItemW(infoPtr->hwndSelf, &lvItem); - else bResult = ListView_SetItemA(infoPtr->hwndSelf, &lvItem); - } - - return bResult; + lvItem.mask = LVIF_TEXT; + lvItem.pszText = lpLVItem->pszText; + + return LISTVIEW_SetItemT(infoPtr, &lvItem, isW); } /*** @@ -7489,7 +7467,6 @@ if (!infoPtr) return -1; SetWindowLongW(hwnd, 0, (LONG)infoPtr); - ZeroMemory(infoPtr, sizeof(LISTVIEW_INFO)); infoPtr->hwndSelf = hwnd; /* determine the type of structures to use */ @@ -8097,9 +8074,8 @@ bGroupSelect = (LISTVIEW_GetItemState(infoPtr, nItem, LVIS_SELECTED) == 0); - ZeroMemory(&item, sizeof(item)); + item.state = bGroupSelect ? LVIS_SELECTED : 0; item.stateMask = LVIS_SELECTED; - if(bGroupSelect) item.state = LVIS_SELECTED; LISTVIEW_SetItemState(infoPtr, nItem, &item); LISTVIEW_SetItemFocus(infoPtr, nItem);

2 3

Patch - stub and workaround to make wineserver compile on cygwin
by Steven Edwards 22 Sep '02

22 Sep '02

This will allow you to run wineserver on cygwin. We still lack tons of stuff before we can have a WINE that really works on Cygwin but over the next few months/years++ as I am learning, I will keep working on this. Changelog: Wineserver - Stub get/set_thread_context in wineserver so it will build/run Change permission error to a Warning when running on Windows/Cygwin Index: context_i386.c =================================================================== RCS file: /home/wine/wine/server/context_i386.c,v retrieving revision 1.23 diff -u -r1.23 context_i386.c --- context_i386.c 14 Aug 2002 20:59:03 -0000 1.23 +++ context_i386.c 22 Sep 2002 03:19:41 -0000 @@ -460,9 +460,24 @@ file_set_error(); } -#else /* linux || __sun__ || __FreeBSD__ */ +#elif defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) + +/* retrieve a thread context */ +static void get_thread_context( struct thread *thread, unsigned int flags, CONTEXT *context ) +{ + printf("get_thread_context is a stub on WINDOWS!\n"); + return 0; +} + +static void set_thread_context( struct thread *thread, unsigned int flags, const CONTEXT *context ) +{ + printf("get_thread_context is a stub on WINDOWS!\n"); + return 0; +} + +#else /* linux || __sun__ || __FreeBSD__ || _WINDOWS */ #error You must implement get/set_thread_context for your platform -#endif /* linux || __sun__ || __FreeBSD__ */ +#endif /* linux || __sun__ || __FreeBSD__ || _WINDOWS */ /* copy a context structure according to the flags */ Index: request.c =================================================================== RCS file: /home/wine/wine/server/request.c,v retrieving revision 1.67 diff -u -r1.67 request.c --- request.c 16 Aug 2002 20:02:15 -0000 1.67 +++ request.c 22 Sep 2002 03:21:04 -0000 @@ -483,7 +483,11 @@ } if (!S_ISDIR(st->st_mode)) fatal_error( "%s is not a directory\n", name ); if (st->st_uid != getuid()) fatal_error( "%s is not owned by you\n", name ); +#if defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) + fprintf( stderr, "Warning: %s is accessible by other users\n", name ); +#else if (st->st_mode & 077) fatal_error( "%s must not be accessible by other users\n", name ); +#endif /* defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) */ } /* create the server directory and chdir to it */

1 0

Re: wine status page
by Brian Vincent 22 Sep '02

22 Sep '02

> that's ok. I've just uploaded your file to winehq > it's up (& running). thanx for your good work If someone wants to forward me the raw HTML I'll edit it to include WWN threads. -brian

4 4

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 22 Sep '02

22 Sep '02

One step at a time... Now I've successfully included my stubbed dll into the wine tree. When I try to link to it, however, I still get undefined references to what should be in the dll. I added my stubbed dll to the my_other_dll_DLLS section of the Makefile.in, just like it were a normal wine dll. Is that all I need to do to link to it? When I run nm on my dll in /usr/local/lib/wine, it only lists entries like: 000131a4 T __wine_stub_mydll_dll_13 It doesn't list any of the exported functions that are listed in the spec file that winedump generated. Does wine automagically match up those stub statements with the exported symbols? Does it matter that the dll is exporting C++ classes, not straight C functions? -Steve Hi Steve, > I upgraded my autoconf, which solved my first problem. Now, > everything runs fine until I get to the make install step, when > I get this error: <snip> The attached patch to winedump corrects the over-enthusiatic insertion of generated DLL entries into dlls/Makefile.in, and renames the MODULE from <dll> to <dll>.dll as per the current build process. You can manually remove the offending lines youself, edit dlls/Makefile.in and remove the 2 lines referring to your DLL after the targets "uninstall::" and "install::". Then append".dll" to the MODULE = line in dlls/<yourdll>/Makefile.in. Alternately, apply the patch and regenerate. I've just tested the process from start to finish and it works for me now. Let me know if you find any other issues. I've sent the patch to wine-patches/Alexandre. > Thanks for making those changes to the README, hopefully they'll get > committed soon so other can avoid the problems I had. np :-) Jon (See attached file: winedump_fix.diff)

2 1

Re: notepad vs write
by Sean Young 21 Sep '02

21 Sep '02

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: > > The problem is that write will handle RTF and Word documents correctly, > > while notepad is just a text editor and will only display garbage... > > > > (yes, wordpad will probably have problems with complex word documents, > > but it should work with simple ones) > > I believe that Write is able to handle only old Word 5.x/6.x format files > (and of course RTFs). RTFs should not produce too much trouble (just feed > them to a richedit control). Regarding Word 5.x format here is a snipped > from my very old DOS code which handled those files (*.doc,*.wri) well > (it completely ignores formatting though): I've written a .wri to RTF converter, which is available here: http://www.msxnet.org/word2rtf/write.c It should be almost complete. The output is almost the same as the microsoft converter (including bugs, if desired). Now I have enough information to write write32.cnv, but is there any need for this? Sean

2 2

regression in recent cvs (transparent window) ?
by T'aZ 21 Sep '02

21 Sep '02

i've recently compiled wine cvs, and now, the content of a window from an app is not shown, it's the bug http://bugs.winehq.com/show_bug.cgi?id=1033 cmorgan on irc said me i might post here so that "maybe someone knows if it was their patch that did it" :) -- T'aZ *Just because you are paranoid, it doesn't mean they are not after you.*

1 0

Re: HRGN
by Michael Stefaniuc 21 Sep '02

21 Sep '02

On Fri, Sep 20, 2002 at 05:15:10PM -0400, Dimitrie O. Paun wrote: > Oddly enough, this seem to work... STOP! It dosn't work: [...] ../../windows/painting.c:433: switch quantity not an integer [...] make[2]: *** [../../windows/painting.o] Error 1 make[2]: Leaving directory `/home/michi/work/wine/dlls/user' make[1]: *** [user] Error 2 make[1]: Leaving directory `/home/michi/work/wine/dlls' make: *** [dlls] Error 2 You picked one of the 3 handles that dosn't even compile when switched to a void* (the other two are HICON, HINSTANCE). None of the to be converted handles are so simple to convert, because if it would have been so simple, it would have already been done ;). Before i start working on the conversion of a handle i do an automated compile run for every remaining DECLARE_OLD_HANDLE saving the output of the build. Here some statistic from a compile run from 3 days ago: camus:/scr/wine.test$ for i in wine.H*; do > echo -n "$i: " > diff -u wine/make.out $i/make.out | grep -c ^+ > done wine.HBITMAP: 664 wine.HBRUSH: 428 wine.HDC: 941 wine.HFONT: 460 wine.HICON: 163 wine.HINSTANCE: 200 wine.HKEY: 423 wine.HMENU: 322 wine.HPEN: 216 wine.HRGN: 220 As you can the there are at least 160 lines of warnings to look at. bye michael > > ChangeLog > Convert HRGN to void * > > Index: include/windef.h > =================================================================== > RCS file: /var/cvs/wine/include/windef.h,v > retrieving revision 1.74 > diff -u -r1.74 windef.h > --- include/windef.h 16 Sep 2002 22:47:05 -0000 1.74 > +++ include/windef.h 20 Sep 2002 18:25:30 -0000 > @@ -89,7 +89,7 @@ > DECLARE_HANDLE(HMONITOR); > DECLARE_HANDLE(HPALETTE); > DECLARE_OLD_HANDLE(HPEN); > -DECLARE_OLD_HANDLE(HRGN); > +DECLARE_HANDLE(HRGN); > DECLARE_HANDLE(HRSRC); > DECLARE_HANDLE(HTASK); > DECLARE_HANDLE(HWINEVENTHOOK); -- 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

Re: winedump doc
by Dimitrie O. Paun 21 Sep '02

21 Sep '02

On September 20, 2002 04:13 pm, Eric Pouech wrote: > this patch adds winedump documentation > (Alexandre, you can delete tools/winedump/README if you want) Sorry, but I don't agree with this patch. Unix docs for command line utilities come in the form of man pages (or info pages). Why put in .sgml? Who's gonna read it there? Who's gonna maintain it there? It should go into a file: programs/winedump/windump.man.in or similar... -- Dimi.

2 2

Re: documentation dir
by Dimitrie O. Paun 20 Sep '02

20 Sep '02

On September 18, 2002 04:10 am, Eric POUECH wrote: > IMO, most of the documentation (even the internals description, > status of DLL) should be made in the DocBook form I don't think this is right. Documenetation that is meant for the user should go into .sgml, no disagreement here. Documentation that is meant for the ongoing developement of a DLL (something like the TODO list, or a few comments on the internal structure, or some tips, etc.) should go as plain text as close as possible to the code that it's documenting. I can not stress how important that is. I find this "developer" documentation useful beyon words: as I read through the code, it gives me ideas on what to work, I keep it _updated_. On the other hand, I've never even read 50% of the .sgml documentation even once. But even if I do, it will never have the "current" status of the one embedded in the/close to the code. As I said before, this thing has been tried numerous times before, and everybody reached the conclusion that the documentation pertaining to code should be as close to the code that it's documenting (see javadoc et. Co.). -- Dimi.

3 5

Re: wine status page
by Eric Pouech 20 Sep '02

20 Sep '02

> I have a update for the status page. > I made changes to the php.html file > If you need more info just let me know Thomas that's ok. I've just uploaded your file to winehq it's up (& running). thanx for your good work A+

1 0

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 20 Sep '02

20 Sep '02

Hi Jon I upgraded my autoconf, which solved my first problem. Now, everything runs fine until I get to the make install step, when I get this error: make[2]: Leaving directory `/home/stevenlu/wine/dlls/x11drv' mydll.dll.so \ rm -f /usr/local/lib/libntdll.dll.so make[1]: mydll.dll.so: Command not found make[1]: *** [install] Error 127 make[1]: Leaving directory `/home/stevenlu/wine/dlls' make: *** [dlls/__install__] Error 2 Winedump created dlls/mydll/mydll.so, not mydll.dll.so. Thanks for making those changes to the README, hopefully they'll get committed soon so other can avoid the problems I had. -Steve Hi Steve, On Wed, 18 Sep 2002 18:57, steve.lustbader(a)philips.com wrote: > 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? Yes, any time that you add or delete directories to the base distribution you need to re-run autoconf to generate a new configure script. In your case you are running an older version of autoconf. Make sure that you are running autoconf version 2.53 or higher, or this process will not work. There was a thread a while ago on allowing earlier versions of autoconf to be used to build Wine, but its not seen as too onerous to require a recent version for developers. > If I skip autoconf (which may be causing this problem), when > I run make depend I get: <snip> Yes, you have the dll directory and a Makefile.in in there, but no Makefile, since configure didn't get updated and generate one for you. > I ran the install script that winedump produced, but maybe that's > not up-to-date with respect to the current wine build process? I updated the build process following the big changes earlier this year for building on Win32. I don't believe there are any problems, but there have been some changes since then. If you have any issues let me know and I'll try and iron them out. If I get a moment I'll update the README on requiring a new autoconf also. I was considering allowing generated DLL'd to be built out of the tree but I didn't want to be generating too many files from winebuild (and autoconf files for a whole new dll project can be quite large). Cheers, Jon

2 1

Debug info of so
by Fabian Cenedese 20 Sep '02

20 Sep '02

Hi I changed my application now from calling a Win32 dll to calling a Linux so. But of course I can't load the pdb file I have from the Windows dll. Is there something similar for Linux? How can I generate such a file and how do I tell Wine to use it? I made the so with KDEdevelop. Thanks Fabi

2 1

Call to update the 'Who's Who' page
by Jeremy Newman 20 Sep '02

20 Sep '02

It's time to update the Wine Who's Who page. http://www.winehq.com/about/index.php?who I need all current developers to send me their info for this page. It is optional to be listed here of course. If you are on the list now and do not wish be be listed let me know. I'll also take anyone's suggestions on how to improve this page. Optional info I'd like from everyone. Your name, e-mail, home page url, location, role, and bio. -- __ _WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | / -_) | | / ' \/ _` | ' \ -= jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

1 0

[Alsa-devel] update of "known bugs" list (forw)
by Joerg Mayer 20 Sep '02

20 Sep '02

----- Forwarded message from Takashi Iwai <tiwai(a)suse.de> ----- From: Takashi Iwai <tiwai(a)suse.de> Cc: alsa-devel(a)lists.sourceforge.net Subject: [Alsa-devel] update of "known bugs" list Date: Thu, 19 Sep 2002 17:46:58 +0200 Hi Patrick, the following is the update of known bugs list on the web. could you update the page? * OSS emulation on WINE --> works the following workaround is necessary on some cards/chips, which support only 16bit samples. you need to set the operation mode by writing a configuration onto /proc/asound/card0/pcm0p/oss, i.e. # echo "wine 0 0 direct" > /proc/asound/card0/pcm0p/oss * intel8x0 --> fixed all three entries are solved. * ice1712 --> changed DMX-6fire frontbox is partially working (no spdif yet) * via8233 --> fixed no problems now (on cvs it's merged together with via686 as snd-via82xx driver) New entries: * es1968 capture doesn't work. * ymfpci pcm playback is not audible on toshiba tecra8100. Takashi ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list Alsa-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ----- End forwarded message ----- -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

1 0

Re: get GetDateFormatW somewhat working...
by Vincent Béron 19 Sep '02

19 Sep '02

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 19 Sep '02

19 Sep '02

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 19 Sep '02

19 Sep '02

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 19 Sep '02

19 Sep '02

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 19 Sep '02

19 Sep '02

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 19 Sep '02

19 Sep '02

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 19 Sep '02

19 Sep '02

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 19 Sep '02

19 Sep '02

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 18 Sep '02

18 Sep '02

"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 18 Sep '02

18 Sep '02

>>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

An attempt at LogonUser()
by Martin Wilck 18 Sep '02

18 Sep '02

[ This goes to wine-devel too - demonstrates PAM interface ] Patch: LogonUser.diff Against: CVS 2002-09-18 Modified files: wine: configure configure.ac wine/dlls/advapi32: Makefile.in advapi.c advapi32.spec wine/include: config.h.in winbase.h Log Message: Attempt to code LogonUser() using an interface between Wine and the PAM library. Normally, this will validate Unix username/password pairs. If PAM is suitably configured (for using winbind), usernames and passwords can be obtained from a Windows Domain controller. It is even possible for system administrators to setup a special authorization scheme for wine by editing "/etc/pam.d/wine". Status: Compiles, simple (non-unicode) test program authenticates sucessfully against Unix and Windows PDC accounts (and fails with wrong password). Fixmes: ** LogonUserW() is untested, and I have little experience with ** Unicode transformations in wine. Be prepared for bugs there. The LICENSE of PAM is rather unclear - on http://sourceforge.net/projects/pam it says "BSD License, GNU General Public License (GPL)". But I expect no problem with Wine linking against it. The flags to LogonUser() are ignored, and the resulting Token is meaningless because wine currently has no concept of security tokens. To make this really useful, more support for security issues needs to be implemented - but this function is (almost) sufficient for me :-) There are no security checks on the parameters (are they null-terminated?), because I'm not sure how to do that (enforce maximum length? If yes, which?). Perhaps the code should have gone into security.c rather than advapi.c. Or does the whole stuff belong somewhere in ntdll? Index: configure =================================================================== RCS file: /home/wine/wine/configure,v [ *** Deleted for better readability *** ] diff -u -r1.340 configure Index: configure.ac =================================================================== RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.77 diff -u -r1.77 configure.ac --- configure.ac 13 Sep 2002 17:54:27 -0000 1.77 +++ configure.ac 18 Sep 2002 19:00:29 -0000 @@ -613,6 +613,13 @@ [AUDIOIOLIBS="-laudioio" AC_DEFINE(HAVE_LIBAUDIOIO, 1, [Define if you have libaudioIO])])]) +dnl **** Check for PAM **** +AC_SUBST(PAMLIBS,"") +AC_CHECK_HEADERS(security/pam_appl.h, + [AC_CHECK_LIB(pam,pam_start, + [AC_DEFINE(HAVE_PAM,1,[Define if you have PAM including devel headers]) + PAMLIBS="-lpam"],,)]) + dnl **** Check for broken glibc mmap64 **** AC_CACHE_CHECK( [whether mmap64 works defined as mmap], ac_cv_mmap64_works, Index: dlls/advapi32/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/advapi32/Makefile.in,v retrieving revision 1.15 diff -u -r1.15 Makefile.in --- dlls/advapi32/Makefile.in 9 Aug 2002 01:22:40 -0000 1.15 +++ dlls/advapi32/Makefile.in 18 Sep 2002 19:00:29 -0000 @@ -5,6 +5,7 @@ VPATH = @srcdir@ MODULE = advapi32.dll IMPORTS = kernel32 ntdll +EXTRALIBS = @PAMLIBS@ LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o Index: dlls/advapi32/advapi.c =================================================================== RCS file: /home/wine/wine/dlls/advapi32/advapi.c,v retrieving revision 1.20 diff -u -r1.20 advapi.c --- dlls/advapi32/advapi.c 27 Aug 2002 18:30:53 -0000 1.20 +++ dlls/advapi32/advapi.c 18 Sep 2002 19:00:29 -0000 @@ -24,6 +24,10 @@ #include <errno.h> #include <stdio.h> #include <string.h> +#include <stdlib.h> +#if HAVE_PAM +#include <security/pam_appl.h> +#endif #include "winbase.h" #include "windef.h" @@ -120,4 +124,240 @@ { TRACE("stub %s (harmless)\n", debugstr_w(lpMachineName)); return TRUE; +} + +/****************************************************************************** + * Init function for advapi32 - needed to properly load the pam library. + */ +BOOL WINAPI advapi32_init ( HINSTANCE hinst, DWORD reason, LPVOID reserved ) +{ +#if HAVE_PAM +#define SONAME_LIBPAM "libpam.so" + switch(reason) + { + case DLL_PROCESS_ATTACH: + if (!wine_dlopen (SONAME_LIBPAM, RTLD_NOW|RTLD_GLOBAL, NULL, 0)) + ERR ( "error opening %s\n", SONAME_LIBPAM ); + break; + } +#endif + return TRUE; +} + +#if HAVE_PAM +/****************************************************************************** + * Helper functions for the PAM interface. + */ + +/* FIXME: These should be made configurable options, at least the separator. */ +#define WINE_PAM_SERVICE "wine" +/* This corresponds to the "winbind separator" setting in smb.conf. */ +#define WINE_WINBIND_SEPARATOR '\\' +#define PAM_FAIL(x) ((x) != PAM_SUCCESS) + +/* Placeholder for future reasonable error handling */ +static int PAM_error_to_dos ( pam_handle_t *pamh, int retcode ) +{ + if ( pamh ) + TRACE( "PAM error: %s\n", pam_strerror ( pamh, retcode ) ); + switch ( retcode ) + { + case PAM_SUCCESS: return ERROR_SUCCESS; + case PAM_AUTH_ERR: return ERROR_ACCESS_DENIED; + default: return ERROR_GEN_FAILURE; + } +} + +/* The "PAM conversation callback" for LogonUser(). */ +static int PAM_logon_user_conv ( int nmsg, const struct pam_message **msg, + struct pam_response **resp, void *ptr ) +{ + int i; + struct pam_response *myresp; + + /* PAM will free myresp and the response buffers when done. */ + myresp = malloc ( nmsg * sizeof (struct pam_response) ); + if (!myresp) return PAM_BUF_ERR; + memset ( myresp, 0, nmsg * sizeof (struct pam_response) ); + + /* Fill in our password as "response" to the prompt we never show. */ + for (i = 0; i < nmsg; i++) + { + if ( msg[i]->msg_style == PAM_PROMPT_ECHO_OFF ) + { + myresp[i].resp = strdup (ptr); + break; + } + } + *resp = myresp; + return PAM_SUCCESS; +} +/******************************************************************************/ +#endif /* HAVE_PAM */ + + +/****************************************************************************** + * LogonUserA [ADVAPI32.@] + * + * PARAMS + * lpUserName : (IN) user name + * lpDomain : (IN) domain name (will only work with PAM winbind support) + * lpPassword : (IN) Cleartext password + * dwLogonType : (IN) logon type, IGNORED + * dwLogonProvider : (IN) login provider, IGNORED + * phToken : (OUT) handle to user token, IGNORED + * + * RETURNS + * TRUE on success. + */ +BOOL WINAPI LogonUserA( LPSTR lpUserName, LPSTR lpDomain, LPSTR lpPassword, + DWORD dwLogonType, DWORD dwLogonProvider, LPHANDLE phToken ) +{ +#if ! HAVE_PAM + ERR( "stub - wine needs to be compiled against PAM library\n" ); + SetLastError ( ERROR_NOT_SUPPORTED ); + return FALSE; +#else + + int err = ERROR_NOT_SUPPORTED, ret; + char *user = NULL; + struct pam_conv conv = { PAM_logon_user_conv, NULL }; + pam_handle_t *pamh = NULL; + + TRACE( "user %s, domain %s\n", lpUserName, lpDomain ); + FIXME( "ignoring type (%lx) and provider (%lx), returned token handle will be bogus!\n", + dwLogonType, dwLogonProvider ); + + if ( !lpUserName || !lpPassword || !phToken ) + { + err = ERROR_INVALID_PARAMETER; + goto abort; + } + + if ( !lpDomain ) + /* User name is "user@DNS-name" (UPN format), + * but we don't know how to convert DNS to NT domain name. + */ + { + char *p; + FIXME( "UPN format unsupported - trying unqualified name\n" ); + + user = strdup ( lpUserName ); + if ( ! user ) goto outofmem; + p = strchr ( user, '@' ); + if ( p ) *p = '\0'; + } + else if ( *lpDomain == '\0' || ! strcmp ( lpDomain, "." ) ) + { + user = strdup ( lpUserName ); + if ( ! user ) goto outofmem; + } + else + { + int ldom = strlen ( lpDomain ); + int lusr = strlen ( lpUserName ); + user = malloc ( ldom + lusr + 2 ); + if ( ! user ) goto outofmem; + strcpy ( user, lpDomain ); + user[ldom] = WINE_WINBIND_SEPARATOR; + strcpy ( user + ldom + 1, lpUserName ); + } + TRACE( "PAM user name: %s\n", user ); + + conv.appdata_ptr = lpPassword; + if ( PAM_FAIL( ret = pam_start ( WINE_PAM_SERVICE, user, &conv, &pamh )) ) + goto pam_error; + + if ( PAM_FAIL( ret = pam_authenticate ( pamh, PAM_SILENT ) ) ) + goto pam_error; + + pam_end ( pamh, PAM_SUCCESS ); + *phToken = 0xcafe; + free ( user ); + + TRACE( "-> logon successful\n" ); + return TRUE; + +pam_error: + err = PAM_error_to_dos ( pamh, ret ); + goto abort; + +outofmem: + err = ERROR_NOT_ENOUGH_MEMORY; + +abort: + TRACE( "-> error %x\n", err ); + if ( pamh ) pam_end ( pamh, PAM_SUCCESS ); + if ( user ) free ( user ); + SetLastError ( err ); + return FALSE; + +#endif /* HAVE_PAM */ +} + +/****************************************************************************** + * LogonUserW [ADVAPI32.@] + * + * PARAMS + * lpUserNameW : (IN) user name + * lpDomainW : (IN) domain name (will only work with PAM winbind support) + * lpPasswordW : (IN) Cleartext password + * dwLogonType : (IN) logon type, IGNORED + * dwLogonProvider : (IN) login provider, IGNORED + * phToken : (OUT) handle to user token, IGNORED + * + * RETURNS + * TRUE on success. + */ +BOOL WINAPI LogonUserW( LPWSTR lpUserNameW, LPWSTR lpDomainW, LPWSTR lpPasswordW, + DWORD dwLogonType, DWORD dwLogonProvider, LPHANDLE phToken ) +{ +#if ! HAVE_PAM + ERR( "stub - wine needs to be compiled against PAM library\n" ); + SetLastError ( ERROR_NOT_SUPPORTED ); + return FALSE; +#else + int ulen = 0, dlen = 0, plen = 0, ret; + LPSTR buf = NULL; + LPSTR lpUserName, lpPassword, lpDomain; + + if ( !lpUserNameW || !lpPasswordW || !phToken ) + { + SetLastError ( ERROR_INVALID_PARAMETER ); + return FALSE; + } + + ulen = WideCharToMultiByte( CP_ACP, 0, lpUserNameW, -1, NULL, 0, NULL, NULL ); + plen = WideCharToMultiByte( CP_ACP, 0, lpPasswordW, -1, NULL, 0, NULL, NULL ); + if ( lpDomainW ) + dlen = WideCharToMultiByte( CP_ACP, 0, lpDomainW, -1, NULL, 0, NULL, NULL ); + + buf = malloc ( ulen + plen + dlen ); + if ( !buf ) + { + SetLastError ( ERROR_NOT_ENOUGH_MEMORY ); + return FALSE; + } + + lpUserName = buf; + WideCharToMultiByte( CP_ACP, 0, lpUserNameW, -1, lpUserName, ulen, NULL, NULL ); + + lpPassword = buf + ulen; + WideCharToMultiByte( CP_ACP, 0, lpPasswordW, -1, lpPassword, plen, NULL, NULL ); + + if ( lpDomainW ) + { + lpDomain = lpPassword + plen; + WideCharToMultiByte( CP_ACP, 0, lpDomainW, -1, lpDomain, dlen, NULL, NULL ); + } + else lpDomain = NULL; + + ret = LogonUserA( lpUserName, lpDomain, lpPassword, + dwLogonType, dwLogonProvider, phToken ); + + memset ( buf, 0, ulen + plen + dlen ); + free ( buf ); + return ret; + +#endif /* HAVE_PAM */ } Index: dlls/advapi32/advapi32.spec =================================================================== RCS file: /home/wine/wine/dlls/advapi32/advapi32.spec,v retrieving revision 1.28 diff -u -r1.28 advapi32.spec --- dlls/advapi32/advapi32.spec 6 Sep 2002 19:36:37 -0000 1.28 +++ dlls/advapi32/advapi32.spec 18 Sep 2002 19:00:29 -0000 @@ -1,3 +1,5 @@ +init advapi32_init + @ stdcall AbortSystemShutdownA(ptr) AbortSystemShutdownA @ stdcall AbortSystemShutdownW(ptr) AbortSystemShutdownW @ stdcall AccessCheck(ptr long long ptr ptr ptr ptr ptr) AccessCheck @@ -127,8 +129,8 @@ @ stdcall IsValidSecurityDescriptor(ptr) IsValidSecurityDescriptor @ stdcall IsValidSid(ptr) IsValidSid @ stub LockServiceDatabase -@ stub LogonUserA -@ stub LogonUserW +@ stdcall LogonUserA(ptr ptr ptr long long ptr) LogonUserA +@ stdcall LogonUserW(ptr ptr ptr long long ptr) LogonUserW @ stdcall LookupAccountNameA(str str ptr ptr ptr ptr ptr) LookupAccountNameA @ stub LookupAccountNameW @ stdcall LookupAccountSidA(ptr ptr ptr ptr ptr ptr ptr) LookupAccountSidA Index: include/config.h.in =================================================================== RCS file: /home/wine/wine/include/config.h.in,v retrieving revision 1.129 diff -u -r1.129 config.h.in --- include/config.h.in 29 Aug 2002 01:51:32 -0000 1.129 +++ include/config.h.in 18 Sep 2002 19:00:33 -0000 @@ -320,6 +320,9 @@ /* Define if you have NAS including devel headers */ #undef HAVE_NAS +/* Define if you have PAM including devel headers */ +#undef HAVE_PAM + /* Define to 1 if you have the <ncurses.h> header file. */ #undef HAVE_NCURSES_H Index: include/winbase.h =================================================================== RCS file: /home/wine/wine/include/winbase.h,v retrieving revision 1.158 diff -u -r1.158 winbase.h --- include/winbase.h 17 Sep 2002 18:54:42 -0000 1.158 +++ include/winbase.h 18 Sep 2002 19:00:33 -0000 @@ -1123,6 +1123,16 @@ #define SCS_POSIX_BINARY 4 #define SCS_OS216_BINARY 5 +/* LOGON support APIs */ +#define LOGON32_LOGON_INTERACTIVE 2 +#define LOGON32_LOGON_NETWORK 3 +#define LOGON32_LOGON_BATCH 4 +#define LOGON32_LOGON_SERVICE 5 +#define LOGON32_PROVIDER_DEFAULT 0 +#define LOGON32_PROVIDER_WINNT35 1 +#define LOGON32_PROVIDER_WINNT40 2 +#define LOGON32_PROVIDER_WINNT50 3 + BOOL WINAPI GetBinaryTypeA( LPCSTR lpApplicationName, LPDWORD lpBinaryType ); BOOL WINAPI GetBinaryTypeW( LPCWSTR lpApplicationName, LPDWORD lpBinaryType ); #define GetBinaryType WINELIB_NAME_AW(GetBinaryType) @@ -1364,6 +1374,9 @@ BOOL WINAPI ImpersonateLoggedOnUser(HANDLE); BOOL WINAPI ImpersonateSelf(SECURITY_IMPERSONATION_LEVEL); BOOL WINAPI IsProcessorFeaturePresent(DWORD); +BOOL WINAPI LogonUserA(LPSTR,LPSTR,LPSTR,DWORD,DWORD,PHANDLE); +BOOL WINAPI LogonUserW(LPWSTR,LPWSTR,LPWSTR,DWORD,DWORD,PHANDLE); +#define LogonUser WINELIB_NAME_AW(LogonUser) BOOL WINAPI LookupAccountSidA(LPCSTR,PSID,LPSTR,LPDWORD,LPSTR,LPDWORD,PSID_NAME_USE); BOOL WINAPI LookupAccountSidW(LPCWSTR,PSID,LPWSTR,LPDWORD,LPWSTR,LPDWORD,PSID_NAME_USE); #define LookupAccountSid WINELIB_NAME_AW(LookupAccountSid) -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

rhlx01.fht-esslingen.de hangs in tsx11 directory
by Uwe Bonnes 18 Sep '02

18 Sep '02

Hallo Andi, a cvs update with rhlx01.fht-esslingen.de hangs in the tsx11 directory Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

winaspi + libscg
by Szombathelyi György 18 Sep '02

18 Sep '02

Hi! 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? Best regards, György Szombathelyi

3 2

RE: Direct3D v8
by Jesse Allen 18 Sep '02

18 Sep '02

Hi, After hearing your about your work on d3d8, I'm particularly interested in the implimentation of Direct3dCreate8. I had been working on a version of my own several weeks ago, but never had time to complete, hoping it would fix a problem with Warcraft 3's very hackish opengl mode. The game has a problem where, if it minimizes for playing movies, it forgets it's hdc -- SwapBuffers only shows (00000000) in a trace even after I restore the window. I checked out the code in x11drv for minimizing and it seems to be fine. I think the problem is in their hackish code for opengl, because even though I explicitly tell it to use opengl, it still makes a call to Direct3dCreate8 at game start before minimizing for the opening movie. Wierd. The game must be very dependent on a working d3d8.dll, no matter what. So that's the only lead there for the moment. So I'll try out that specific function and see how it works. If it looks good, I can prepare a patch for that against the current wine tree, cleaning it up where necessary. Let me know if you think if this is ok. Jesse

1 0

problems with --debugmsg -relay=this:that
by Rick Romero 18 Sep '02

18 Sep '02

I'm using Wine cvs from Monday (IIRC) I'm trying to find what appears to be a loop which that calls GetCursorPos infinately. (I know it's called repeatedly anyhow, but part of the bug is that PosX & PosY never get changed after a left click. Bug #434) Just +relay is a little too much info, so according to 'man wine': --debugmsg -relay=rtlleavecriticalsection:RtlEnterCriticalSection will turn on all relay messages except for RtlLeaveCriticalSection and RtlEnterCriticalSection. --debugmsg +relay=advapi32 will only turn on relay messages into the ADVAPI32 code. So, I tried: wine --debugmsg +cursor,+input,+mouse,-relay=kernel32:ntdll vfp.exe &> testfile2 wine --debugmsg +cursor,+input,+mouse,+relay=x11drv:gdi32:user32 vfp.exe &> testfile2 I even dropped to: wine --debugmsg +relay=x11drv:gdi32:user32 vfp.exe No relay messages. Now, just +relay works but gives too much info, so I think I've either got some syntax wrong, or maybe the(my?) man page hasn't been updated. What am I doing wrong? Thanks, Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

2 1

RFC - Closing Bug 529 - Running Perl regression tests on Windows
by Steven Edwards 18 Sep '02

18 Sep '02

I just wanted to double check that we are going to be moving away from perl for the regression test suite. If this is still true then we have one less bug for 0.9 after the existing system is changed to be C only. Thanks Steven

1 0

[OT] site down?
by Paul Millar 18 Sep '02

18 Sep '02

Hi, I can ping www.winehq.com, but can't load http://www.winehq.com/ (or any other page). Instead, I get a "connection refused" back from the local proxy. Also, email to webmaster(a)winehq.com is not being delivered (connection problems again). Looks like a server problem, so could someone give it a kick? Ta, Paul. ---- Paul Millar

3 4

Re: Right button clicks
by Fabian Cenedese 18 Sep '02

18 Sep '02

> > Does Wine support right mouse button double clicks? I have an App with > > a dialog (in fact an overridden MFC CDialog for about infos) in which I can > > double click with the right mouse button to show some additional info. But > > they never show up. After +relay tracing the messages I found that only > > WM_RBUTTONDOWN and WM_RBUTTONUP messages are generated, > > none of them get converted into clicks or even double clicks, no matter > > how fast I click. Does anyone have an idea? I now got to the real problem. The dialog's class flags include the CS_DBLCLKS in Windows, but in Wine this bit is cleared. I never explicitely wrote this flag in the source, so I guess it's MFC or Windows adding it. It works if I set it now manually but that wouldn't solve the problem in Wine. Where are the dialogs/windows created in Wine, where could this flag be added? Thanks. bye Fabi

1 0

Re: [Bug 529] - Running Perl regression tests on Windows
by Andriy Palamarchuk 18 Sep '02

18 Sep '02

> ------- Additional Comments From > Steven_Ed4153(a)yahoo.com 2002-09-17 18:50 ------- > This bug can be closed as Alexandre has said that > the regression suite will be > droping perl as no one uses it and its a bitch to > get working on Windows. Trust > me I have tried Want to let winedevel know that I'm closing the bug. Andriy Boston, MA __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

Right button clicks
by Fabian Cenedese 18 Sep '02

18 Sep '02

Hi Does Wine support right mouse button double clicks? I have an App with a dialog (in fact an overridden MFC CDialog for about infos) in which I can double click with the right mouse button to show some additional info. But they never show up. After +relay tracing the messages I found that only WM_RBUTTONDOWN and WM_RBUTTONUP messages are generated, none of them get converted into clicks or even double clicks, no matter how fast I click. Does anyone have an idea? Thanks Fabi

2 3

Re: X client wrapper for Win apps?
by Alexander Gottwald 18 Sep '02

18 Sep '02

On Mon, 16 Sep 2002, Keith D. Tyler wrote: [GDI apps using X11] > This is, I realize, all probably very unrealistic dreaming, but any leads > or tips are welcome. I don't know much of the windows internals but thought of simple concept. Every Windows draw command is translated into calls to a GDI driver. this driver is either the driver of the graphics card or a printer. The people from wine already have written a driver which exports a GDI interface and maps all calls to X11. Maybe this is a starting point. I never tried to compile the wine x11drv as a native windows driver. This would be the first hurdle to take. Then one must either replace the original windows display driver or use the x11drv as proxy (export X11 and call old display driver) or even set the driver per application (create a new graphics context with the x11drv) so the rest of the system is not affected. bye ago Xpost to wine-devel, they might know it better -- Alexander.Gottwald(a)informatik.tu-chemnitz.de http://www.gotti.org ICQ: 126018723

1 0

more MSVCRT fun
by steve.lustbader＠philips.com 18 Sep '02

18 Sep '02

In my winelib app, most of the cpp files use MSVCRT only, and thanks to Martin I've gotten those to compile. A couple of my source files, however, use a mix of MSVCRT and standard glibc (fork, exec, etc). When I include unistd.h, lots of function definitions conflict with msvcrt/io.h. How can I get this mix to compile? Does the @ignore in the spec file trick from the Winelib user's guide still apply, or has it been changed (or removed altogether)? -Steve

2 1

Re: Update to REAME.fr
by Dimitrie O. Paun 17 Sep '02

17 Sep '02

> PS: are my patches inline or not? Or, can you read them easily or not? > Please answer in a private mail as to not clutter wine-devel. Yes, they are. In fact you attach them as plain/text (isn't it), but that's equivalent to inlining them, for our purposes. Thanks. -- Dimi.

1 0

Patch - Update some CVS ignores
by Steven Edwards 17 Sep '02

17 Sep '02

Changelog: Update .cvsignore's for mingw/cygwin Index: unicode/.cvsignore =================================================================== RCS file: /home/wine/wine/unicode/.cvsignore,v retrieving revision 1.2 diff -u -r1.2 .cvsignore --- unicode/.cvsignore 25 Jul 2000 21:01:59 -0000 1.2 +++ unicode/.cvsignore 17 Sep 2002 22:20:37 -0000 @@ -1,2 +1,3 @@ Makefile libwine_unicode.so.1.0 +libwine_unicode.dll Index: tsx11/.cvsignore =================================================================== RCS file: /home/wine/wine/tsx11/.cvsignore,v retrieving revision 1.2 diff -u -r1.2 .cvsignore --- tsx11/.cvsignore 6 Dec 2000 00:04:11 -0000 1.2 +++ tsx11/.cvsignore 17 Sep 2002 22:21:09 -0000 @@ -1,2 +1,3 @@ Makefile libwine_tsx11.so.1.0 +libwine_tsx11.dll Index: library/.cvsignore =================================================================== RCS file: /home/wine/wine/library/.cvsignore,v retrieving revision 1.2 diff -u -r1.2 .cvsignore --- library/.cvsignore 31 Oct 2000 00:20:51 -0000 1.2 +++ library/.cvsignore 17 Sep 2002 22:21:33 -0000 @@ -1,2 +1,3 @@ Makefile libwine.so.1.0 +libwine.dll

1 0

Re: Unable to print with the Wine PS driver
by Sylvain Petreolle 17 Sep '02

17 Sep '02

Same issue here with another printers. Note that the text printed in the msgboxes is random garbage. This could be uninitialised/corrupted pointer. And, last point, the 'printing' window shouldn't be there after you get these 3 windows, or at least inactive. Are you using the cvs version ? your debugger problem should be fixed now. I have to the backtrace attached at bottom. Note that calls 6 to 9 are the same I reported in 'Question about "undefined" functions' on wine-devel and they go to 0x0 access error. See http://www.winehq.com/hypermail/wine-devel/2002/09/0385.html 1 0x413c35b7 (X11DRV.DLL.SetDeviceGammaRamp+0x7b9c17 in wineps.dll.so) (ebp=405e2648) 2 0x40a1b0e0 (GDI32.DLL.StartDocA+0x80 in gdi32.dll.so) (ebp=405e267c) 3 0x403b7cb8 (notepad.exe.EntryPoint+0x1cb8 in notepad.exe.so) (ebp=405e2b24) 4 0x403b890f (notepad.exe.EntryPoint+0x290f in notepad.exe.so) (ebp=405e2b30) 5 0x403b8c35 (notepad.exe.EntryPoint+0x2c35 in notepad.exe.so) (ebp=405e2c98) 6 0x4091701f (USER32.DLL.GetTaskmanWindow+0xdf in user32.dll.so) (ebp=405e2cbc) 7 0x40917093 (USER32.DLL.GetTaskmanWindow+0x153 in user32.dll.so) (ebp=405e2cf4) 8 0x4091da26 (USER32.DLL.CallWindowProcA+0x136 in user32.dll.so) (ebp=405e2d28) 9 0x408f721b (USER32.DLL.DispatchMessageA+0xbb in user32.dll.so) (ebp=405e2d5c) 10 0x403b914a (notepad.exe.EntryPoint+0x314a in notepad.exe.so) (ebp=405e2e00) 11 0x403b60cd (notepad.exe.EntryPoint+0xcd in notepad.exe.so) (ebp=405e2e70) 12 0x400e1be6 (start_process+0x206 [process.c] in libntdll.dll.so) (ebp=405e2f28) 13 0x400e6ce0 (call_on_thread_stack+0x90 [sysdeps.c] in libntdll.dll.so) (ebp=405e2ff4) 14 0x400e6e68 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

PATCH: make wine find winelib apps better
by Martin Wilck 17 Sep '02

17 Sep '02

[ forwarded to wine-devel, potential for controversy ] Patch: open-builtin-exe Modified files: scheduler: process.c Log Message: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Winelib apps often (almost always) have mixed upper/lower case names and are therefore never found by open_builtin_exe(). Fix that, without breaking the default (all-lowercase name) for builtin apps. Index: scheduler/process.c =================================================================== RCS file: /home/wine/wine/scheduler/process.c,v retrieving revision 1.198 diff -u -r1.198 process.c --- scheduler/process.c 27 Aug 2002 01:13:59 -0000 1.198 +++ scheduler/process.c 17 Sep 2002 16:55:18 -0000 @@ -265,11 +265,15 @@ { char exename[MAX_PATH], *p; const char *basename = get_basename(name); + void *exeptr; if (strlen(basename) >= sizeof(exename)) return NULL; strcpy( exename, basename ); for (p = exename; *p; p++) *p = FILE_tolower(*p); - return wine_dll_load_main_exe( exename, error, error_size, test_only ); + exeptr = wine_dll_load_main_exe( exename, error, error_size, test_only ); + if ( exeptr ) return exeptr; + /* If lower-case name fails, try potential mixed-case name (for Winelib) */ + return wine_dll_load_main_exe( basename, error, error_size, test_only ); } -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 4

Missing tchar.h?
by Juraj Hercek 17 Sep '02

17 Sep '02

Hi, Is tchar.h file *not installed* intentionaly? If so why? I installed september's wine snapshot. I build everything then I did "make install". File tchar.h wasn't installed. I did "make install-dev" but it didn't help (actually it was expected, since install-dev target is probably subclass of full install). I need tchar.h... Thanks, Juraj

2 1

Netapi32 ??
by Martin Wilck 17 Sep '02

17 Sep '02

The app I am trying to port with winelib makes heavy use of calls to the netapi32 DLL to check for permissions, etc. I just took a glance over the spec file and found it consists mainly of stubs. Is anybody (Mike?) currently working on netapi32, are there plans to implement larger parts, what are the main problems? I guess this points towards the general Wine/Samba integration that Mike has been talking about earlier... Grateful for any hints, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

3 7

Re: WineLib with MSVCRT
by steve.lustbader＠philips.com 17 Sep '02

17 Sep '02

I noticed in regedit's Makefile.in that it lists msvcrt, advapi32, and kernel32 in it's IMPORTS variable and has no foo_DLLS variable, whereas Winemaker by default puts most of those in the foo_DLLS variable. What's the difference between the DLLS variable and the IMPORTS variable? -Steve Andriy Palamarchuk To: Steve Lustbader/ANR/MS/PHILIPS@AMEC <apa3a(a)yahoo.com wine-devel(a)winehq.com > cc: Subject: Re: WineLib with MSVCRT 09/16/2002 03:02 PM Classification: --- steve.lustbader(a)philips.com wrote: > What is the proper way to use the MSVCRT in WineLib? Check out how Wine programs (e.g. regedit) use MSVCRT. Andriy __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 1

SFU port part2
by Steven Edwards 17 Sep '02

17 Sep '02

ok got configure working but some of the porting definitions are hosed. When I try to build anything I get this: ../include/wine/port.h:49: Error: conflicting types for `mode_t' /usr/include/sys/types.h:45: Error: previous declaration of `mode_t' ../include/wine/port.h:52: Warning: redefinition of `off_t' /usr/include/sys/types.h:69: Warning: `off_t' previously declared here ../include/wine/port.h:55: Error: conflicting types for `pid_t' /usr/include/sys/types.h:55: Error: previous declaration of `pid_t' ../include/wine/port.h:58: Warning: redefinition of `size_t' /usr/include/sys/types.h:89: Warning: `size_t' previously declared here ../include/wine/port.h:61: Warning: redefinition of `ssize_t' /usr/include/sys/types.h:94: Warning: `ssize_t' previously declared here Any suggestions? Thanks Steven

2 2

Re: DefineDosDevice - ??
by Martin Wilck 17 Sep '02

17 Sep '02

Am Die, 2002-09-17 um 20.48 schrieb Mike McCormack: > Did you get my other mails? I'll include the text again... they don't > seem to have made it to wine-devel, so I'm wondering if they got > anywhere at all... No they didn't, at least not to me. Thanks for resending... > BTW. The PAM module you are talking about was a goal of Samba TNG. "Was" - does that mean the project is dead? I reckon that the "winbind" module of the current Samba release is pretty close to what we want in terms of host, user, and group lookup. > I think that can be done with a NetBIOS QUERY packet with "*" as the > name to query. You'll then get every machine on your local network > sending a QUERY RESPONSE packet back to you with the machine's name. > > The operation is similar to the code to resolve a NetBIOS name (see > NB_Lookup in files/smb.c) I need yet to understand how all these things relate. Winsock may use NetBIOS as a service provider, but NetBIOS seems to offer an independent interface to other APIs as well, right? If I understand you right, the Netbios stuff is then located somewhere in kernel32. Is the winsock provider an independent package or part of the NetBIOS core? > The named pipes code needs to be rewritten to work through SMB so that > we can support DCOM clients (computer to computer). Supporting a DCOM > server is a problem because Samba is usually in the way on the ports we > need to listen to... it would be nice to have some way for Samba and > Wine to work together... a Netbios kernel module perhaps? IMO this raises more fundamental questions about the role wine should play. Samba is a service offered by the Unix system on which wine is running. If wine were to grab the NetBIOS ports, it would take over this service functionality; I doubt that's a good approach. Wine could perhaps offer services on an IP alias instead, somewhat similar as described in http://www.deschner.de/gd/dual_samba.html > shell32 manages passwords and shares through MPR.DLL. We need to add > some code to show the Network Neighbourhood icon and probe any connected > shares, connect new shares, etc to shell32. > > If you need something specific, I'll see what I can do, but a full > implementation is probably a bit much for this weekend ;-) I think it needs to be clarified what we're actually heading for. As I said, I consider it potentially dangerous if wine offers services on the network bypassing the ordinary Unix security mechanism. Acting as a client is a different story, I guess we want maximum functionality in that area. When it comes to User authentication, I am strongly for wine communicating with the Unix system (e.g. PAM). Then if PAM supports NT domain authentication (through samba or whatever), Active directory AKA LDAP authentication, etc., wine would, too. We'd just have to ensure that we don't loose too much on our way through the Unix layer. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

WineLib with MSVCRT
by steve.lustbader＠philips.com 17 Sep '02

17 Sep '02

What is the proper way to use the MSVCRT in WineLib? I tried adding a -I/usr/local/include/wine/msvcrt to the list of includes and -nostdinc to CXXEXTRA, but then gcc can't find stdarg.h, which is included in windows.h via winbase.h. If I use -nostdinc++, gcc is able to find stdarg.h, but it runs into problems with other files, such iostream.h. Finally, if I don't use either -nostdinc or -nostdinc++, gcc complains about types being redefined, such as wint_t (as an unsigned short int in /usr/include/_G_config.h but WCHAR in /usr/local/include/wine/msvcrt/wctype.h). It seems like using -nostdinc would be the right way, but does that mean that Wine needs to include its own copy of stdarg.h and related files? -Steve

3 2

PATCH: workaround for ms typo
by Michael Stefaniuc 17 Sep '02

17 Sep '02

Hello, this email is CC'ed to wine-devel because it's controversial. MS made a typo in CHOOSECOLOR (commdlg.h) and kept it till today (at least that's what msdn says): the struct member hInstance is a HWND instead of a HINSTANCE. Until now it wasn't a problem in wine but with the conversions of the handles to void* a lot of casts are necessary. And this casts are looking just wrong: cast to HINSTANCE when using the hInstance member as rvalue and cast to HWND when using it as lvalue. The casts looks so wrong so that we would need comments like "Yes, this cast is needed, see struct CHOOSECOLOR in include/commdlg.h". The attached patch fixes the typo for wine (but keeps it for compatibility reasons for winelib) and removes the need of some ugly casts. License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - workaround for MS typo bye michael -- 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 1

Direct3D v8
by Ann and Jason Edmeades 16 Sep '02

16 Sep '02

Hello, What is the current state of affairs regarding DirectX (8) support in wine. With Transgaming producing a version which appears to work well from what I read on the Internet, what is happening about getting support for it in the wine tree - Is the intention to wait and see what Transgaming do? The reason I ask - Not to start a political debate with pros and cons of Transgaming, but more because as a learning exercise with regard to 3d graphics, I started fiddling with Direct X 8 support and have some sample code which runs some simple Direct3D samples and most of a sequence of tutorials. (9 out of 11 work reasonably well). I dont have a problem with the code remaining personal to me and probably archived, as I have learnt a lot by doing it (which was my original aim), but if it is agreed that adding directx 8 support completely different to the Transgaming code is ok, then I may try to submit some patches. Note the current code is nowhere near ideal, so dont get your hopes up. Specifically, it exports X11DRV_get_client_window from X11DRV as a means of getting the X window from the HWND, which is not clean. It does not use a HAL (which is where the current ddraw code was starting to head), it calls all the opengl calls inline. I have only tested on one machine with one level of mesa (tough! thats all I have). It also has all the c parts in the d3d8 directory, completely seperate (and in some cases duplicating code from the ddraw code), which may or may not be desired. I also dont have a clue about the configure tests and makefile.in, so I have just a basic structure which works enough for me. I'm also relatively certain I havent necessarily used the highest performing code everywhere, I have done the best I could with my limited knowledge. The way I look at it would be a starting point for others to work from. I could make a drop of the code on a website if anyone wants to see how bad it is first :-) Anyway, thoughts please? Jason

8 17

Re: memory/virtual.c: ROUND_SIZE() bugfix + .SYS loading
by Alexandre Julliard 16 Sep '02

16 Sep '02

Jan Kratochvil <short(a)ucw.cz> writes: > I had incorrect warnings "Section %.8s too large (%lx+%lx/%lx)" during loading > of some low-level system libraries. It got fixed by the attached > "wine-memory-virtual.c-too_large_section.diff" which changes (I think fixes) > ROUND_SIZE() behaviour. It also comments ROUND_ADDR() and ROUND_SIZE(), I hope > I guessed its intended description from the style of its usage around the code. No, ROUND_SIZE is supposed to return an aligned size, which you use together with an aligned address. The normal pattern is to use ROUND_SIZE and ROUND_ADDR together. We don't bother to round addresses in image mapping because all the code assumes the image has correct section alignment already. > Attached "wine-memory-virtual.c-mmap_cache-preliminary.diff" is just a RFC as > I found out that I was unable to load some .SYS files as they were being > attempted to be loaded with page-overlapping sections, unaligned offsets and > incompatible protections. Therefore I had to implement my own mapping cache and > handle the overlapping/merging myself. It would be more simple/clean to use > Linux /proc/$$/maps mmap map but it would be probably no-no as it is > Linux-dependent. I think this is complete overkill. Mapping unaligned binaries is a very unusual case and should be treated as such. There's no need to maintain such a complex structure, or add support for non page aligned mmaps, for such an exotic feature. Probably what you want is to create a separate map_image_unaligned function to map images that don't have a proper section alignment, using read() and not worrying about protections at all. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Replace static initializers with a proper #define in .h files
by Alexandre Julliard 16 Sep '02

16 Sep '02

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Alexandre, your patch committed at 02/08/14 16:09:55 (Builtin modules > must be aligned on 64K boundary) completely kills any attempts to > minimize sizes of winelib executables. Is it really necessary? Yes, some apps need modules to be properly aligned. Note that this stuff will never be paged in so it only wastes a bit of disk space. -- Alexandre Julliard julliard(a)winehq.com

1 0

Question about "undefined" functions
by Sylvain Petreolle 16 Sep '02

16 Sep '02

Hi, I have problems with the following functions: 17 0x4073bf2f (USER32.DLL.GetTaskmanWindow+0xdf in user32.dll.so) (ebp=405c24d0) 18 0x4073bfa3 (USER32.DLL.GetTaskmanWindow+0x153 in user32.dll.so) (ebp=405c2508) 19 0x40742936 (USER32.DLL.CallWindowProcA+0x136 in user32.dll.so) (ebp=405c253c) 20 0x4071c21b (USER32.DLL.DispatchMessageA+0xbb in user32.dll.so) (ebp=405c2570 In some programs this call stack appears when going to debugger and is causing 0x0 read acess.Digging in the source shows that these functions are only defined by a stdcall in the spec file of user32. the result is a return '0x0000' in the user32.spec.c: "\tjmp GetTaskmanWindow\n" "\tret $0x0000\n" Are these functions intended to return 0x0 ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: winedump: selective search also by name
by Eric Pouech 16 Sep '02

16 Sep '02

> > I am missing some general utility library such as GLib, Qt, NSPR or APR to > > provide general datastructures such as hashes etc. Maybe it is provided by W32? > > Therefore /* FIXME: Replace with some hash such as GHashTable */. it'll be a bad idea to use extra libs like Qt or Glib in Wine, just for that (note also, that in your case, a simple binary search would be enough IMO (compared to the current linear search) A+

2 1

Re: Shell icons - legal
by Jeff Smith 16 Sep '02

16 Sep '02

1 0

DefineDosDevice - ??
by Martin Wilck 16 Sep '02

16 Sep '02

This function is currently a stub - are there any major problems supporting it, i.e. supporting dynamic creation and deletion of DOS drives? Does Wine have a notion of Device paths that look like "\\Device\\Harddisk2\\Partition1" at all? Thinking about it, does something like this make sense at all in the Wine context? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

winebuild/main.c: Include ctype
by Uwe Bonnes 16 Sep '02

16 Sep '02

Changelog: tools/winebuild/main.c Include ctype.h as isdigit is used -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/tools/winebuild/main.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/main.c,v retrieving revision 1.37 diff -u -w -r1.37 main.c --- wine/tools/winebuild/main.c 12 Sep 2002 22:51:20 -0000 1.37 +++ wine/tools/winebuild/main.c 16 Sep 2002 16:00:04 -0000 @@ -26,6 +26,7 @@ #include "wine/port.h" #include <assert.h> +#include <ctype.h> #include <stdio.h> #include <errno.h> #include <string.h>

1 0

Re: Fixed selecting multiple files in common file dialog 95-style
by Huw Davies 16 Sep '02

16 Sep '02

On Sun, Sep 15, 2002 at 08:31:27PM +0200, Josef Meixner wrote: > Index: dlls/commdlg/filedlg95.c > =================================================================== > RCS file: /home/wine/wine/dlls/commdlg/filedlg95.c,v > retrieving revision 1.80 > diff -r1.80 filedlg95.c [snip] > 1457c1464,1466 > < memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); > --- > > memset( ofn->lpstrFile + nSizePath, 0, sizeof(WCHAR) ); > > memcpy( ofn->lpstrFile + nSizePath + sizeof(WCHAR), lpstrFileList, > > sizeUsed*sizeof(WCHAR) ); > 1463,1466c1472,1483 > < WideCharToMultiByte(CP_ACP, 0, lpstrPathSpec, -1, > < ofn->lpstrFile, ofn->nMaxFile, NULL, NULL); > < WideCharToMultiByte(CP_ACP, 0, lpstrFileList, sizeUsed, > < &ofn->lpstrFile[nSizePath], ofn->nMaxFile - nSizePath, NULL, NULL); > --- > > if (ofn->lpstrFile != NULL) > > { > > WideCharToMultiByte(CP_ACP, 0, lpstrPathSpec, -1, > > ofn->lpstrFile, ofn->nMaxFile, NULL, NULL); > > if (ofn->nMaxFile > nSizePath + 1) > > { > > ofn->lpstrFile[nSizePath] = '\0'; > > WideCharToMultiByte(CP_ACP, 0, lpstrFileList, sizeUsed, > > ofn->lpstrFile + nSizePath + 1, > > ofn->nMaxFile - nSizePath, NULL, NULL); > > } > > } > The last two hunks of this patch aren't right. Alexandre, please use this one instead. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

PATCH: Fix MoveFileEx() flags in MSVCRT rename()
by Martin Wilck 16 Sep '02

16 Sep '02

[ Forwarding to wine-devel because it may be controversial, please see comments below. ] Patch: rename.diff Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Patch against: CVS 2002-09-16 Modified files: - wine/dlls/msvcrt: file.c Log Message: * Fix MoveFileEx() flags in MSVCRT rename()/_wrename() Comment: >From MSDN docs for rename()/_wrename(): "The new name must not be the name of an existing file or directory. You can use rename to move a file from one directory or device to another by giving a different path in the newname argument." This clearly says that MOVEFILE_REPLACE_EXISTING should _not_ be set, while MOVEFILE_COPY_ALLOWED is necessary to allow moving files between drives. I have verified that windows actually behaves as stated in the MSDN excerpt above. Perhaps someone knows why the flags have been set this way - is it a workaround for some hidden feature in some Windows version? Index: dlls/msvcrt/file.c =================================================================== RCS file: /home/wine/wine/dlls/msvcrt/file.c,v retrieving revision 1.37 diff -u -r1.37 file.c --- dlls/msvcrt/file.c 12 Sep 2002 22:28:01 -0000 1.37 +++ dlls/msvcrt/file.c 16 Sep 2002 09:16:07 -0000 @@ -2107,7 +2107,7 @@ int MSVCRT_rename(const char *oldpath,const char *newpath) { TRACE(":from %s to %s\n",oldpath,newpath); - if (MoveFileExA(oldpath, newpath, MOVEFILE_REPLACE_EXISTING)) + if (MoveFileExA(oldpath, newpath, MOVEFILE_COPY_ALLOWED)) return 0; TRACE(":failed (%ld)\n",GetLastError()); MSVCRT__set_errno(GetLastError()); @@ -2120,7 +2120,7 @@ int _wrename(const WCHAR *oldpath,const WCHAR *newpath) { TRACE(":from %s to %s\n",debugstr_w(oldpath),debugstr_w(newpath)); - if (MoveFileExW(oldpath, newpath, MOVEFILE_REPLACE_EXISTING)) + if (MoveFileExW(oldpath, newpath, MOVEFILE_COPY_ALLOWED)) return 0; TRACE(":failed (%ld)\n",GetLastError()); MSVCRT__set_errno(GetLastError()); -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: Replace static initializers with a proper #define in .h files
by Francois Gouget 16 Sep '02

16 Sep '02

On Sat, 14 Sep 2002, Dmitry Timoshkov wrote: > Hello. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Replace static initializers with a proper #define in .h files. Are defines really better? It seemed to me that they had at least one disadvantage: the value is duplicated each time the define is used. Hmmm, I just retested and it looks as if I was wrong. Anyway, what are the pros and cons? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

3 5

Strange behaviour in directory/drive traversal
by Sylvain Petreolle 16 Sep '02

16 Sep '02

I installed a program and want to launch it. Configuration : ls -ld /c lrwxrwxrwx 1 root root 7 déc 21 2001 /c -> /home/c ls -ld /c/Program\ Files/Yahoo\!/Messenger/YPager.exe -rwxr-xr-x 1 syl wine 1044480 mai 28 17:52 /c/Program Files/Yahoo\!/Messenger/YPager.exe C drive is set to : [Drive C] "Path" = "/home/c" "Type" = "hd" "Filesystem" = "win95" I got: [syl@snoop syl]$ wine /c/Program\ Files/Yahoo\!/Messenger/YPager.exe Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive wine: cannot find '/c/Program Files/Yahoo!/Messenger/YPager.exe' I go to drive C: [syl@snoop syl]$ cd /c [syl@snoop c]$ wine /c/Program\ Files/Yahoo\!/Messenger/YPager.exe Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive wine: cannot find '/c/Program Files/Yahoo!/Messenger/YPager.exe' I finally go to the program directory: [syl@snoop c]$ cd /c/Program\ Files/Yahoo\!/Messenger/ [syl@snoop Messenger]$ wine YPager.exe and it launches ... Comments ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Wine Hides On-board RAM
by Ian D. Stewart 16 Sep '02

16 Sep '02

On 2002.08.18 12:21 Andreas Mohr wrote: > On Sun, Aug 18, 2002 at 11:32:54AM -0400, Ian D. Stewart wrote: > > I have recently noticed an unusual side-effect of running Wine. > When I > > first start up my system, /proc/meminfo reports MemTotal as 256892 > kb. > > After running Wine for awhile, /proc/meminfo reports MemTotal as > 32680 > > kb. The system performs as if it only had 32 MB of RAM. A reboot > of > > the system resets total memory to the proper value. > > > > My question is: > > > > 1) Has anybody else encountered this? > > 2) Does anyone know what causes this, or better yet how to avoid it? > > 3) Is there anyway to recover the lost RAM short of a reboot? > > Huh ? This is very, very, VERY strange ! > Something like this should never happen. > Are you sure it's caused by Wine only, or maybe it is due to faulty > memory > instead ? (and thus the board/Linux notices that only 32MB are useable > and resorts to accessing 32MB only). Well I can't say with absolute certainty that it's caused by Wine, but the system runs without any problems for extended periods of time so long as I don't run Wine, and consistently 'loses' memory when I *do* run wine. I don't know exactly what's going on. I do know that there appears to be some sort of threshold that is reached at which point the memory hiding occurs (e.g., the same issue arises whether I run Wine for 5 hours at one shot or for 30 minutes a day for 10 days) and the threshold isn't 'reset' until I reboot. > > Again, I'm utterly puzzled when hearing such a story. > Or maybe Wine accesses some Linux memory management function in some > way > that causes Linux to tamper with the value for some reason ? > This wouldn't be the first time that Wine is the only program to > reveal > some severe bug in Linux memory management... > > Definitely try upgrading your kernel, too. I have no problem with upgrading, but I would like to know *why* I am upgrading (i.e., what bug is causing the problem, and how does the new kernel address the bug). To do otherwise strikes me as being equivelant to the tendency in the Windows community whenever something odd happens. Thanx for the input, Andreas. Ian

5 8

ntdll.dll vs. ntoskrnl.exe
by Jan Kratochvil 15 Sep '02

15 Sep '02

Hi, What are the differences between "ntdll.dll" and "ntoskrnl.exe"? In Windows XP they exist both and they export similiar (although different) set of functions. Wine implements just "ntdll.dll". Some W32 binary wants to import functions from "ntoskrnl.exe" from me, should I make an alias of Wine "ntdll.dll" to "ntoskrnl.exe" and try to fill the missing funcs? I have never seen W32 programming before as I am *IX coder. Thanks, Jan Kratochvil

5 8

Re: Direct3D v8
by Sylvain Petreolle 15 Sep '02

15 Sep '02

did someone try to compile it with winemaker ? it seems to have only m$ project files... --- "P. Christeas" <p_christ(a)hol.gr> a écrit : > I just saw a sourceforge project about that. See: > http://sourceforge.net/projects/dxglwrap/ > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Building WINE under Microsoft Services for UNIX
by Steven Edwards 15 Sep '02

15 Sep '02

Hola, I wanted to start working on a port to SFU now that we are making progress on the Cygwin and Mingw port and am having a little trouble. SFU doesnt come with binutils and has a older gcc (2.7). I have upgraded the gcc to the 3.x release and am having trouble getting WINE to build. SFU has support for building .SO and .dll files although I dont really know how it differs from Linux is this regard. Attached is my config.log Thanks Steven This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Wine configure 20020904, which was generated by GNU Autoconf 2.53. Invocation command line was $ ./configure ## --------- ## ## Platform. ## ## --------- ## hostname = ph33r uname -m = x86 uname -r = 3.0 uname -s = Interix uname -v = SP-7.0.1701.1 /usr/bin/uname -p = AMD Duron /bin/uname -X = System = Interix Node = ph33r Release = 3.0 Version = SP-7.0.1701.1 Machine = x86 Processor = AMD Duron HostSystem = Windows HostRelease = SP3 HostVersion = 5.0 /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /bin PATH: /usr/contrib/bin PATH: /usr/X11R5/bin PATH: /usr/local/bin PATH: /usr/contrib/win32/bin PATH: /dev/fs/C/WINNT/system32 PATH: /dev/fs/C/SFU/common ## ----------- ## ## Core tests. ## ## ----------- ## configure:1300: checking build system type configure:1318: result: i386-pc-interix3 configure:1326: checking host system type configure:1340: result: i386-pc-interix3 configure:1348: checking whether make sets ${MAKE} configure:1368: result: yes configure:1423: checking for gcc configure:1439: found /usr/contrib/bin/gcc configure:1449: result: gcc configure:1693: checking for C compiler version configure:1696: gcc --version </dev/null >&5 cygnus-2.7.2-970404 configure:1699: $? = 0 configure:1701: gcc -v </dev/null >&5 Using builtin specs. gcc version cygnus-2.7.2-970404 configure:1704: $? = 0 configure:1706: gcc -V </dev/null >&5 gcc: argument to `-V' is missing configure:1709: $? = 1 configure:1735: checking for C compiler default output configure:1738: gcc conftest.c >&5 configure:1741: $? = 0 configure:1774: result: a.out configure:1779: checking whether the C compiler works configure:1785: ./a.out configure:1788: $? = 0 configure:1803: result: yes configure:1810: checking whether we are cross compiling configure:1812: result: no configure:1815: checking for suffix of executables configure:1817: gcc -o conftest conftest.c >&5 configure:1820: $? = 0 configure:1842: result: configure:1848: checking for suffix of object files configure:1872: gcc -c conftest.c >&5 configure:1875: $? = 0 configure:1894: result: o configure:1898: checking whether we are using the GNU C compiler configure:1925: gcc -c conftest.c >&5 configure:1928: $? = 0 configure:1931: test -s conftest.o configure:1934: $? = 0 configure:1946: result: yes configure:1952: checking whether gcc accepts -g configure:1976: gcc -c -g conftest.c >&5 configure:1979: $? = 0 configure:1982: test -s conftest.o configure:1985: $? = 0 configure:1995: result: yes configure:2022: gcc -c -g -O2 conftest.c >&5 conftest.c:2: syntax error before `me' configure:2025: $? = 1 configure: failed program was: #ifndef __cplusplus choke me #endif configure:2140: checking how to run the C preprocessor configure:2166: gcc -E conftest.c configure:2172: $? = 0 configure:2199: gcc -E conftest.c configure:2195: ac_nonexistent.h: No such file or directory configure:2205: $? = 1 configure: failed program was: #line 2194 "configure" #include "confdefs.h" #include <ac_nonexistent.h> configure:2242: result: gcc -E configure:2257: gcc -E conftest.c configure:2263: $? = 0 configure:2290: gcc -E conftest.c configure:2286: ac_nonexistent.h: No such file or directory configure:2296: $? = 1 configure: failed program was: #line 2285 "configure" #include "confdefs.h" #include <ac_nonexistent.h> configure:2336: checking for the directory containing the Wine tools configure:2360: result: $(TOPOBJDIR) configure:2367: checking for X configure:2583: result: libraries /usr/X11R5/lib, headers /usr/X11R5/include configure:2740: gcc -o conftest -g -O2 conftest.c -L/usr/X11R5/lib -lX11 >&5 configure:2743: $? = 0 configure:2746: test -s conftest configure:2749: $? = 0 configure:2887: checking for gethostbyname configure:2930: gcc -o conftest -g -O2 conftest.c >&5 configure:2933: $? = 0 configure:2936: test -s conftest configure:2939: $? = 0 configure:2949: result: yes configure:3082: checking for connect configure:3125: gcc -o conftest -g -O2 conftest.c >&5 configure:3128: $? = 0 configure:3131: test -s conftest configure:3134: $? = 0 configure:3144: result: yes configure:3210: checking for remove configure:3253: gcc -o conftest -g -O2 conftest.c >&5 configure:3256: $? = 0 configure:3259: test -s conftest configure:3262: $? = 0 configure:3272: result: yes configure:3338: checking for shmat configure:3381: gcc -o conftest -g -O2 conftest.c >&5 configure:3384: $? = 0 configure:3387: test -s conftest configure:3390: $? = 0 configure:3400: result: yes configure:3475: checking for IceConnectionNumber in -lICE configure:3508: gcc -o conftest -g -O2 -L/usr/X11R5/lib conftest.c -lICE >&5 ld: cannot open -lICE: No such file or directory configure:3511: $? = 1 configure: failed program was: #line 3482 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char IceConnectionNumber (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { IceConnectionNumber (); ; return 0; } configure:3528: result: no configure:3542: checking for bison configure:3571: result: no configure:3542: checking for byacc configure:3571: result: no configure:3583: checking for flex configure:3612: result: no configure:3583: checking for lex configure:3599: found /bin/lex configure:3609: result: lex configure:3622: checking for yywrap in -lfl configure:3655: gcc -o conftest -g -O2 conftest.c -lfl >&5 ld: cannot open -lfl: No such file or directory configure:3658: $? = 1 configure: failed program was: #line 3629 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char yywrap (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { yywrap (); ; return 0; } configure:3675: result: no configure:3680: checking for yywrap in -ll configure:3713: gcc -o conftest -g -O2 conftest.c -ll >&5 configure:3716: $? = 0 configure:3719: test -s conftest configure:3722: $? = 0 configure:3733: result: yes configure:3744: checking lex output file root configure:3755: lex conftest.l configure:3758: $? = 0 configure:3770: result: lex.yy configure:3775: checking whether yytext is a pointer configure:3791: gcc -o conftest -g -O2 conftest.c -ll >&5 configure:3794: $? = 0 configure:3797: test -s conftest configure:3800: $? = 0 configure:3812: result: yes configure:3828: checking for yacc configure:3844: found /bin/yacc configure:3854: result: yacc configure:3875: checking for lex configure:3891: found /bin/lex configure:3901: result: lex configure:3960: checking for ld configure:3976: found /usr/contrib/bin/ld configure:3987: result: ld configure:4040: checking for ar configure:4056: found /bin/ar configure:4067: result: ar configure:4120: checking for ranlib configure:4136: found /bin/ranlib configure:4147: result: ranlib configure:4200: checking for strip configure:4216: found /bin/strip configure:4227: result: strip configure:4280: checking for windres configure:4307: result: false configure:4331: checking for a BSD-compatible install configure:4385: result: /bin/install -c configure:4396: checking whether ln -s works configure:4400: result: yes configure:4407: checking whether ln works configure:4419: result: no, using cp -p configure:4425: checking for c2man configure:4452: result: $(TOPSRCDIR)/tools/c2man.pl configure:4461: checking for ldconfig configure:4492: result: true configure:4504: checking for lclint configure:4533: result: no configure:4504: checking for lint configure:4533: result: no configure:4549: checking for sqrt in -lm configure:4582: gcc -o conftest -g -O2 conftest.c -lm >&5 configure:4564: warning: conflicting types for built-in function `sqrt' configure:4585: $? = 0 configure:4588: test -s conftest configure:4591: $? = 0 configure:4602: result: yes configure:4614: checking for i386_set_ldt in -li386 configure:4647: gcc -o conftest -g -O2 conftest.c -li386 -lm >&5 ld: cannot open -li386: No such file or directory configure:4650: $? = 1 configure: failed program was: #line 4621 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char i386_set_ldt (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { i386_set_ldt (); ; return 0; } configure:4667: result: no configure:4679: checking for _oss_ioctl in -lossaudio configure:4712: gcc -o conftest -g -O2 conftest.c -lossaudio -lm >&5 ld: cannot open -lossaudio: No such file or directory configure:4715: $? = 1 configure: failed program was: #line 4686 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char _oss_ioctl (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { _oss_ioctl (); ; return 0; } configure:4732: result: no configure:4747: checking for iswalnum configure:4790: gcc -o conftest -g -O2 conftest.c -lm >&5 /tmp/ccky4zOe.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:4780: undefined reference to `iswalnum' configure:4793: $? = 1 configure: failed program was: #line 4752 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char iswalnum (); below. */ #include <assert.h> /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char iswalnum (); char (*f) (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_iswalnum) || defined (__stub___iswalnum) choke me #else f = iswalnum; #endif ; return 0; } configure:4809: result: no configure:4818: checking for iswalnum in -lw configure:4851: gcc -o conftest -g -O2 conftest.c -lw -lm >&5 ld: cannot open -lw: No such file or directory configure:4854: $? = 1 configure: failed program was: #line 4825 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char iswalnum (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { iswalnum (); ; return 0; } configure:4871: result: no configure:4889: checking for gethostbyname configure:4951: result: yes configure:5031: checking for connect configure:5093: result: yes configure:5173: checking for inet_aton configure:5216: gcc -o conftest -g -O2 conftest.c -lm >&5 configure:5219: $? = 0 configure:5222: test -s conftest configure:5225: $? = 0 configure:5235: result: yes configure:5312: checking for _xpg4_setrunelocale in -lxpg4 configure:5345: gcc -o conftest -g -O2 conftest.c -lxpg4 -lm >&5 ld: cannot open -lxpg4: No such file or directory configure:5348: $? = 1 configure: failed program was: #line 5319 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char _xpg4_setrunelocale (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { _xpg4_setrunelocale (); ; return 0; } configure:5365: result: no configure:5377: checking for mmap in -lmmap configure:5410: gcc -o conftest -g -O2 conftest.c -lmmap -lm >&5 ld: cannot open -lmmap: No such file or directory configure:5413: $? = 1 configure: failed program was: #line 5384 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char mmap (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { mmap (); ; return 0; } configure:5430: result: no configure:5444: checking for ANSI C header files configure:5458: gcc -E conftest.c configure:5464: $? = 0 configure:5551: gcc -o conftest -g -O2 conftest.c -lm >&5 configure:5554: $? = 0 configure:5556: ./conftest configure:5559: $? = 0 configure:5573: result: yes configure:5597: checking for sys/types.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for sys/stat.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for stdlib.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for string.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for memory.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for strings.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for inttypes.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5638: inttypes.h: No such file or directory configure:5613: $? = 1 configure: failed program was: #line 5602 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <inttypes.h> configure:5629: result: no configure:5597: checking for stdint.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5638: stdint.h: No such file or directory configure:5613: $? = 1 configure: failed program was: #line 5602 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <stdint.h> configure:5629: result: no configure:5597: checking for unistd.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5655: checking jpeglib.h usability configure:5664: gcc -c -g -O2 conftest.c >&5 configure:5692: jpeglib.h: No such file or directory configure:5667: $? = 1 configure: failed program was: #line 5657 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <jpeglib.h> configure:5682: result: no configure:5686: checking jpeglib.h presence configure:5693: gcc -E conftest.c configure:5689: jpeglib.h: No such file or directory configure:5699: $? = 1 configure: failed program was: #line 5688 "configure" #include "confdefs.h" #include <jpeglib.h> configure:5717: result: no configure:5735: checking for jpeglib.h configure:5742: result: no configure:5849: checking X11/Xlib.h usability configure:5858: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:5861: $? = 0 configure:5864: test -s conftest.o configure:5867: $? = 0 configure:5876: result: yes configure:5880: checking X11/Xlib.h presence configure:5887: gcc -E -I/usr/X11R5/include conftest.c configure:5893: $? = 0 configure:5911: result: yes configure:5929: checking for X11/Xlib.h configure:5936: result: yes configure:5949: checking for X11/XKBlib.h configure:5962: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:5957: X11/XKBlib.h: No such file or directory configure:5965: $? = 1 configure: failed program was: #line 5954 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/XKBlib.h> configure:5981: result: no configure:6052: WARNING: Xkb extension not found, Wine will be built without it configure:6063: checking for X11/extensions/XShm.h configure:6076: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6079: $? = 0 configure:6082: test -s conftest.o configure:6085: $? = 0 configure:6095: result: yes configure:6101: checking for XShmQueryExtension in -lXext configure:6134: gcc -o conftest -g -O2 -I/usr/X11R5/include conftest.c -lXext -L/usr/X11R5/lib -lXext -lX11 -lm >&5 /tmp/ccFkOVtc.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:6126: undefined reference to `XShmQueryExtension' configure:6137: $? = 1 configure: failed program was: #line 6108 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char XShmQueryExtension (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { XShmQueryExtension (); ; return 0; } configure:6154: result: no configure:6177: checking for X11/Xutil.h configure:6190: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6193: $? = 0 configure:6196: test -s conftest.o configure:6199: $? = 0 configure:6209: result: yes configure:6225: checking for X11/extensions/shape.h configure:6241: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6244: $? = 0 configure:6247: test -s conftest.o configure:6250: $? = 0 configure:6260: result: yes configure:6266: checking for XShapeQueryExtension in -lXext configure:6299: gcc -o conftest -g -O2 -I/usr/X11R5/include conftest.c -lXext -L/usr/X11R5/lib -lXext -lX11 -lm >&5 configure:6302: $? = 0 configure:6305: test -s conftest configure:6308: $? = 0 configure:6319: result: yes configure:6342: checking for X11/extensions/xf86dga.h configure:6355: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6350: X11/extensions/xf86dga.h: No such file or directory configure:6358: $? = 1 configure: failed program was: #line 6347 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/extensions/xf86dga.h> configure:6374: result: no configure:6516: WARNING: DGA extension not found, Wine will be built without it configure:6527: checking for X11/extensions/xf86vmode.h configure:6540: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6535: X11/extensions/xf86vmode.h: No such file or directory configure:6543: $? = 1 configure: failed program was: #line 6532 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/extensions/xf86vmode.h> configure:6559: result: no configure:6633: WARNING: XFree86 VMODE extension not found, Wine will be built without it configure:6644: checking for X11/extensions/Xvlib.h configure:6657: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6652: X11/extensions/Xvlib.h: No such file or directory configure:6660: $? = 1 configure: failed program was: #line 6649 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/extensions/Xvlib.h> configure:6676: result: no configure:6750: WARNING: XVideo extension not found, Wine will be built without it configure:6761: checking for X11/extensions/Xrender.h configure:6774: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6769: X11/extensions/Xrender.h: No such file or directory configure:6777: $? = 1 configure: failed program was: #line 6766 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/extensions/Xrender.h> configure:6793: result: no configure:6836: checking GL/gl.h usability configure:6845: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6873: GL/gl.h: No such file or directory configure:6848: $? = 1 configure: failed program was: #line 6838 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <GL/gl.h> configure:6863: result: no configure:6867: checking GL/gl.h presence configure:6874: gcc -E -I/usr/X11R5/include conftest.c configure:6870: GL/gl.h: No such file or directory configure:6880: $? = 1 configure: failed program was: #line 6869 "configure" #include "confdefs.h" #include <GL/gl.h> configure:6898: result: no configure:6916: checking for GL/gl.h configure:6923: result: no configure:6836: checking GL/glx.h usability configure:6845: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6873: GL/glx.h: No such file or directory configure:6848: $? = 1 configure: failed program was: #line 6838 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <GL/glx.h> configure:6863: result: no configure:6867: checking GL/glx.h presence configure:6874: gcc -E -I/usr/X11R5/include conftest.c configure:6870: GL/glx.h: No such file or directory configure:6880: $? = 1 configure: failed program was: #line 6869 "configure" #include "confdefs.h" #include <GL/glx.h> configure:6898: result: no configure:6916: checking for GL/glx.h configure:6923: result: no configure:7374: checking ncurses.h usability configure:7383: gcc -c -g -O2 conftest.c >&5 configure:7411: ncurses.h: No such file or directory configure:7386: $? = 1 configure: failed program was: #line 7376 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <ncurses.h> configure:7401: result: no configure:7405: checking ncurses.h presence configure:7412: gcc -E conftest.c configure:7408: ncurses.h: No such file or directory configure:7418: $? = 1 configure: failed program was: #line 7407 "configure" #include "confdefs.h" #include <ncurses.h> configure:7436: result: no configure:7454: checking for ncurses.h configure:7461: result: no configure:7722: checking for getbkgd configure:7765: gcc -o conftest -g -O2 conftest.c -lm >&5 /tmp/ccRhSFca.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:7755: undefined reference to `getbkgd' configure:7768: $? = 1 configure: failed program was: #line 7727 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getbkgd (); below. */ #include <assert.h> /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getbkgd (); char (*f) (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_getbkgd) || defined (__stub___getbkgd) choke me #else f = getbkgd; #endif ; return 0; } configure:7784: result: no configure:7722: checking for resizeterm configure:7765: gcc -o conftest -g -O2 conftest.c -lm >&5 /tmp/ccPUiDhe.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:7755: undefined reference to `resizeterm' configure:7768: $? = 1 configure: failed program was: #line 7727 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char resizeterm (); below. */ #include <assert.h> /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char resizeterm (); char (*f) (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_resizeterm) || defined (__stub___resizeterm) choke me #else f = resizeterm; #endif ; return 0; } configure:7784: result: no configure:7800: checking for cupsGetPPD in -lcups configure:7833: gcc -o conftest -g -O2 conftest.c -lcups -lm >&5 ld: cannot open -lcups: No such file or directory configure:7836: $? = 1 configure: failed program was: #line 7807 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char cupsGetPPD (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { cupsGetPPD (); ; return 0; } configure:7853: result: no configure:7976: checking for sane-config configure:8003: result: no configure:8201: checking for FT_Init_FreeType in -lfreetype configure:8234: gcc -o conftest -g -O2 conftest.c -lfreetype -L/usr/X11R5/lib -lm >&5 ld: cannot open -lfreetype: No such file or directory configure:8237: $? = 1 configure: failed program was: #line 8208 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char FT_Init_FreeType (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { FT_Init_FreeType (); ; return 0; } configure:8254: result: no configure:8534: checking for parport header/ppdev.h configure:8558: gcc -c -g -O2 conftest.c >&5 configure:8540: linux/ppdev.h: No such file or directory configure:8561: $? = 1 configure: failed program was: #line 8539 "configure" #include "confdefs.h" #include <linux/ppdev.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ioctl (1,PPCLAIM,0) ; return 0; } configure:8578: result: no configure:8589: checking for va_copy configure:8615: gcc -o conftest -g -O2 conftest.c -lm >&5 /tmp/cciMfKJa.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:8606: undefined reference to `va_copy' configure:8618: $? = 1 configure: failed program was: #line 8594 "configure" #include "confdefs.h" #include <stdarg.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { va_list ap1, ap2; va_copy(ap1,ap2); ; return 0; } configure:8635: result: no configure:8645: checking for __va_copy configure:8671: gcc -o conftest -g -O2 conftest.c -lm >&5 configure:8674: $? = 0 configure:8677: test -s conftest configure:8680: $? = 0 configure:8691: result: yes configure:8702: checking for GNU style IPX support configure:8727: gcc -c -g -O2 conftest.c >&5 configure:8709: netipx/ipx.h: No such file or directory configure:8730: $? = 1 configure: failed program was: #line 8707 "configure" #include "confdefs.h" #include <sys/socket.h> #include <netipx/ipx.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ((struct sockaddr_ipx *)0)->sipx_family == AF_IPX ; return 0; } configure:8747: result: no configure:8760: checking for linux style IPX support configure:8786: gcc -c -g -O2 conftest.c >&5 configure:8767: asm/types.h: No such file or directory configure:8768: linux/ipx.h: No such file or directory configure:8789: $? = 1 configure: failed program was: #line 8765 "configure" #include "confdefs.h" #include <sys/socket.h> #include <asm/types.h> #include <linux/ipx.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ((struct sockaddr_ipx *)0)->sipx_family == AF_IPX ; return 0; } configure:8806: result: no configure:8834: checking sys/soundcard.h usability configure:8843: gcc -c -g -O2 conftest.c >&5 configure:8871: sys/soundcard.h: No such file or directory configure:8846: $? = 1 configure: failed program was: #line 8836 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <sys/soundcard.h> configure:8861: result: no configure:8865: checking sys/soundcard.h presence configure:8872: gcc -E conftest.c configure:8868: sys/soundcard.h: No such file or directory configure:8878: $? = 1 configure: failed program was: #line 8867 "configure" #include "confdefs.h" #include <sys/soundcard.h> configure:8896: result: no configure:8914: checking for sys/soundcard.h configure:8921: result: no configure:8834: checking machine/soundcard.h usability configure:8843: gcc -c -g -O2 conftest.c >&5 configure:8871: machine/soundcard.h: No such file or directory configure:8846: $? = 1 configure: failed program was: #line 8836 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <machine/soundcard.h> configure:8861: result: no configure:8865: checking machine/soundcard.h presence configure:8872: gcc -E conftest.c configure:8868: machine/soundcard.h: No such file or directory configure:8878: $? = 1 configure: failed program was: #line 8867 "configure" #include "confdefs.h" #include <machine/soundcard.h> configure:8896: result: no configure:8914: checking for machine/soundcard.h configure:8921: result: no configure:8834: checking soundcard.h usability configure:8843: gcc -c -g -O2 conftest.c >&5 configure:8871: soundcard.h: No such file or directory configure:8846: $? = 1 configure: failed program was: #line 8836 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <soundcard.h> configure:8861: result: no configure:8865: checking soundcard.h presence configure:8872: gcc -E conftest.c configure:8868: soundcard.h: No such file or directory configure:8878: $? = 1 configure: failed program was: #line 8867 "configure" #include "confdefs.h" #include <soundcard.h> configure:8896: result: no configure:8914: checking for soundcard.h configure:8921: result: no configure:8935: checking for Open Sound System configure:8973: gcc -c -g -O2 conftest.c >&5 configure:8963: #error No open sound system configure:8976: $? = 1 configure: failed program was: #line 8940 "configure" #include "confdefs.h" #if defined(HAVE_SYS_SOUNDCARD_H) #include <sys/soundcard.h> #elif defined(HAVE_MACHINE_SOUNDCARD_H) #include <machine/soundcard.h> #elif defined(HAVE_SOUNDCARD_H) #include <soundcard.h> #endif #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* check for one of the Open Sound System specific SNDCTL_ defines */ #if !defined(SNDCTL_DSP_STEREO) #error No open sound system #endif ; return 0; } configure:8992: result: no configure:9004: checking for Open Sound System/MIDI interface configure:9042: gcc -c -g -O2 conftest.c >&5 configure:9032: #error No open sound system MIDI interface configure:9045: $? = 1 configure: failed program was: #line 9009 "configure" #include "confdefs.h" #if defined(HAVE_SYS_SOUNDCARD_H) #include <sys/soundcard.h> #elif defined(HAVE_MACHINE_SOUNDCARD_H) #include <machine/soundcard.h> #elif defined(HAVE_SOUNDCARD_H) #include <soundcard.h> #endif #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* check for one of the Open Sound System specific SNDCTL_SEQ defines */ #if !defined(SNDCTL_SEQ_SYNC) #error No open sound system MIDI interface #endif ; return 0; } configure:9061: result: no configure:9075: checking for artsc-config configure:9108: result: no configure:9112: checking for aRts Sound server configure:9171: result: no configure:9205: checking alsa/asoundlib.h usability configure:9214: gcc -c -g -O2 conftest.c >&5 configure:9242: alsa/asoundlib.h: No such file or directory configure:9217: $? = 1 configure: failed program was: #line 9207 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <alsa/asoundlib.h> configure:9232: result: no configure:9236: checking alsa/asoundlib.h presence configure:9243: gcc -E conftest.c configure:9239: alsa/asoundlib.h: No such file or directory configure:9249: $? = 1 configure: failed program was: #line 9238 "configure" #include "confdefs.h" #include <alsa/asoundlib.h> configure:9267: result: no configure:9285: checking for alsa/asoundlib.h configure:9292: result: no configure:9205: checking sys/asoundlib.h usability configure:9214: gcc -c -g -O2 conftest.c >&5 configure:9242: sys/asoundlib.h: No such file or directory configure:9217: $? = 1 configure: failed program was: #line 9207 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <sys/asoundlib.h> configure:9232: result: no configure:9236: checking sys/asoundlib.h presence configure:9243: gcc -E conftest.c configure:9239: sys/asoundlib.h: No such file or directory configure:9249: $? = 1 configure: failed program was: #line 9238 "configure" #include "confdefs.h" #include <sys/asoundlib.h> configure:9267: result: no configure:9285: checking for sys/asoundlib.h configure:9292: result: no configure:9389: checking audio/audiolib.h usability configure:9398: gcc -c -g -O2 conftest.c >&5 configure:9426: audio/audiolib.h: No such file or directory configure:9401: $? = 1 configure: failed program was: #line 9391 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <audio/audiolib.h> configure:9416: result: no configure:9420: checking audio/audiolib.h presence configure:9427: gcc -E conftest.c configure:9423: audio/audiolib.h: No such file or directory configure:9433: $? = 1 configure: failed program was: #line 9422 "configure" #include "confdefs.h" #include <audio/audiolib.h> configure:9451: result: no configure:9469: checking for audio/audiolib.h configure:9476: result: no configure:9617: checking libaudioio.h usability configure:9626: gcc -c -g -O2 conftest.c >&5 configure:9654: libaudioio.h: No such file or directory configure:9629: $? = 1 configure: failed program was: #line 9619 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <libaudioio.h> configure:9644: result: no configure:9648: checking libaudioio.h presence configure:9655: gcc -E conftest.c configure:9651: libaudioio.h: No such file or directory configure:9661: $? = 1 configure: failed program was: #line 9650 "configure" #include "confdefs.h" #include <libaudioio.h> configure:9679: result: no configure:9697: checking for libaudioio.h configure:9704: result: no configure:9782: checking whether mmap64 works defined as mmap configure:9822: gcc -o conftest -g -O2 conftest.c -lm >&5 configure: In function `main': configure:9807: warning: comparison between pointer and integer configure:9825: $? = 0 configure:9827: ./conftest success! configure:9830: $? = 0 configure:9843: result: yes configure:9859: checking for gcc strength-reduce bug configure:9884: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure: In function `main': configure:9874: warning: comparison between signed and unsigned configure:9887: $? = 0 configure:9889: ./conftest configure:9892: $? = 0 configure:9905: result: no configure:9912: checking for gcc -mpreferred-stack-boundary=2 support configure:9938: gcc -o conftest -g -O2 -Wall -mpreferred-stack-boundary=2 conftest.c -lm >&5 cc1: Invalid option `preferred-stack-boundary=2' configure:9941: $? = 1 configure: failed program was: #line 9919 "configure" #include "confdefs.h" #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ; return 0; } configure:9958: result: no configure:9967: checking how to define a function in assembly code configure:9992: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure:9995: $? = 0 configure:9998: test -s conftest configure:10001: $? = 0 configure:10085: result: .def configure:10114: checking whether external symbols need an underscore prefix configure:10139: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure:10142: $? = 0 configure:10145: test -s conftest configure:10148: $? = 0 configure:10158: result: yes configure:10177: checking whether stdcall symbols need to be decorated configure:10202: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure:10205: $? = 0 configure:10208: test -s conftest configure:10211: $? = 0 configure:10221: result: yes configure:10233: checking whether assembler accepts .string configure:10258: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure: In function `ac_asm': configure:10239: syntax error before `test' configure:10261: $? = 1 configure: failed program was: #line 10238 "configure" #include "confdefs.h" void ac_asm(void) { asm(".data\n\t.string "test"\n\t.text"); } #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ; return 0; } configure:10277: result: no configure:10343: checking for dllwrap configure:10370: result: false configure:10853: error: could not find a way to build shared libraries. It is currently not possible to build Wine without shared library (.so) support to allow transparent switch between .so and .dll files. If you are using Linux, you will need a newer binutils. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_asm_func_def=.def ac_cv_build=i386-pc-interix3 ac_cv_build_alias=i386-pc-interix3 ac_cv_c___va_copy=yes ac_cv_c_artsserver=no ac_cv_c_asm_string=no ac_cv_c_compiler_gnu=yes ac_cv_c_extern_prefix=yes ac_cv_c_gcc_stack_boundary=no ac_cv_c_gcc_strength_bug=no ac_cv_c_ipx_gnu=no ac_cv_c_ipx_linux=no ac_cv_c_opensoundsystem=no ac_cv_c_opensoundsystem_midi=no ac_cv_c_ppdev=no ac_cv_c_stdcall_decoration=yes ac_cv_c_va_copy=no ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_exeext= ac_cv_func_connect=yes ac_cv_func_getbkgd=no ac_cv_func_gethostbyname=yes ac_cv_func_inet_aton=yes ac_cv_func_iswalnum=no ac_cv_func_remove=yes ac_cv_func_resizeterm=no ac_cv_func_shmat=yes ac_cv_have_x='have_x=yes ac_x_includes=/usr/X11R5/include ac_x_libraries=/usr/X11R5/lib' ac_cv_header_GL_gl_h=no ac_cv_header_GL_glx_h=no ac_cv_header_X11_XKBlib_h=no ac_cv_header_X11_Xlib_h=yes ac_cv_header_X11_Xutil_h=yes ac_cv_header_X11_extensions_XShm_h=yes ac_cv_header_X11_extensions_Xrender_h=no ac_cv_header_X11_extensions_Xvlib_h=no ac_cv_header_X11_extensions_shape_h=yes ac_cv_header_X11_extensions_xf86dga_h=no ac_cv_header_X11_extensions_xf86vmode_h=no ac_cv_header_alsa_asoundlib_h=no ac_cv_header_audio_audiolib_h=no ac_cv_header_inttypes_h=no ac_cv_header_jpeglib_h=no ac_cv_header_libaudioio_h=no ac_cv_header_machine_soundcard_h=no ac_cv_header_memory_h=yes ac_cv_header_ncurses_h=no ac_cv_header_soundcard_h=no ac_cv_header_stdc=yes ac_cv_header_stdint_h=no ac_cv_header_stdlib_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_asoundlib_h=no ac_cv_header_sys_soundcard_h=no ac_cv_header_sys_stat_h=yes ac_cv_header_sys_types_h=yes ac_cv_header_unistd_h=yes ac_cv_host=i386-pc-interix3 ac_cv_host_alias=i386-pc-interix3 ac_cv_lib_ICE_IceConnectionNumber=no ac_cv_lib_Xext_XShapeQueryExtension=yes ac_cv_lib_Xext_XShmQueryExtension=no ac_cv_lib_cups_cupsGetPPD=no ac_cv_lib_fl_yywrap=no ac_cv_lib_freetype_FT_Init_FreeType=no ac_cv_lib_i386_i386_set_ldt=no ac_cv_lib_l_yywrap=yes ac_cv_lib_m_sqrt=yes ac_cv_lib_mmap_mmap=no ac_cv_lib_ossaudio__oss_ioctl=no ac_cv_lib_w_iswalnum=no ac_cv_lib_xpg4__xpg4_setrunelocale=no ac_cv_mmap64_works=yes ac_cv_objext=o ac_cv_path_LDCONFIG=true ac_cv_path_install='/bin/install -c' ac_cv_prog_C2MAN='$(TOPSRCDIR)/tools/c2man.pl' ac_cv_prog_CPP='gcc -E' ac_cv_prog_LEX=lex ac_cv_prog_XLEX=lex ac_cv_prog_XYACC=yacc ac_cv_prog_ac_ct_AR=ar ac_cv_prog_ac_ct_CC=gcc ac_cv_prog_ac_ct_DLLWRAP=false ac_cv_prog_ac_ct_LD=ld ac_cv_prog_ac_ct_RANLIB=ranlib ac_cv_prog_ac_ct_STRIP=strip ac_cv_prog_ac_ct_WINDRES=false ac_cv_prog_cc_g=yes ac_cv_prog_lex_root=lex.yy ac_cv_prog_lex_yytext_pointer=yes ac_cv_prog_make_make_set=yes ac_cv_prog_sane_devel=no wine_cv_msg_freetype=no wine_cv_toolsdir='$(TOPOBJDIR)' wine_cv_warn_cups_h=no ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "Wine" #define PACKAGE_TARNAME "wine" #define PACKAGE_VERSION "20020904" #define PACKAGE_STRING "Wine 20020904" #define PACKAGE_BUGREPORT "" #define YYTEXT_POINTER 1 #define HAVE_LIBM 1 #define HAVE_GETHOSTBYNAME 1 #define HAVE_CONNECT 1 #define HAVE_INET_ATON 1 #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_UNISTD_H 1 #define HAVE_X11_XLIB_H 1 #define HAVE_X11_EXTENSIONS_XSHM_H 1 #define HAVE_X11_XUTIL_H 1 #define HAVE_X11_EXTENSIONS_SHAPE_H 1 #define HAVE_LIBXSHAPE 1 #define HAVE___VA_COPY 1 #define _FILE_OFFSET_BITS 64 #define __ASM_FUNC(name) ".def " __ASM_NAME(name) "; .scl 2; .type 32; .endef" #define __ASM_NAME(name) "_" name #define NEED_STDCALL_DECORATION 1 configure: exit 1

1 0

Re: Fixed selecting multiple files in common file dialog 95-style
by Duane Clark 15 Sep '02

15 Sep '02

Josef Meixner wrote: > Problem: > Selecting multiple files in an OpenDialog resulted in a crash, tested with > PVAstrumento. > > Changelog: > dlls/commdlg/filedlg95.c: > - Initializing the return-string shouldn't change the pointer. > - Added "FIXME" for case not handled. > - Directory and the filenames have to be separated by "\0". > - Added check to handle possible signed/unsigned overflow. > > Index: dlls/commdlg/filedlg95.c > =================================================================== > RCS file: /home/wine/wine/dlls/commdlg/filedlg95.c,v > retrieving revision 1.80 > diff -r1.80 filedlg95.c > 1405c1405 > < ofn->lpstrFile = '\0'; > --- Hi Josef, and Juraj too, if you are reading this. Please create a file ~/.cvsrc and add the entry "diff -u", so that patches will be in unified diff format. Thanks.

1 0

Re: Fixed typo error in wingdi.h, added structure tags in winbase.h
by Francois Gouget 15 Sep '02

15 Sep '02

On Sun, 15 Sep 2002, Juraj Hercek wrote: > Hi everybody, > I was permanently fixing COLORREF in wingdi.h after every update of > wine snapshot. I hope, I'll never have to do it again :o). I needed also > some tags to be defined in structures in winbase.h file. Hmm, apparently the patch is missing so I'm afraid you will have to keep patching things ;-) Unless you resubmit with the patch of course. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

1 0

Re: Shell execute with URLs
by Eric Pouech 15 Sep '02

15 Sep '02

Duane Clark a écrit : > > I finally managed to test the shell execute functions with URLs. why do you call WaitForInputIdle through a pointer ? loader needs to do it because of DLL separation (loader belongs to kernel32, and thus cannot call user32) your code lives in shell32, which already loads user32, so direct call would do A+

2 1

Problem with the TEB parser
by Sylvain Petreolle 15 Sep '02

15 Sep '02

Hi list, I encounter problem with the TEB parser. Enabling the builtin olepro32 and run winedbg on a program that needs it stops with following errors hen halting on a read access to 0x0. what could I do to debug this ? First chance exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:04c7 EIP:00000000 ESP:405c25f0 EBP:4000b6c9 EFLAGS:00010206( R- 00 I - -P1 ) EAX:400136bc EBX:400134c0 ECX:4000bd00 EDX:400136bc ESI:00000000 EDI:00000000 Stack dump: 0x405c25f0 (NTDLL.DLL.sqrt+0x396ccc): *** Invalid address 0x405c25f0 (NTDLL.DLL.sqrt+0x396ccc) 0011: sel=008f base=4013e0c0 limit=00000fff 32-bit rw- Backtrace: =>0 0x00000000 (ebp=4000b6c9) Can't read TEB:cur_stack 0x00000000: *** Invalid address 0x00000000 -- no code -- ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

UML Merged Into 2.5.34 , VxD's
by Thomas Wickline 14 Sep '02

14 Sep '02

I see UML made it into the 2.5.34 kernel http://user-mode-linux.sourceforge.net/ From what I get VxD drivers try to get hold of your pci bus and a ton of other stuff . Could this be the start to a fix down the road when it comes to .vxd support ? Will this help when it comes to a Wine Kernel Module ? cut from there site --- User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software. ----- Tom

6 6

Regitry Load*RegistryFiles options oboleted?
by Raul Dias 14 Sep '02

14 Sep '02

Hi, Did the regsitry section options: LoadGlobalRegistryFiles and LoadHomeRegistryFiles got obsoleted? It is not in misc/registry.c or anywhere else in the source other than in documentation dir. When was it obsoleted? why? Regards, Raul Dias

1 1

Re: recognize Unix-style hidden files
by Alexandre Julliard 14 Sep '02

14 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > The semantics associated in Unix with files starting with > a . is that they are hidden, *exactly* like the hidden DOS > files. We should mark them as such. > > We're lucky in that the DOS world does not use files that > only have extension, so we have no semantical conflict. I don't think I agree with that. Maybe in the days of 8.3 files yes, but nowadays Windows apps can create files starting with a dot, and they don't expect these files to be hidden. Also hidden files are much harder to access under Windows than dot files under Unix, so I'm not sure it would really be better for the user. -- Alexandre Julliard julliard(a)winehq.com

5 12

Press: LinuxPlanet makes a great case for Wine
by Francois Gouget 14 Sep '02

14 Sep '02

(and reviews CrossOver Office 1.2 too :-) * August 29, 2002 - LinuxPlanet CrossOver Office: Cutting to the Quicken http://www.linuxplanet.com/linuxplanet/reviews/4405/1/ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

1 0

Re: wine/ dlls/ntdll/Makefile.in win32/device.c me ...
by Dimitrie O. Paun 13 Sep '02

13 Sep '02

On September 13, 2002 02:52 pm, Alexandre Julliard wrote: > Log message: > Copied the registry functions needed by VMM into device.c and got rid > of memory/registry.c. Hmm, this is painful. Why and how long do we have to support Win95 advapi32? -- Dimi.

2 2

Re: Re:can windows be reparented?
by Dmitry Timoshkov 13 Sep '02

13 Sep '02

<us(a)the-edmeades.demon.co.uk> wrote: > To be honest I never investigated further once I commented out the SetParent call, > as I was continuing to fix oleaut32 and left the gui side to someone else! > > I know it was being called in the failing case, and removing it allowed the > windows to pop up, BUT they were still wrong as you could access the 'parent' > whereas you should not be able to Could you please test patch posted by Bill Medland to wine-patches today? It's not entirely correct though. My tests show that SetWindowLong(GWL_HWNDPARENT) call changes simultaneously both parent and owner for top level windows and returns old value (not sure old owner or parent it is). But top level windows created by Visual Vasic are special: they have no parent, but only owner according to Spy++. In my tests I can't reproduce it yet. A bit of investigation of Wine source revealed that some places use GetAncestor(hwnd, GA_PARENT), while others use GetParent(hwnd). Since their behaviour is different in respect of top level and child windows, some major clean up in that area in Wine is needed. -- Dmitry.

4 5

Winemaker broken?
by steve.lustbader＠philips.com 13 Sep '02

13 Sep '02

Winemaker doesn't work in the latest CVS. When I run it, it tells me: Global symbol "$app_name" requires explicit package name at /usr/local/bin/winemaker line 1674. Execution of /usr/local/bin/winemaker aborted due to compilation errors. It worked as of Sept 10. -Steve

2 2

configure and then make distclean
by Shachar Shemesh 13 Sep '02

13 Sep '02

Hi, For some strange reason (well, maybe not strange), I cannot run "make distclean" unless the make files are up to date. Is there a reason for this, or is this just a result of a check at the very begining of the makefile? It seems rather strange to me to do "./configure && make distclean; ./configure && make depend && make". Shachar P.S. No, I am not doing this every single time.

2 1

Re: Winemaker: improved MSVCRT support
by Francois Gouget 13 Sep '02

13 Sep '02

On 13 Sep 2002, Martin Wilck wrote: [...] > + if ($dllname =~ /^msvcrt\.dll$/) { You can also say 'if ($dllname eq "msvcrt.dll")'. Great work on winemaker :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

1 0

Re: Improved MoveFileEx() Patch
by Huw Davies 13 Sep '02

13 Sep '02

On Fri, Sep 13, 2002 at 04:50:47PM +0200, Martin Wilck wrote: > Index: files/file.c > =================================================================== > RCS file: /home/wine/wine/files/file.c,v > retrieving revision 1.160 > diff -u -r1.160 file.c > --- files/file.c 12 Sep 2002 22:28:01 -0000 1.160 > +++ files/file.c 13 Sep 2002 14:26:47 -0000 > @@ -2579,6 +2579,7 @@ > { > DOS_FULL_NAME full_name1, full_name2; > HANDLE hFile; > + DWORD attr = INVALID_FILE_ATTRIBUTES; > > TRACE("(%s,%s,%04lx)\n", debugstr_w(fn1), debugstr_w(fn2), flag); > > @@ -2619,8 +2620,7 @@ > /* target exists, check if we may overwrite */ > if (!(flag & MOVEFILE_REPLACE_EXISTING)) > { > - /* FIXME: Use right error code */ > - SetLastError( ERROR_ACCESS_DENIED ); > + SetLastError( ERROR_FILE_EXISTS ); > return FALSE; > } > } > @@ -2647,17 +2647,17 @@ > return FILE_AddBootRenameEntry( fn1, fn2, flag ); > } > > + attr = GetFileAttributesA( full_name1.long_name ); Any reason why you don't use: attr = GetFileAttributesW( fn1 ); here? I've seen cases that I've not had time to investigate where the former version fails. Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Shell icons - legal
by Jacek Bator 13 Sep '02

13 Sep '02

Hello! I realy don't like icons which are currently in shell32.dll. I've created few replacement icons from there. They are much more simillar to win95,98 icons ... but not exactly the same. I want to confirm that my work will not be wasted. ---- Original icons from Windows shell32.dll can't be inserted in wine dll because of legal issues (design or something). ----- If I'm wrong let me know. Jacek Bator jbator(a)ecommercelogic.com

1 0

WM_PAINT disappeared
by Fabian Cenedese 13 Sep '02

13 Sep '02

Hi all I have a problem with my MFC-MDI-app. There are some other windows docked in the main window. The problem now is that they don't get painted. I end up with an app-window with some areas that never get updated. I first tried with tracing but I never saw anything wrong. Now I logged in my child window (CIXDockWnd) all messages it gets. This is what happens at creation in Windows: CMainFrame::OnCreate CIXDockWnd: -WM_NCCREATE -WM_NCCALCSIZE -WM_CREATE -WM_SIZE -WM_MOVE .. (some other stuff) -WM_WINDOWPOSCHANGING -WM_NCCALCSIZE -WM_WINDOWPOSCHANGED -WM_SIZE -WM_SHOWWINDOW CImdApp::InitInstance: Call ShowWindow CImdApp::InitInstance: Call UpdateWindow CIXDockWnd: -WM_PAINT (*) -WM_NCPAINT (*) CImdApp::InitInstance: Call SetFocus CIXAppFrame::OnWindowPosChanged CIXDockWnd: -WM_PAINT (*) -WM_NCPAINT (*) -WM_ERASEBKGND (*) IDLE_UPDATE Here the window is finished and visible, waiting for actions. In Wine though the paint messages of the child window (*) never show up, it stays clear. I don't know now if this is a problem in message routing (I don't think so as all other messages come through) or if these messages aren't sent at all. To investigate this can somebody point me to directions where these messages should be generated? Thanks bye Fabi

1 0

Tagging releases
by Shachar Shemesh 13 Sep '02

13 Sep '02

Hi, Would it be possible to tag each "release" announced to wine-announce in the CVS, so cvs co -r WINE_20020702 wine will actually get the wine version that corresponds to that release? I know I can do "cvs co -D 2002-jul-02 wine" for similar effect, but I don't like that solution. It has not worked well for me, and it leaves some inclarities regarding files that had several commits on the same day (not to mention time zones etc.) Shachar

2 1

Re: Fix lossage due to pathname truncation in calls to MODULE_LoadLibraryExA
by Andreas Mohr 13 Sep '02

13 Sep '02

On Thu, Sep 12, 2002 at 08:38:09PM +1000, Michael Beach wrote: > Recently I've been using WINE to run a Win32 exe which needs to load certain > DLLs which are located in the same directory as the exe. I was most perplexed > when I found that this worked initially, but when I moved the exe and DLLs to > a different directory it stopped working ie WINE would refuse to start the > exe, claiming that it was unable to load the required DLLs. > > After some debugging, I discovered that the critical factor was the length of > the pathname to the exe, when it passed a certain length it stopped working. > However this length was way short of the MAX_PATH value of 260. Ah, cool finding ! > static BOOL DIR_TryModulePath( LPCWSTR name, DOS_FULL_NAME *full_name, BOOL win32 ) > { > - /* FIXME: for now, GetModuleFileNameW can't return more */ > - /* than OFS_MAXPATHNAME. This may change with Win32. */ > - WCHAR bufferW[OFS_MAXPATHNAME]; > + WCHAR bufferW[MAX_PATH]; > LPWSTR p; > > if (!win32) > @@ -727,13 +725,13 @@ > if (!GetCurrentTask()) return FALSE; > if (!GetModuleFileName16( GetCurrentTask(), buffer, sizeof(buffer) )) > return FALSE; > - MultiByteToWideChar(CP_ACP, 0, buffer, -1, bufferW, OFS_MAXPATHNAME); > + MultiByteToWideChar(CP_ACP, 0, buffer, -1, bufferW, MAX_PATH); > } else { > - if (!GetModuleFileNameW( 0, bufferW, OFS_MAXPATHNAME ) ) > + if (!GetModuleFileNameW( 0, bufferW, MAX_PATH ) ) > return FALSE; > } > if (!(p = strrchrW( bufferW, '\\' ))) return FALSE; > - if (OFS_MAXPATHNAME - (++p - bufferW) <= strlenW(name)) return FALSE; > + if (MAX_PATH - (++p - bufferW) <= strlenW(name)) return FALSE; > strcpyW( p, name ); > return DOSFS_GetFullName( bufferW, TRUE, full_name ); Argl, why does this code use the buffer size contants instead of sizeof(variable) !? I suggest we always specify buffer length constants only *once*, namely at creation of the buffer. Not doing so can be potentially very harmful if we decide to change the buffer length and then manage to forget one or more length constants... Maybe you could even also fix that "weirdness" in our code ? Thanks ! :) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

4 8

Re: WineLib and DLLs
by steve.lustbader＠philips.com 13 Sep '02

13 Sep '02

If possible, I don't want to insert it into the wine tree, I want to leave it in the source tree of my program. Is including it in the wine tree the only way to link with it? -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

re: shlwapi failes to build on windows
by Jon Griffiths 12 Sep '02

12 Sep '02

Hi, >shlwapi.exp(.edata+0x34):fake: undefined reference to >`AssocCreate@12' >C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 >make: *** [shlwapi.dll] Error 1 >The def should contain AssocCreate@24 I do not know what is needed >in the *.spec though This is due to the spec entry possibly being incorrect. AssocCreate takes a CLSID as its first parameter (rather than a ptr to one as any sane coder would have expected). I have no idea how to tell the spec file that the first parameter is a structure, however this obviously means that the size of the parameters listed after the '@' is wrong. I'm not sure how to fix this, since passing structs is a rare case, I've never looked into how to specify them in the spec. Maybe we need a "struct(n)" spec type for by value structures? Another note: if you're planning to try to test SHLWAPI under Windows you should be running NT 4 or later, as there are some changes needed w.r.t unicode to get earlier O/Ss working OK. 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 2

Fwd: Message Undeliverable
by Dimitrie O. Paun 12 Sep '02

12 Sep '02

This is the second (and I have a third now) message of this type that I receive, even though it seems that my messages to reach the list. What's up? ---------- Forwarded Message ---------- Subject: Message Undeliverable Date: Thu, 12 Sep 2002 15:40:19 -0600 From: postmaster(a)www.praize.com To: dpaun(a)rogers.com User does not exist Message Headers: Return-Path: <wine-patches-admin(a)winehq.com> Received: from admin.praize.com (root@localhost) by praize.com (8.11.6/8.11.6) with ESMTP id g8CLcxP18778 for <gboutwel(a)praize.com>; Thu, 12 Sep 2002 15:38:59 -0600 X-ClientAddr: 198.144.4.3 Received: from wine.codeweavers.com (wine.codeweavers.com [198.144.4.3]) by admin.praize.com (8.11.6/8.11.6) with ESMTP id g8CLcwD18774 for <gboutwel(a)praize.com>; Thu, 12 Sep 2002 15:38:58 -0600 Received: from localhost.localdomain (wine [127.0.0.1]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id g8CLb6F27723; Thu, 12 Sep 2002 16:37:06 -0500 Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id g8CLaeF27686 for <wine-patches(a)winehq.com>; Thu, 12 Sep 2002 16:36:41 -0500 Received: from dimi.dssd.ca ([24.103.156.204]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20020912213628.FCWQ389684.fep04-mail.bloor.is.net.cable.rogers.com(a)dimi.dss d.ca> for <wine-patches(a)winehq.com>; Thu, 12 Sep 2002 17:36:28 -0400 Content-Type: text/plain; charset="us-ascii" From: "Dimitrie O. Paun" <dpaun(a)rogers.com> Organization: DSSD Software Inc. To: Wine Patches <wine-patches(a)winehq.com> Subject: Trackbar updates User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209121734.32094.dpaun(a)rogers.com> X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.103.156.204] using ID <dpaun(a)rogers.com> at Thu, 12 Sep 2002 17:36:27 -0400 Sender: wine-patches-admin(a)winehq.com Errors-To: wine-patches-admin(a)winehq.com X-BeenThere: wine-patches(a)winehq.com X-Mailman-Version: 2.0 Precedence: bulk Reply-To: wine-devel(a)winehq.com X-Reply-To: dpaun(a)rogers.com List-Help: <mailto:wine-patches-request@winehq.com?subject=help> List-Post: <mailto:wine-patches@winehq.com> List-Subscribe: <http://www.winehq.com/mailman/listinfo/wine-patches>, <mailto:wine-patches-request@winehq.com?subject=subscribe> List-Id: Wine Patch Submissions <wine-patches.winehq.com> List-Unsubscribe: <http://www.winehq.com/mailman/listinfo/wine-patches>, <mailto:wine-patches-request@winehq.com?subject=unsubscribe> List-Archive: <http://www.winehq.com/hypermail/wine-patches/> Date: Thu, 12 Sep 2002 17:34:31 -0400 Status: ------------------------------------------------------- -- Dimi.

2 1

Re: WineLib and DLLs
by Jon Griffiths 12 Sep '02

12 Sep '02

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

1 0

Re: SHLWAPI merging #4
by Alexandre Julliard 12 Sep '02

12 Sep '02

Jon <jon_p_griffiths(a)yahoo.com> writes: > Does anyone object to my moving SHLWAPI_1 & 2 into url.c and moving out the > definitions from ordinal.h in there as well? > > I want to tidy this up because at some point in the not too distant future the > ordinal code will get a lot bigger. So it makes sense to me to implement > ordinals that are related in the same files (like the MIME ord. functions in > url.c), and to split out other ord. groups (gdi/windows/com/ie/perfmon etc) > into their own files as well. OK? Actually there's no reason at all to group ordinal functions together, the fact that they are exported by ordinal is just a detail that doesn't matter for understanding what's going on. It's much better to group ordinal string functions with other string functions, ordinal URL functions with other URL stuff etc. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: WineLib and DLLs
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

I also have the .lib and .pdb files for the DLLs, if that helps. 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? There are instructions in the WineLib docs about binary DLLs, but they seem to be talking about pretending a Linux library is a DLL, which is not what I want to do. -Steve

1 0

WineLib and DLLs
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

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? There are instructions in the WineLib docs about binary DLLs, but they seem to be talking about pretending a Linux library is a DLL, which is not what I want to do. -Steve

1 0

Re: Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

Thanks, that worked! Do you think you could update the Unicode section in the WineLib user's guide (section 2.2)? It doesn't even mention WINE_UNICODE_NATIVE (not like the rest of the guide is that current, but every little bit helps for new developers). -Steve On Thu, 12 Sep 2002 steve.lustbader(a)philips.com wrote: > I think there is issue with _T(x). I have this line in my Windows app > that I'm compiling with WineLib (I'm using -fshort-wchar): > > const TCHAR *Name() const { return _T("my_name"); }; > > The compiler gives me an error of: > > cannot convert `const __wchar_t *' to `const > TCHAR *' in return If you are using --fshort-wchar you should also use WINE_UNICODE_NATIVE so that WCHAR gets defined to wchar_t. From winnt.h: #ifdef WINE_UNICODE_NATIVE typedef wchar_t WCHAR, *PWCHAR; #else typedef unsigned short WCHAR, *PWCHAR; #endif and further down: /* Define WINE_UNICODE_NATIVE if: * - your compiler provides a 16bit wchar_t type, e.g. gcc >= 2.96 with * -fshort-wchar option * - or if you decide to use the native 32bit Unix wchar_t type. Be aware * though that the Wine APIs only support 16bit WCHAR characters for * binary compatibility reasons. * - or define nothing at all if you don't use Unicode, and blissfully * ignore the issue :-) */ Does that help? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels

1 0

shlwapi failes to build on windows
by Steven Edwards 12 Sep '02

12 Sep '02

shlwapi.exp(.edata+0x34):fake: undefined reference to `AssocCreate@12' C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [shlwapi.dll] Error 1 The def should contain AssocCreate@24 I do not know what is needed in the *.spec though Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

Re: Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

I think there is issue with _T(x). I have this line in my Windows app that I'm compiling with WineLib (I'm using -fshort-wchar): const TCHAR *Name() const { return _T("my_name"); }; The compiler gives me an error of: cannot convert `const __wchar_t *' to `const TCHAR *' in return It similarly complains about converting _T("foo") to a const WCHAR *. Both of these things work under Windows. Changing the definition of _T(x) from L##x to (TCHAR *) L##x avoids these problems, but then something like _T("foo") _T("bar") doesn't concatenate those strings like it does in Windows. -Steve --- steve.lustbader(a)philips.com wrote: > Are _tprintf and it's related functions (_ftprintf, > _stprintf) implemented? I found a tchar.h in the > source tree that defines these functions, but it > wasn't in my /usr/local/include/wine directory. I'm fixing the build process to install the header. For now you can copy it manually to the /usr/local/include/wine directory. Actually _ftprintf and _stprintf are not functions, but macros which are mapped in tchar.h to corresponding ASCII or Unicode function. The underlying functions should be implemented. > These functions aren't important for wine, since > they're simply defined as the ASCII or Unicode > version, but they are important for WineLib. > > What is the overall status of using Unicode with > WineLib? What needs to be defined and what headers > need to be included to get the functionality from > Windows' tchar.h (_T(), TCHAR, the above functions, > etc)? Unicode is supported relatively well in Wine. Please report if you have any issues with it. Andriy __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

3 2

RE: wstr vs ptr in spec files
by Patrik Stridvall 12 Sep '02

12 Sep '02

> When should I use wstr and when ptr for wide strings > in the spec files functions specification? > > Looking at existing files I see that LPCWSTR type is > usually mapped to wstr, It should almost always map to wstr. > but LPWSTR is sometimes mapped > to ptr, sometimes to wstr. As the general rule it depends on whether the parameter is IN, OUT or IN/OUT. IN: wstr OUT: ptr IN/OUT: wstr PS. It is for debug messages. If the parameter is OUT it might not be initialized as thus it should not be printed as a string (in this case a wide string).

1 0

Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

Are _tprintf and it's related functions (_ftprintf, _stprintf) implemented? I found a tchar.h in the source tree that defines these functions, but it wasn't in my /usr/local/include/wine directory. These functions aren't important for wine, since they're simply defined as the ASCII or Unicode version, but they are important for WineLib. What is the overall status of using Unicode with WineLib? What needs to be defined and what headers need to be included to get the functionality from Windows' tchar.h (_T(), TCHAR, the above functions, etc)? -Steve

3 2

wstr vs ptr in spec files
by Andriy Palamarchuk 12 Sep '02

12 Sep '02

When should I use wstr and when ptr for wide strings in the spec files functions specification? Looking at existing files I see that LPCWSTR type is usually mapped to wstr, but LPWSTR is sometimes mapped to ptr, sometimes to wstr. Andriy Boston, MA, USA As an employee of an oil company, let me assure you that nothing, and I mean NOTHING scares a big company more than a noisy, smelly, obnoxious, disaffected pressure group. Now go away and chain yourself to someone important's front door. TheRegister. Unknown __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

RE: Patch - Fix typo
by Patrik Stridvall 12 Sep '02

12 Sep '02

> On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > > I noticed this when adapting WINE code for ReactOS > [...] > > > > - * DialogBoxIndirectParam (USER.240) > > > - * DialogBoxIndirectParam16 (USER32.@) > > > + * DialogBoxIndirectParam16 (USER.240) > > > + * DialogBoxIndirectParam (USER32.@) > > > */ > > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > > HANDLE16 dlgTemplate, > > > HWND16 owner16, > > > DLGPROC16 dlgProc, > > > > No this is correct. > > > > The 16 bit function's external name is DialogBoxIndirectParam > > The 32 bit function's external name is DialogBoxIndirectParam16 > Then maybe add a comment instead: > "(yep, 16/32 naming is correct)" Well, it quite common in the core DLLs that the naming is done that way so it would be quite a lot of IMHO unnessary comments. PS. winapi_check automatically finds functions that are wrong so the Wine sourc eis currrently 100% correct (save bugs in winapi_check of course) as far as the issue above in documentation header is concerned.

1 0

Re: Patch - Fix typo
by Andreas Mohr 12 Sep '02

12 Sep '02

On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > I noticed this when adapting WINE code for ReactOS [...] > > - * DialogBoxIndirectParam (USER.240) > > - * DialogBoxIndirectParam16 (USER32.@) > > + * DialogBoxIndirectParam16 (USER.240) > > + * DialogBoxIndirectParam (USER32.@) > > */ > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > HANDLE16 dlgTemplate, > > HWND16 owner16, > > DLGPROC16 dlgProc, > > No this is correct. > > The 16 bit function's external name is DialogBoxIndirectParam > The 32 bit function's external name is DialogBoxIndirectParam16 Then maybe add a comment instead: "(yep, 16/32 naming is correct)" -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

1 0

Re: Duplicate: Listview update - LVM_GETITEMRECT
by Dimitrie O. Paun 12 Sep '02

12 Sep '02

On September 10, 2002 10:26 pm, Guy L. Albertelli wrote: > Alexandre: Is this format any better. I am worried about line end > characters and line wrapping. I like this format a lot better! But I'm no Alexandre... :) > This is built on top of CVS of yesterday (9/9/02) but will probably > conflict with Dimi's latest patch. Can you please rediff against the current tree? TIA, Dimi.

3 5

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 12 Sep '02

12 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > The orginal reason for winapi_cleanup was to convert the \r\n > > that I got while editing in Micrsoft Developer studio > > to \n. > > > > But I can modify it the so it only does that. > > > > It should probably remove trailing whitespace at lines > > ending in \ though since some compilers choke on that. > > Sure, the idea of a cleanup tool is a good thing, it just should only > do the cleanups that we all agree on. Myself I'm especially interested > in an automatic cleanup of C++ comments... Already on my TODO list. BTW. How do you want multiliners like // XXX // YYY // ZZZ to look like? Like this /* XXX * YYY * ZZZ */ or like this /* * XXX * YYY * ZZZ */ or perhaps in some other way? One liners like // XXX should simply look like /* XXX */ Or would you prefer it some other way?

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > > Of course having an imperfect parser also means we cannot > use it for > > > the export info, because unlike relay debugging it needs > to be 100% > > > correct. So we either need compiler declspec support, > > > > That will leave us dependent on compilers that support it. > > Well, the idea would be not to depend on compiler support for the > __declspec keyword itself, but more to have some clever macro > replacements that output stuff in a special ELF section or something > like that. This could then hopefully be made to work on most > compilers. But I'm not sure if there's a good way to do that at all. It might work, but then it might not. > > This isn't happend soon either. It might not be THAT difficult, > > however the code need not just work it needs be well structured > > and organized as well if any reasonable guarantees of correctness > > can be made. > > I think most of all it needs to be simple. My idea is to run through > the preprocessor, This will be VERY slow. > find the __declspec, and locate the corresponding > function name, or die if there's anything it cannot parse. This should > be reasonably foolproof. A naive idea would be search for __declspec while keeping track of the nesting level (that is how many (, [, { that have not been closed). If the nesting level goes from 1 to 0 before finding the __declspec set a mark. When __declspec is found search backward to mark until you find ; at nesting level 0 or the mark then skip forward any white space. This is extremely likely to be the beginning of a function. Then search forward until { or ; is found when nesting level is 0. Then skip any whitespace backwards. You now know where a __declspec function begins and ends. This reduces the problem to the parsing of a function declaration. The rest is left as an exersize to the reader. :-) The problem is that this might work or it might not. You have no real guarante that it will. > And IMO it shouldn't be in Perl, it should be > part of winebuild. That will not make things easier.

3 2

Strange CVS problem (help!!!)
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

Folks, Up until a few days ago, I was able to do this: # vim some/wine/file.c # cvs diff some/wine/file.c > file.diff # mail wine-patches(a)winehq.com < file.diff # sleep <until Alexandre commited the patch> # cvs up At this point, CVS would figure out that the changes in file.c in my tree are the same as the ones on the server, will give a message to that effect, and update the file. As of lately, this no longer happens: I get a big fat conflic for all the changes I submit! This is *very* annoying. Anyone knows how to fix this behaviour? Alexandre, are you doing anything different? -- Dimi.

7 20

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > I (personally) like to keep it the way it is. > > If the submitter is worried about the spaces he can > > run the whitespaces cleaning tool himself before > > submitting the patch (hint, hint ;-) > > Well, no, if not everybody does it you can't do it either, otherwise > it will create huge differences. I don't want to receive a patch that > is 10% code and 90% whitespace changes just because the guy who edited > the file before you didn't cleanup the spaces. Well, either you remove trailing whitespaces from patches or you don't. If you do than "the guy who edited the file before you didn't cleanup the spaces" case can't happend, can it?

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> > You have the case: > > void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) > > __attribute__((noreturn)) { } > > > > Sure you can have an exception if the name seems to be > __attribute__ but > > then where might be other exceptions. > > Yes, but a few preprocessor defines can get rid of that. Well. You want to read the __attribute__ to know if the function should be stdcall or cdecl don't you? The there might be cases I haven't though of. > > > The only problem is if you want to find > > > the number of args for stdcall decoration, but we should > be able to do > > > without it. > > > > That is not a problem. If you find the opening ( before the > function name, > > it would be the number of , at nesting level 1 plus one > with the special > > case of void between the parantesis which means 0. > > Except for 64-bit data types... And data structures. Forgot about that. > > Perhaps. You will easily reach 99% correctness. However > beyond that it > > is hard without a real C parser. > > Well it's clear you can't get 100%, the thing is to make sure it fails > in a reasonable way, not just silently breaks. Agreed. > I think it is feasible; Maybe. > whether it is worth the effort is an entirely different question... It is MANY hours of work. Work I'm not going to be able to motivate myself to do especially not if you want it in C. The last time years ago I did parsing and string handling in C was a horrible experience one I'm not eager to experience again, especially since other tools (read: Perl) exists. PS. I do agree it should be done in C though.

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > This will be VERY slow. > > I don't think it will be really different than duplicating all the > work the preprocessor is doing inside the parser itself. Of course you > want to use the Wine preprocessor, not fork+exec gcc for each file. OK. I was mainly refering to fork+exec gcc. > But yes parsing all the files is of course slower than having all the > info in the .spec, there's no way around that. Of course. > > You now know where a __declspec function begins and ends. > > This reduces the problem to the parsing of a function declaration. > > The rest is left as an exersize to the reader. :-) > > All you really need is the function name, which should be the last > token before the opening '('. Yes, but which opening? There might be several at nesting level 0. And searching backward to find the matching ( from the last ) might not be always correct either. You have the case: void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) __attribute__((noreturn)) { } Sure you can have an exception if the name seems to be __attribute__ but then where might be other exceptions. > The only problem is if you want to find > the number of args for stdcall decoration, but we should be able to do > without it. That is not a problem. If you find the opening ( before the function name, it would be the number of , at nesting level 1 plus one with the special case of void between the parantesis which means 0. > > The problem is that this might work or it might not. You > have no real > > guarante that it will. > > Well the thing is if you find a declspec you output what you think is > the function name. If you get it wrong and output 'WINAPI' or 'char*' > instead you'll notice it at build time. Perhaps. You will easily reach 99% correctness. However beyond that it is hard without a real C parser. It easy to do that for reasonable functions but for ALL function is much harder. For example you have the special case of a function that returns a function pointer. Not even all C compilers gets that one right, so it normally done with a helping typedef...

2 1

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > Not quite. If you run the tool on every commit (which is in > effect what's > > happening now), you almost guarantee that many people > contributing code > > will experience conflicts on a *daily* basis. If you run > the tool once > > once a year, I will experience the conflict only then. And > I will be so > > much happy. > > Well yes, that's what I meant by saying that the tool is "useless". If > I'm the only one who can use it, and then only once a year, we don't > really need it. As I can see it either we enforce no trailing whitespace or we do not. I can't see any reasonable middle ground. I'm of course for no trailing whitespace. :-) However I'm not going to start a new flamewar other it... > And in fact we should probably remove it so that other > people are not tempted to use it... The orginal reason for winapi_cleanup was to convert the \r\n that I got while editing in Micrsoft Developer studio to \n. But I can modify it the so it only does that. It should probably remove trailing whitespace at lines ending in \ though since some compilers choke on that.

2 1

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 01:51 pm, Alexandre Julliard wrote: > > And in fact we should probably remove it so that other > > people are not tempted to use it... > > As long as I don't have to deal with the conflicts. I had > only grief from removing the whitespace, and NO benefit. > For me, the choice is clear. Have you tried to run winapi_cleanup before submitting the patch or alternatively before running "cvs update"?

1 0

OfficeXP/IE and latest CVS wine
by Boris 11 Sep '02

11 Sep '02

I downloaded the latest wine cvs [09-11-2002] and not using any windows files. I tried installing OfficeXP and only when I set the OS to Winme, It continues the farthest until it starts installing and then it says the setup files are corrupted. I looked at my status window and it says fixme:advapi:SetThreadToken((nil_,cafe): stub (NT impl. only) fixme:setupapi:SetupIterateCabinetA not implemented (setupapi.dll) Ive noticed even when trying to install IE5 or 6 without any hacks, it seems that their are *alot* of things not implimented in the setupapi. It would be nice to get install IE 5 or 6 off a clean wine installation without hacking the configs or creating any extra directories.

2 1

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > On September 11, 2002 12:58 pm, Alexandre Julliard > > wrote: > > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > > > Well, I'm happy to turn it off if people consider > > it to be a problem. > > > > I think it should be turned off. It causes a lot of > > grief, for very little > > gain, if any. Moreover, now you have a tool in the > > tree that does that > > automatically, and cleverly. > > > > If you think whitespaces are a problem, *you* apply > > it say, once a year. > > Or every 5 years, I don't care. > > I (personally) like to keep it the way it is. > If the submitter is worried about the spaces he can > run the whitespaces cleaning tool himself before > submitting the patch (hint, hint ;-) Exactly. :-)

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 11:07 am, Patrik Stridvall wrote: > > > Well as I said a lot of API use LPSTR when it really should > > use LPCSTR so the potential IO/OUT cases are quite a few. > > I don't think it's "lot". Can you give a count where LPSTR/LPWSTR > is used for a IN parameter only? I don't know how to do that automatically. You will have to look in the documentation and sometimes the documention is wrong... > And those we can fix in our > sources, as you said. Yes. > > You mean just add a OUT before the type. That is quite easy > to parse. > > Even better -- encode it in the typeinfo. > > /* M = modifiable */ > typedef LPSTR LPMSTR; > typedef LPWSTR LPMWSTR; > > Use LPM{,W}STR instead of LP{,W}STR where the parameter is an IO one. > The type are equivalent, so no one will notice a difference except > our parsing tool. I personally like the OUT better since it is official defined by Microsoft. > BTW, how many are IO? I would suspect most are O only... For strings, not that many. Can't think of any right now. However there are quite a few LPDWORD that specifies the allocated length of the output buffer and the function is should write the used length (or needed length, if the function faild) in the pointed to DWORD. Other than that it is quite uncommon IIRC.

3 2

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On Wed, 11 Sep 2002, Patrik Stridvall wrote: > [...] > > > Of course having an imperfect parser also means we cannot > use it for > > > the export info, because unlike relay debugging it needs > to be 100% > > > correct. So we either need compiler declspec support, > > > > That will leave us dependent on compilers that support it. > > I agree that Wine should not depend on hacked compilers. However it > would be nice to have anyway for Winelib. There should be an > alternative > but if it saves 'big' Winelib developpers from having to > write huge spec > files by hand then it would definitely be a plus. For Winelib sure that would be a good idea. > I'm not saying that you, Patrik, should do it. I just don't want > potential contributers to think that this is not something > that would be > useful to Wine/Winelib. OK. For the record I see absolutely nothing wrong GNU C handles __declspec(dll{import,export}) and just put useful information in some aproprietely named section. After all you can always strip the section if don't want it and BTW if why don't want it why use __declspec(dll{import,export}) at all...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> The parser shouldn't require any modification > to the source, and should work on any Windows source, not only the > Wine ones. This means there are basically two approaches: > > 1. write a full C compiler This isn't happening soon. Definitely not within the coming months and not likely this year and more likely than not neither the coming year. > 2. use Patrik's Perl stuff to generate the initial info as best as we > can and then update it by hand. > > IMO #2 is the way to go, because no matter how clever a parser you > write it won't be able to extract semantics information; and that > would be the main advantage of doing a better relay debugger. Imagine > dumping structure contents, flags, following list pointers, etc. We > shouldn't limit ourselves to what can be extracted automatically from > the source. Agreed. I can write code if you, Dimitrie or whomever specify the output format... > Of course having an imperfect parser also means we cannot use it for > the export info, because unlike relay debugging it needs to be 100% > correct. So we either need compiler declspec support, That will leave us dependent on compilers that support it. > or we need a > specialized tool to extract the declspec info in a way that is > guaranteed to not miss anything. This isn't happend soon either. It might not be THAT difficult, however the code need not just work it needs be well structured and organized as well if any reasonable guarantees of correctness can be made.

3 2

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Steven Edwards <steven_ed4153(a)yahoo.com> writes: > > > I thought the WINE tree and regression suite would try and > move away from a perl dependancy? > > How is all of this going to effect building on > Windows/ReactOS with Mingw? I have had a bitch of a > > time getting Mingw+MSYS+Perl working and would hate to see > it become a bigger requirement. If > > -mno-cygwin worked right I dont guess it would be as big of > a deal because then we could still > > build WINE-Mingw under cyg but atm some import is still > hosing things up and forcing importation > > of cygwin1.dll so the recommended setup is just Mingw+MSYS. > > Yes, we should try to move away from the Perl requirement for > regression tests. It was considered OK to depend on it because the > framework itself was based on Perl, but now that all tests are done in > C anyway we should probably get rid of it. I see no reason to get rid of it. If people doesn't have Perl installed just don't run them. But then most people probabably have Perl installed anyway...

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 10:23 am, Patrik Stridvall wrote: > > However how do know whether it is IN/OUT or OUT? > > Excellent point. There aren't that many IN/OUT cases anyway > (can you produce a count?), Well as I said a lot of API use LPSTR when it really should use LPCSTR so the potential IO/OUT cases are quite a few. > but we would need to add some > metainfo at the source level. No big deal, really... You mean just add a OUT before the type. That is quite easy to parse.

3 4

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> --- Patrik Stridvall <ps(a)leissner.se> wrote: > > > > > But beyond that, we can *today* compile Wine with > Mingw as PE. So > > > > > what we need is a checkspec make target which would run > > > your script, > > > > > compile Wine as PE, extract what needs extracting > from there, and > > > > > compare results. This does not need to happen all the > time, only > > > > > from time to time by some people that (1) have Mingw > installed, > > > > > and (2) care to do it :). > > > > > > > > True. However I still a little worried about the "stabillity" > > > > of the solution. > > > > > > Why? This is as good of a verification method (no, even > better) than > > > what we have today. > > > > Sure, but I have written the Perl code I know how ad hoc it is. > > It works under reasonable assumptions however beyond that... > > > > But I'm not really against it, I'm just pointing out > > potential problems... > > I thought the WINE tree and regression suite would try and > move away from a perl dependancy? It is not really dependent on Perl. Of course you can't run regression test written in Perl without Perl... > How is all of this going to effect building on > Windows/ReactOS with Mingw? I have had a bitch of a > time getting Mingw+MSYS+Perl working and would hate to see it > become a bigger requirement. If > -mno-cygwin worked right I dont guess it would be as big of a > deal because then we could still > build WINE-Mingw under cyg but atm some import is still > hosing things up and forcing importation > of cygwin1.dll so the recommended setup is just Mingw+MSYS. I understand. On the other hand we can't hold back "progress" just because of difficulties of installing certains tools on certain platforms. But judging from Alexandres message it won't be happing anytime soon... > Note: even using perl on cygwin is still borked atm for the > regression suite and I havent even > tried winapi_check. another option may be to look at active > perl for windows but I really dont > like that idea. ActivePython for Windows works nicely. Haven't tested ActivePerl...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> > > But beyond that, we can *today* compile Wine with Mingw as PE. So > > > what we need is a checkspec make target which would run > your script, > > > compile Wine as PE, extract what needs extracting from there, and > > > compare results. This does not need to happen all the time, only > > > from time to time by some people that (1) have Mingw installed, > > > and (2) care to do it :). > > > > True. However I still a little worried about the "stabillity" > > of the solution. > > Why? This is as good of a verification method (no, even better) than > what we have today. Sure, but I have written the Perl code I know how ad hoc it is. It works under reasonable assumptions however beyond that... But I'm not really against it, I'm just pointing out potential problems...

4 3

Standard controls
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

And since I feel frisky lately, I want to run another idea by you guys. We have the standard controls bundled with USER, just like Windows. In fact, it seems XP bundles them with the common control, but that's another story. My point is, that there's no logical reason they should be in USER. In fact, in the future we may want to provide other implementations which integrate better with GNOME and/or KDE. So what about moving them to a separate DLL, say winectrl? -- Dimi.

2 2

winebuild & (name, heap, init)
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

Alexandre, Why don't we take the following directives: name, heap, init out of the .spec file, and put them in the Makefile (transfered to winebuild through command line args)? Some of them are supported in .DEF file as well, but all of them are supported as arguments to LINK. I think it will gain us flexibility if we also support them as command line arguments. With that in mind, it would be neat if we could specify a flag at configure time to build most of Wine as PE with a cross mingw. It would be way cool if I could take the same comctl32.dll I have on Linux, copy it on my Windows machine, and test it out... Anyway, what about a patch to at least support all of this as command line options as well? -- Dimi.

4 7

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 11:33 am, Patrik Stridvall wrote: > > Sure, but I have written the Perl code I know how ad hoc it is. > > It works under reasonable assumptions however beyond that... > > But we don't *want* Wine's sources to look beyond reasonable. > I see no problem. Even better, if this helps us detect unreasonable > looking sources... Well winapi_check already does that so no additional advantage...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dpaun@rogers.com] > Sent: Wednesday, September 11, 2002 5:37 PM > To: Patrik Stridvall; Francois Gouget > Cc: Wine Devel > Subject: Re: winebuild & (name, heap, init) > > > On September 11, 2002 11:24 am, Patrik Stridvall wrote: > > > BTW, how many are IO? I would suspect most are O only... > > > > For strings, not that many. Can't think of any right now. > > However there are quite a few LPDWORD that specifies the > > allocated length of the output buffer and the function > > is should write the used length (or needed length, > > if the function faild) in the pointed to DWORD. > > Dude, you're killing me! I often do that yet you still live. :-) > We care to distinguish I/O for strings _only_. And since we > don't have any, we have no problem!!! We have I found an example: LPTSTR PathAddBackslash(LPTSTR lpszPath); A few more of the Path functions are like that IIRC. Then there might be more function. The Windows API is larger we have only begun to implement it... > For LPDWORD, print them > always, they are fixed length, you (as the guy looking at the > traces) know if you care about them or not... True. How if you wish to automatically compare debug output diffs you have a problem. Sure pointer and such usually differs but that can be fixed with some sort of mapping table. However the value of unintialized variables are "random" or rather non-derministic since they might depend of subtle differences in the enviroment. But I do agree that strings is the larger problem...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Were we distinguishing IN/OUT and OUT before in the spec file? No. I suggest to Alexandre that we should add such information but he rejected my patch...

1 0

RE: winebuild & (name, heap, init)
by Jeff Smith 11 Sep '02

11 Sep '02

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 10:16 am, Patrik Stridvall wrote: > > #define HELPER(x,y,z) DWORD WINAPI x(y arg1, z *arg1) > > > > FOO(Bar, INT, HWND) { > > /* ... */ > > } > > > > But we don't need to support that. If it doesn't get recognized, > the function is not exported. You can manually look in the generated > spec file and see it's not there. > > I don't think we need to be too clever. Just get the 80% that can be > done with 20% of effort. Well as I said "winapi_extract --spec-files" works to some extent even now and getting it to work good enough might not be that much effort. However I'm worried about the "stabillity" of the result. > It's a temporaray solution anyway: we need > help from the compiler, writing a C parser (no, a gcc-C parser) is > a lot of work. Yes. I know I have tried. :-) > Mingw supports __declspec, Urlich, what would it take > for the regular gcc to support it under Linux/ELF? But what should it do? Just generate a special dllexport section that you can read with appropriate tools or what? > But beyond that, we can *today* compile Wine with Mingw as PE. So > what we need is a checkspec make target which would run your script, > compile Wine as PE, extract what needs extracting from there, and > compare results. This does not need to happen all the time, only > from time to time by some people that (1) have Mingw installed, > and (2) care to do it :). True. However I still a little worried about the "stabillity" of the solution.

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 05:48 am, Francois Gouget wrote: > > Hmm, for strings the spec files currently distinguish between input > > strings (str) and output strings (ptr). This cannot be > extracted from > > the source files... unless we start using IN/OUT macros everywhere? > > It's all in the types, dude... > > LPCSTR/LPCWSTR = IN, LPSTR/LPWSTR=IN/OUT. The is almost always correct. Unfortunately Microsoft is not consequent in the regard, but then I guess that we could modify the API slightly. If a WineLib application breaks, it was in some meaning broken anyway. However how do know whether it is IN/OUT or OUT? For debug messages that is quite important since the pointer in the OUT case might point to uninitialized memory which shouldn't be printed in the debug output...

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 06:18 am, Patrik Stridvall wrote: > > However I might be able to write a very specialized parser, that > > pipes the .c files through the C preprosessor, that work all of the > > time, but this is quite some work as well. > > But we shouldn't need that. Wine has a very good strucutre right now, > and were that's broken, we can fix... Sure. But what would tell you that it was broken? winapi_check currently, among other thing, compares the .spec files with the source code. When it reports something there are three possibillities 1. winapi_check is broken (because the code doesn't have good structure) 2. the .spec file is broken 3. the .c file is broken Currently I check manually and I try to make an educated guess of which is the cases and then fix it. If you extract the information from the source you don't have that luxury. If it misses a function or have some other bug you have no backup. Since the .spec files exists winapi_check knows what functions it is expected to find in the source code and if is doesn't it reports it. So if for example we have function Foo that looks like. #define HELPER(x,y,z) DWORD WINAPI x(y arg1, z *arg1) FOO(Bar, INT, HWND) { /* ... */ } winapi_check will miss it (since it in an ad hoc parser), but since Bar is declared in some .spec file it will complain that Bar was never found. Then I manually search the source, and try to fix the problem somehow. If you on the other hand extract the .spec files (of .def files) from the source the function Bar would be missed and you would never detect it... That is why the parser needs to be so good that it "always" works.

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 10, 2002 02:15 pm, Alexandre Julliard wrote: > > > Well, the problem is that the __declspec stuff is usually inside > > macros, so you have to run the code through the C > preprocessor to find > > them. It can be done, but it's not that trivial. Also one thing you > > need to extract is the relay debugging information (and for 16-bit > > code information for the relay routines), and this requires > a C parser > > (or some of Patrik's magic Perl stuff). > > I'm sure if we have the political will at the top, we'll find a > solution... :) Patrik, care to help us extract the required stuff > directly out of the source file? Sure. BTW winapi_extract can already do that: winapi_extract --spec-files This generates a .spec2 file that should hopefully be the same as the .spec file. It currently isn't (except for a few files) though but that can hopefully be fixed. Outputing in another format like .def files or whatever should be quite easy. However note that winapi_extract is quite ad hoc and specfic for parsing the Wine source tree. It is not a generalized C parser. I have begun with a generalized C parser in winapi_fixup however it doesn't quite work that good yet. Parsing generalized C is non trivial. > > A related idea I had is to store the relay debugging independently > > from the .spec file; you could then use it in other cases, notably > > with snoop debugging of native dlls. And then you no longer need a > > .spec, you can use a .def or directly extract the __declspecs, at > > least for Win32. This would also potentially allow more intelligent > > relay routines, maybe even per-dll relay code that knows > about the dll > > internal data structures; and hopefully also relay debugging of COM > > interfaces. > > Exactly! That's where I was driving at. But this depends on getting > stuff automatically out of .c file, because this way we can retain > the type information, which we now lose (except for strings). Once > we have the type information, the sky's the limit... But most > imprtantly, > we eliminate (1) a potential source of mistakes, (2) a barrier for > new commers (which are likely to be from the Windows world), and > (3) avoid maintenaning the 700KB of .specs!!! Agreed, but the script that does it is also a potential source of mistake and the current state of the winapi tools are that they work MOST of the time. However if we are to replace the .spec files it must work ALL the time. However I might be able to write a very specialized parser, that pipes the .c files through the C preprosessor, that work all of the time, but this is quite some work as well. Note however that piping every source file through the C prepropessor is VERY SLOW. That is one of the reason the winapi tools doesn't do that.

2 1

Re: wine/tools winemaker (1.49 - breaks winemaker)
by Martin Wilck 11 Sep '02

11 Sep '02

Am Mit, 2002-09-11 um 03.09 schrieb Alexandre Julliard: > ChangeSet ID: 1031706598725635746101947 Sorry, but this patch is severely broken - it introduces several regressions. > Log message: > Francois Gouget <fgouget(a)codeweavers.com> > Store the global settings in Make.rules.in instead of duplicating them > in each Makefile.in file. > Introduce generate_from_template which replaces generate_configure > and generate_generic > Simplify the wrapper generation by using generate_from_template. > Rename configure.in to configure.ac. Now works with autoconf 2.5x. This is what happened to me with a trivial winelib test setup: 1. winemaker doesn't even run - perl compilation error in generate_wrapper_file(). 2. After that's fixed, autoconf fails. Winemaker may now work with autoconf 2.5x, but is broken with 2.13. I wonder if this is intentional. If yes, I am against it - you cannot assume that all winelib developers have autoconf 2.5x. At the very least, it should be documented. 3. After that's fixed, configure fails with "Could not include the Wine headers (windef.h)". At this point I have stopped investigating further. Here is a quick fix for 1. and 2. - I will look into 3. and possible further problems later. Martin Index: winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.49 diff -u -r1.49 winemaker --- winemaker 11 Sep 2002 01:09:58 -0000 1.49 +++ winemaker 11 Sep 2002 09:52:51 -0000 @@ -1670,6 +1670,7 @@ { my $path=$_[0]; my $target=$_[1]; + my $app_name=@$target[$T_NAME]; return generate_from_template("wrapper.c","$path${app_name}_wrapper.c",[ ["APP_NAME",@$target[$T_NAME]], @@ -2069,7 +2070,7 @@ ["PROJECTS",join("\n",map { "@$_[$P_PATH]Makefile" } @projects)], ["SOURCE","$a_source_file"], ["NEEDS_MFC","$needs_mfc"]]); - system("autoconf"); + system("autoconf configure.ac > configure"); # Add execute permission to configure for whoever has the right to read it my @st=stat("configure"); -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On Wed, 11 Sep 2002, Dimitrie O. Paun wrote: > [...] > > Exactly! That's where I was driving at. But this depends on getting > > stuff automatically out of .c file, because this way we can retain > > the type information, which we now lose (except for strings). Once > > we have the type information, the sky's the limit... > > Hmm, for strings the spec files currently distinguish between input > strings (str) and output strings (ptr). This cannot be extracted from > the source files... unless we start using IN/OUT macros everywhere? Or we could do as winapi_{check,extract} already supports: BOOL WINAPI WaitCommEvent( HANDLE hFile, /* [in] handle of comm port to wait for */ LPDWORD lpdwEvents, /* [out] event(s) that were detected */ LPOVERLAPPED lpOverlapped) /* [in/out] for Asynchronous waiting */ { /* ... */ } Alexandre rejected having in/out markers in the .spec files so I never continued that project... > Anyway, where it would be most useful is for Winelib > applications. So if > we can support these then it would be great. Yes. > But it wouldn't it be > easier to hack the compiler? Maybe. :-) However the compiler must be really clever to determinte whether a pointer parameter is IN, OUT or IN/OUT. Futhermore it is logically impossible for stubbed functions and for stubbed functions it would be really nice to see the parameters wouldn't it? So I guess we have to put it in the source code somewhere. See my suggestion above.

1 0

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