wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

What is the @ in the function headers
by Bill Medland 03 Aug '01

03 Aug '01

Quick question. What is the @ in a function header supposed to contain? Presumably it is the ordinal in the Dll. But what if the same function has different ordinals in different copies of the Dll? Bill

1 0

Re: Dont allow SetSelectorBase to change into an kernel region
by Alexandre Julliard 03 Aug '01

03 Aug '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > If I only allow to set the selector base when (selector base + selector > limit) is smaller than 0x8000000, the application goes on and lets me read > an eprom plugged into the Galep3 Programmer. Is the appended fix a right > acceptable? No, it's legal to have selectors covering the entire address space. I'm afraid there is no good solution to this kind of problem. What does the app do under NT or with -winver nt40? -- Alexandre Julliard julliard(a)winehq.com

2 1

Some questions about TB_REPLACEBITMAP
by Marco Bizzarri 03 Aug '01

03 Aug '01

Hi all. I'm trying to implement the TB_REPLACEBITMAP message in the comctrl32, and I would like to have some advice about the ImageList structure. The TB_REPLACEBITMAP provides (via the hInst, nID pair) the handle to the old bitmap and the handle to the new bitmap, as well as the number of button in the new bitmap. I think I could use the ImageList_Replace to actually replace the bitmaps. However, the ImageList_Replace function requires a number, which is the first bitmap to be replaced. How can I retrieve this information? For what I can see, once a bitmap has been added to the imagelist, no information about is is stored. I'm doing some tests, using a value (like 0) as the bitmap index, but this is of little help, of course. Any help will be appreciated. Bye Marco

1 0

Some questions about TB_REPLACEBITMAP
by Marco Bizzarri 03 Aug '01

03 Aug '01

1 0

Switching threads in winedbg
by Francois Gouget 03 Aug '01

03 Aug '01

Is it possible to switch threads in winedbg? I can use 'walk thread' to see a list of the threads of my application but I could not find how to get a backtrace of one of these other threads. It's not in the Wine Developper's Guide and I could not find it from the source. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

2 1

Dose wine people hate Solaris?
by EriK W 03 Aug '01

03 Aug '01

I have posted my question for compiling Wine in solaris x86 for 2 weeks, seems no anybody even has a bit interest. Do you guys hate solaris? :) I checked almost all the documents and faq, except it mentioned wine works with Solaris, there almost have no other info for it at all. Does anybody has even a suggestion for me? pls don't tell me nuke my solaris. :)

5 8

Re: Documenting functions
by Alexandre Julliard 02 Aug '01

02 Aug '01

"Bill Medland" <medbi01(a)accpac.com> writes: > Ay, there's the rub. It isn't our function. It';s Microsoft's function. > Now was it Holub or McConnell that complains about functions having weird > behaviour on certain inputs. IMO Microsoft functions need less documentation than internal ones, since there is MSDN and other countless books about Windows. You can assume that people reading your code already know what the various APIs are supposed to do. > The biggest problem, I believe, is the functions that take flags. Bear in > mind that a single DWORD argument used for flags is equivalent to up to 32 > boolean arguments. Documenting the relationship between those is a pain > but it needs to be done if we expect compatibility. This is clearly something that is best documented with code, not with text. You may need pages of text to describe the flags behavior in English, while with code it's usually only a few lines, plus a few comments here and there. This doesn't mean it wouldn't be a good thing to also have the full description in English; but in a separate document, not in the code. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Prevent excessive clipping in SysListView32
by Uwe Bonnes 02 Aug '01

02 Aug '01

>>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: Medland,> I am not very comfortable with this one but strange as it may Medland,> seem it solves the problem. I'd love to know why. Medland,> <<diff13.txt>> Bill Medland (medbi01(a)accpac.com) Prevents Medland,> excessive clipping in SysListView32. Medland,> Medland,>-static inline int perfect_graphics(void) Medland,>+static int perfect_graphics(void) Medland,> { Medland,> static int perfect = -1; Medland,> if (perfect == -1) Medland,> Some C-Expert is requested here, but I suspect that in the old function the variable "perfect" was created in every instantiation of the "perfect_graphics" inlined function. Could you perhaps try to declare the "perfect" outside the inlined function, like static int perfect = -1; static inline int perfect_graphics(void) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

6 9

Re: Documenting functions
by Alexandre Julliard 02 Aug '01

02 Aug '01

Jeremy White <jwhite(a)codeweavers.com> writes: > I would say that I would rather have 100% of the effort a > particular developer *wants* to put in, rather than only > have his/her coding efforts. Absolutely; I'm not going to discourage anybody from writing doc if they feel like it. But I don't want anyone to feel somehow obliged to spend time on the doc if they'd rather be writing code, which I expect is the case with most developers... > However, I think that there should be a standard function > header, with a standard place to put notes and comments > in general about a function. I don't see a need to standardize anything. If you want to add a comment before a function just do it, there is no need for a standard format, plain text works just as well. > I have been trained, and I suspect that many of us have > been trained, to look at a function header for general > tips and tricks before diving into the code. I know > this is sacriledge to you, Alexandre, but there are some > of us who like to quickly look at a function, rather than > always reading the code to understand it completely. I think you misunderstand my position; I'm not opposed to having a comment at the start of the function explaining the general goal and the non-obvious things going on. But if you need more than a couple of paragraphs to do this, then either there are too many non-obvious things going on in your function, or you are wasting space explaining the obvious. I do strongly think that the goal should be to write code that doesn't require documentation in order to be understood. Of course adding a small amount of comments is a good idea; but when you start having more lines of documentation than lines of code, something is very wrong IMO. But this is mainly a matter of personal taste, and except in extreme cases I'm not going to reject code because it has too much (or not enough) documentation. It may happen that some of your beloved horizontal lines get lost during the cvs commit though ;-) -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Documenting functions
by Jeremy White 02 Aug '01

02 Aug '01

[Resend due to exim crash; thanks Ove] >> I'd much rather have developers spend their time writing code. Making >> them duplicate the whole MSDN documentation would be a huge waste of >> their time. Our resources are not infinite, and it's much more useful >> to have 100% API coverage with no docs at all than 50% coverage and >> tons of docs. I think this is a dangerous attitude to take. I think that you cannot (and should not) attempt to force volunteer developers to add documentation to code. However, there are some few of us, who don't feel that the job is satisfactorily done until the documentation reflects important things that we've learned. I would say that I would rather have 100% of the effort a particular developer *wants* to put in, rather than only have his/her coding efforts. If I, like Bill, spend 24 hours ripping my hair out to learn some oddball things, I want a place to put those things. I want someone else (or an older version of me) to have a chance to not have to learn those things the hard way. Please don't misunderstand me. I agree that we shouldn't try to replicate MSDN. I'm not even sure we should provide minimal documentation like parameter lists and return values. Further, I agree that where it makes sense, the best place for comments is inline with the relevant code. However, I think that there should be a standard function header, with a standard place to put notes and comments in general about a function. I have been trained, and I suspect that many of us have been trained, to look at a function header for general tips and tricks before diving into the code. I know this is sacriledge to you, Alexandre, but there are some of us who like to quickly look at a function, rather than always reading the code to understand it completely. <in joke> Finally, I think all the code would be dramatically improved, in fact, I bet we'd be at Wine 1.0 by now, if there were nice big horizontal separator lines everywhere. </in joke>

1 0

Re: Documenting functions
by Alexandre Julliard 02 Aug '01

02 Aug '01

Francois Gouget <fgouget(a)free.fr> writes: > So I think the functions implemented in Wine should be fully > documented. And the only place to do that is in the code source because > this is the only place where they have a remote chance of staying up to > date (and also where it's most practical to have it). I have to disagree here. Yes it would be nice to have a free Win API documentation, but it definitely doesn't belong inside the Wine source. First it would be a huge bloat in the source; and more importantly the Wine source doesn't define the Windows API, it is defined by Microsoft. > Of course developpers are very well-known for hating to document > stuff so it's going to be pretty hard to get proper documentation. But > we should encourage all Wine developpers to write good documentation for > the functions they implement/fix, not dissuade them to do so. I'd much rather have developers spend their time writing code. Making them duplicate the whole MSDN documentation would be a huge waste of their time. Our resources are not infinite, and it's much more useful to have 100% API coverage with no docs at all than 50% coverage and tons of docs. > Also I agree with you that the strict minimum is to at least document > all the undocumented/weird behaviors. Especially since without some sort > of documentation the next developper may be tempted to remove what looks > like unnecessarily convoluted/obviously wrong code. That should be done with comments inside the code itself. And in many cases it would actually be better to comment the places where the behavior is not right. What I mean is, instead of adding a comment on every line stating "yes this is what Windows does", I'd prefer adding a comment/FIXME to mark the lines that have been written without checking whether Windows really does it this way. -- Alexandre Julliard julliard(a)winehq.com

2 1

Dont allow SetSelectorBase to change into an kernel region
by Uwe Bonnes 01 Aug '01

01 Aug '01

Hallo, galep3 crashes with following sequence: 096c7b38:Call KERNEL.189: SETSELECTORLIMIT(0x0d87,0x0000045f) ret=02e7:6fb5 ds=099f 096c7b38:Ret KERNEL.189: SETSELECTORLIMIT() retval=0x0d87 ret=02e7:6fb5 ds=099f 096c7b38:Call KERNEL.187: SETSELECTORBASE(0x0d87,0xc02924e0) ret=02e7:6fc1 ds=099f 096c7b38:Ret KERNEL.187: SETSELECTORBASE() retval=0x0d87 ret=02e7:6fc1 ds=099f ... Unhandled exception: page fault on read access to 0xc0292545 Obviously the application trys to reach some kernel memory. If I only allow to set the selector base when (selector base + selector limit) is smaller than 0x8000000, the application goes on and lets me read an eprom plugged into the Galep3 Programmer. Is the appended fix a right acceptable? Index: wine/memory/selector.c =================================================================== RCS file: /home/wine/wine/memory/selector.c,v retrieving revision 1.39 diff -u -r1.39 selector.c --- wine/memory/selector.c 19 Jul 2001 00:39:10 -0000 1.39 +++ wine/memory/selector.c 1 Aug 2001 17:30:48 -0000 @@ -327,7 +327,12 @@ LDT_ENTRY entry; wine_ldt_get_entry( sel, &entry ); wine_ldt_set_base( &entry, DOSMEM_MapDosToLinear(base) ); - wine_ldt_set_entry( sel, &entry ); + if ((base + wine_ldt_copy.limit[sel >> __AHSHIFT]) > 0x8000000) + { + FIXME("Illegal region base %lx limit %lx\n", base,wine_ldt_copy.limit[sel >> __AHSHIFT]); + } + else + wine_ldt_set_entry( sel, &entry ); return sel; } 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 1

Strange window handle in the trace
by Marco Bizzarri <m.bizzarri＠icube.it> 01 Aug '01

01 Aug '01

Hi all. I'm working on a no-windows installation. The system is a RH 6.2 system, upgraded to the latest patches. I've installed XFree4 and KDE 2.1 I'm experiencing an unhandled exception when I try to a VC application. The application works (almost) fine until it opens a selection dialog, with a list on it. As you can see from the trace, it is trying to do an RDW_UpdateRgns with a wndPtr of 0xffff Unhandled exception: page fault on read access to 0x08fd506b in 32-bit code (0x406d1771). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x406d1771 (RDW_UpdateRgns+0x3c9 [painting.c:720] in libuser32.so): testb $ 0x10,0x6b(%esi) 720 if( wnd->dwStyle & WS_VISIBLE ) Wine-dbg>bt Backtrace: =>0 0x406d1771 (RDW_UpdateRgns+0x3c9(wndPtr=0xffff, hRgn=0x0, flags=0x180, firstRecursLevel=0x0) [painting.c:720] in libuser32.so) (ebp=405b1bc4) 1 0x406d1787 (RDW_UpdateRgns+0x3df(wndPtr=0x40377824, hRgn=0x0, flags=0x180, firstRecursLevel=0x0) [painting.c:721] in libuser32.so) (ebp=405b1c20) 2 0x406d1787 (RDW_UpdateRgns+0x3df(wndPtr=0x40377538, hRgn=0x0, flags=0x180, firstRecursLevel=0x1) [painting.c:721] in libuser32.so) (ebp=405b1c7c) 3 0x406d1e08 (RedrawWindow+0x38c(hwnd=0x43f0, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x180) [painting.c:982] in libuser32.so) (ebp=405b1cd4) 4 0x406d1f1d (UpdateWindow+0x21(hwnd=0x43f0) [painting.c:1015] in libuser32.so) (ebp=405b1cf0) 5 0x0043df7a (<Debugged process>.EntryPoint+0x13625 in <Debugged process>) (ebp=0046e660) 6 0x00000623 (ebp=000044e4) Just for "fun", I've tryied to add checks for 0xffff, but it crashes when it enters non Wine DLL (actually they are Spread dlls from Farpoint) Any clue? Thanks you all in advance Bye Marco -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588

1 0

CloseHandle with 0xffffffff parameter
by Marco Bizzarri 01 Aug '01

01 Aug '01

Hi All. While trying to make an application working under wine, I've stumped into the following trace fragment, obtained with --debugmsg +relay: 081612c8:Call kernel32.CreateFileA(405f6454 "c:\\rs\\project\\apitest\\vc\\32\\apitestvc60\\debug\\ret_dll.pdb",80000000,00000001,00000000,00000003,00000080,00000000) ret=404aa001 081612c8:Ret kernel32.CreateFileA() retval=ffffffff ret=404aa001 081612c8:Call kernel32.CloseHandle(ffffffff) ret=404aa0bd 081612c8:Ret kernel32.CloseHandle() retval=00000000 ret=404aa0bd As you can see, the program is trying to open a file, which is not found. An invalid handle (ffffffff) is returned. The program however closes the handle. My question is: is this correct? Should the CloseHandle check to see if it is a correct handle? Thank you all in advance Marco Bizzarri -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588

1 0

Documenting functions
by Bill Medland 01 Aug '01

01 Aug '01

Getting back to what we are and are not allowed to do.. Suppose I am looking at a low-level function that I believe is only 75%-complete (the most important 75% of course and no disrespect meant to those who have got it that far). One of the problems with it is it is not totally clear EXACTLY what the function should do in some of its more esoteric modes. To me the first task is to define what it should do and that should be part of the documentation of the function. The particular function currently does not have any true documentation within the code; the best documentation of what it does is the code itself, and the best documentation of what it should do is the MSDN description of the function. 1. Should the function be completely defined in its header in the source code (which will probably make the header twice as large as the function) or should the details be put somewhere else. 2. Are we walking into copyright danger if the Wine documentation of the function is clearly based on the MSDN documentation, even if we acknowledge that. 3. Are we interested in that level of documentation? Bill

4 3

Re: Patch to fix the Linux 2.2 joysitck interface
by Alexandre Julliard 31 Jul '01

31 Jul '01

David Hagood <wowbagger(a)sktc.net> writes: > To be done: the file descriptor is never closed under normal > circumstances - this might be a problem if a Wine app is opened and > accesses the stick, as the file descriptor will be open until that > process terminates. If this is viewed as a problem, it would be a simple > matter to add a device close function to the Wine driver to close the FD. Shouldn't this be done in the driver DRV_OPEN/DRV_CLOSE calls then? Any joystick experts out there? (BTW please use diff -u to generate patches, the default diff format is unreadable). -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: RFC: Patch for making GrabPointer work
by Alexandre Julliard 31 Jul '01

31 Jul '01

Jukka Heinonen <jhei(a)iki.fi> writes: > Storing old windows procedure in struct x11drv_win_data > would remove the worst race, but unless window > procedure update is atomic, it would not remove > all races. Since you have the window locked when changing the wnd proc the update will be atomic. The only problem I see is that your wnd proc might get called to process some other message, but you can solve this by having it chain to the previous wnd proc for all messages except the special one. -- Alexandre Julliard julliard(a)winehq.com

2 1

Relocatoion and ExceptionFilter problem?
by EriK W 30 Jul '01

30 Jul '01

Now I finally made a wine , :) But I can't get any program to excute so far, mostly It is like bash-2.03# wine --winver win95 sol.exe err:seh:UnhandledExceptionFilter Couldn't start debugger (debugger/winedbg 134639312 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger or bash-2.03# wine --winver win98 icq2000b.exe err:win32:do_relocations Standard load address for a Win32 program not available - patched kernel ? err:win32:do_relocations FATAL: Need to relocate F:\export\home\ericw\system\icq2000b.exe, but no relocation records present (stripped during link). Try to run that file directly ! wine: can't exec 'icq2000b.exe': error=21 This wine seems taste not good, :) Francois Gouget wrote: > On Thu, 26 Jul 2001, EriK W wrote: > > > > What does not work? Do you have unicode/libwine_unicode.so or not? > > > Does the following command run or does it say it cannot find > > > libwine_unicode.so? > > > > > I does have the libwine_unicode.so > > but it just don't go to ~unicode directory to search for it, it always > > report " can't find it in /usr/local/lib" I don't know why, I am using bash, > > so I just simply copied libwine_unicode.so over to make it happy. > > I was wondering if it was the shell not exporting the environment > variable or something. Since you're using bash it should be all fine. > So you have to figure out why setting LD_LIBRARY_PATH does not work. > It's supposed to work. I'm 99.9% sure I did use it on Sparc Solaris so I > really don't see why it would not work on Solaris x86. Plus > LD_LIBRARY_PATH is such an important thing that it would be very > surprising if it really did not work and nothing else was broken in your > system. > > Did you try specifying an absolute path like: > LD_LIBRARY_PATH=/export/home/system/wine-20010629/unicode ./tools/winebuild/winebuild > > What does 'echo $LD_LIBRARY_PATH' normally say? Is it empty? > > [...] > > take it out? > > Can I do that by commenting " > > LIBPROGRAMS = \ > > debugger/winedbg" ? > > The following patch should do that nicely: > > --- cut here --- > Index: Makefile.in > =================================================================== > RCS file: /home/wine/wine/debugger/Makefile.in,v > retrieving revision 1.24 > diff -u -r1.24 Makefile.in > --- Makefile.in 2000/12/29 05:38:00 1.24 > +++ Makefile.in 2001/07/27 01:39:15 > @@ -3,7 +3,7 @@ > TOPOBJDIR = .. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > -MODULE = winedbg > +MODULE = #winedbg > > C_SRCS = \ > break.c \ > --- Makefile.orig Thu Jul 26 19:03:36 2001 > +++ Makefile Thu Jul 26 19:00:53 2001 > @@ -3,7 +3,7 @@ > TOPSRCDIR = .. > TOPOBJDIR = .. > SRCDIR = . > -MODULE = winedbg > +MODULE = #winedbg > > C_SRCS = \ > break.c \ > --- cut here --- > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Broadcast message : fin du monde dans cinq minutes, repentez vous !

2 2

RE: Small OpenGL patch
by Patrik Stridvall 30 Jul '01

30 Jul '01

> It also puts the 'make_opengl' script in line with the latest > modification > to the spec file. It also changes the OPENGL32.@ to OPENGL.@ > as per Patrik's > modifications in 'make_opengl'. Arrgghhh! I just saw that I didn't do the same change in the script as in the .c files (I didn't run the script, since it worked badly last time I tried with my OpenGL files). Braino. :-( It should of course be OPENGL32.@ not OPENGL.@. The .c files was correct as they were. Sorry to cause you problems but can you fix the script and rerun on your OpenGL files and resubmit. > PS: god I hate Perl... I may well rewrite 'make_opengl' in > Python one of > these days :-) Whats wrong with Perl? I write applications sometimes in Perl and sometimes in Python, and I like them both and a dislike somethings about each language as well. Of course Perl is a little more difficult to learn but still. PS. You will se one of the advantages of Perl if you add use strict; at the top of the script. Of course after that you will have to declare all variable to it keeps the number of bugs down.

1 0

RE: winapi update
by Patrik Stridvall 30 Jul '01

30 Jul '01

> > In short, please apply it, they facillitates using the > > winapi tools alot and might make more people actually > > use them. They don't hurt anything. > > The problem is if we make it part of the default make install all Wine > distributions will include these non-functional (from the user POV) > scripts, and I don't think this is a good idea. That is true. > So I have applied it > but it doesn't run by default; developers who want it should run make > install in the tools/winapi directory. Ah, of course. Good idea. Thanks. This brings to mind the fact that three different kinds of "users": 1. Ordinary users 2. Wine/Winelib developers 3. Winelib application developers that need different kinds of tools installed. Not that I have any good solution to the problem. And not something that really is a problem either. Is was just something that occured to me. Oh well. Never mind.

1 0

Re: winapi update
by Alexandre Julliard 30 Jul '01

30 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > A full install is largely meaningless since the winapi tools are made > for work on a Wine source tree, so making them independant of such > a tree is largely meaningless. Agreed. > In short, please apply it, they facillitates using the > winapi tools alot and might make more people actually > use them. They don't hurt anything. The problem is if we make it part of the default make install all Wine distributions will include these non-functional (from the user POV) scripts, and I don't think this is a good idea. So I have applied it but it doesn't run by default; developers who want it should run make install in the tools/winapi directory. -- Alexandre Julliard julliard(a)winehq.com

1 0

broken misc/version.c (patch 1.43 -> 1.44) WIN95 value in version16
by Ladislav Sladecek 30 Jul '01

30 Jul '01

Two days ago a 16 bit application, which I use, started to complain about unknown windows version. After I rgressed to 1.43 of misc/version.c, everything was OK. I found the problem in the GetVersionInfo value that you changed at line 75 of the file. My windows 95 returns 0xC0000004 in WIN32 and 0x07005F03 in WIN16. You changed the 16bit value from 0x7005F03 to 0x7000304. Can you please check this? Do you have some docs? I think that we that we are both right; the value probably depends on longitude, altitude, and Windows language version. Mine iWindows 95 is Czech Edition, SR2. Regards Ladislav Sladecek

1 0

RE: winapi update
by Patrik Stridvall 30 Jul '01

30 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I have resent winapi_install patch. > > > > While it probably that you didn't apply > > it because of lack of time I resend > > for your convinience. If not please > > explain. > > Correct me if I'm wrong, but it seems you are not actually installing > anything, only a script that needs the Wine source tree to work. That is a correct conclusion. > I don't really see the point. The point is that when you are in some sub directory of a wine tree, you can just write winapi_check or make_filter and whatever and it will call the correct version of the tool. Instead of having to type, if you are in dlls/winsock. ../../tools/winapi_check Sure you can currently do make winapi_check or make filter and adding winapi_{extract,fixup} is trivial but giving arguments through make is a little awkward. That why I wrote a few script to fix this and now when I have a tool (make_filter) that could possibly enjoy a wider use I decided to make a formalized "install" for them. > If you want to install something it should > be a complete installation that works without external files (not that > I suggest doing that for winapi_check, at least not by default). A full install is largely meaningless since the winapi tools are made for work on a Wine source tree, so making them independant of such a tree is largely meaningless. Well they actually are indendent of the specific tree they where install from. They do not reference to it at all. They use the current directory to find the real winapi tools in that tree. They will work equally well with any tree (of a later date than your hopefull application of the patch that is). They are as they are by design, not by mistake, and complete installation of them is almost completly meaningless. Sure there might be future winapi tools worthy of a complete install, a future tool for automatical generation of .spec files from any Winelib application, that we talked about some time ago, comes to mind, but I'm not there quite yet. I have begun to implement simple typedef parsing but it doesn't work 100% yet. In short, please apply it, they facillitates using the winapi tools alot and might make more people actually use them. They don't hurt anything.

1 0

Re: winapi update
by Alexandre Julliard 30 Jul '01

30 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > I have resent winapi_install patch. > > While it probably that you didn't apply > it because of lack of time I resend > for your convinience. If not please > explain. Correct me if I'm wrong, but it seems you are not actually installing anything, only a script that needs the Wine source tree to work. I don't really see the point. If you want to install something it should be a complete installation that works without external files (not that I suggest doing that for winapi_check, at least not by default). -- Alexandre Julliard julliard(a)winehq.com

1 0

Possible printer driver bug
by Jukka Heinonen 30 Jul '01

30 Jul '01

Wine compiled from CVS crashes since file "wine/dlls/gdi/driver.c" passes a NULL pointer to function CreateICA. The following patch stops crashing, but since I have no idea how Wine printer drivers work, this patch might be plain wrong. After this patch, Wine no longer crashes, but I haven't been able to test whether printing works or not. Index: wine/dlls/gdi/driver.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/driver.c,v retrieving revision 1.2 diff -u -r1.2 driver.c --- wine/dlls/gdi/driver.c 2001/07/28 00:18:02 1.2 +++ wine/dlls/gdi/driver.c 2001/07/29 14:10:18 @@ -376,7 +376,7 @@ if(!DRIVER_GetDriverName( lpszDevice, buf, sizeof(buf) )) return -1; - if (!(hdc = CreateICA( buf, NULL, lpszPort, NULL ))) return -1; + if (!(hdc = CreateICA( buf, lpszDevice, lpszPort, NULL ))) return -1; if ((dc = DC_GetDCPtr( hdc ))) { -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel