Re: How are we doing?
Friday, June 2, 2006, 12:20:58 PM, EA Durbin wrote: >>From: Juan Lang <[EMAIL PROTECTED]> >>To: EA Durbin <[EMAIL PROTECTED]> >>CC: wine-devel@winehq.org >>Subject: Re: How are we doing? >>Date: Fri, 2 Jun 2006 10:56:15 -0700 (PDT) >> >> > Especially the code that is responded to as , I know it's a mess to >> > look at, but I didn't write it. >> >>Can you give us examples? >> >>Mostly Wine attempts to follow how Windows works, so MSDN provides a lot >>of the documentation. This is becoming increasingly true, with kernel32 >>being implemented on top of ntdll. >> >>There are bits that are hard to understand, certainly, and some areas >>could use some comments. Unfortunately sometimes the lack of comments >>demonstrates a lack of understanding, but the code works for someone, >>somewhere, so we're mostly afraid to touch it until some brave soul comes >>along. >> >>For example, SHFileOperation was a complete mess until James fixed it up. >> >>Another example is user32. It's impossible to document (in English) what >>it's supposed to be doing. For this, and many other cases, a good >>regression test suite is the best documentation: it tells you what's >>expected, so if you go mucking around you have checks against introducing >>regressions. >> >>I know you've been working with msi lately. The fact that you've figured >>out where the problem is indicates to me that it's adequately commented, >>even if the learning curve is still a bit steep. >> >>Patches to add API comments for the Wine API guide >>(http://source.winehq.org/WineAPI/ ) are always welcome. Patches to >>document dodgy bits of code may or may not be accepted, but regression >>tests to justify dodgy bits of code are happily accepted too. >>http://source.winehq.org/WineAPI/ >> >>--Juan >> >>__ >>Do You Yahoo!? >>Tired of spam? Yahoo! Mail has the best spam protection around >>http://mail.yahoo.com > I'm just nitpicky I guess. If I use K & R style, or not enough white space, > or don't align things perfectly at work my boss will kindly print off a copy > of the companies acceptable coding standards policy and bring it over. I > guess I'm just used to having things that way, and the shifting coding style > and lack of comments in places in wine makes the learning curve steeper than > it needs to be for beginning wine developers. > Just my 2 cents as a beginning wine developer. Oh yeah I see your pain right here... Even hard to respond in the well accepted format, not in a business ignorant style - "My comments more important so I'll put then on top." Vitaliy
Re: How are we doing?
Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote: >>There is precious little "Why" in the comments of a lot of projects - Why >>does this function exist, why would I call it, why does it return what it >>does, etc. >> >>BS comments like those within the function don't help, obviously - but >>sometimes a comment block describing WHY a given chunk of code does what it >>does would be nice. >> I don't see any problems here. If anyone needs to know _why_ some function does X - they should look on msdn. Also it would really help look at the patch itself that _does_ explain what the patch is for. And might even link to the bug #. BTW Alexandre, can we preserve references to bug numbers in patch comments? That would be an ultimate explanation to what most questionable code does. > Exactly my point. > As in the case of wine, you must try to figure out what a block of code > does, then that block of code calls existing wine functions that you've > never seen before in your life. So then you have to trace that back to find > out what the already implemented function does, and look through the code to > it, because there is no documentation for it either, then it calls another > function, so go ahead and trace back through the code for it too to find out And how that would be different from reading comments to each function? Or do you expect to have description of what each function with variation of the any other function can do? Vitaliy
RE: My 1.0 wish list
I guess it's not installing after all, the installer menu says install completed, but the log code says differently. fixme:msi:ACTION_HandleStandardAction unhandled standard action L"RemoveFolders"err:cabinet:FDICopy PFDI_OPEN returned zero for c:\Program Files\Common Files\Java\Update\Base Images\jdk1.5.0.b64\patch-jdk1.5.0_07.b03\\jo15.cab. err:msi:extract_cabinet_file FDICopy failed err:msi:ACTION_InstallFiles Unable to ready media That message looks eerily familiar, seems the same bug that plagues the America's Army installer also plagues that of J2SE. Caused by the query in ready_media_for_file in files.c returning the wrong results from the query "SELECT * FROM Media WHERE LastSequence >= file-Sequence ORDER BY LastSequence". Fix this bug and we'll kill 2 birds with one stone. From: "EA Durbin" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: wine-devel@winehq.org Subject: RE: My 1.0 wish list Date: Sat, 03 Jun 2006 00:54:31 -0500 I just tested J2SE update 7 offline installation from sun and it installed with no problems. Are we trying to install netbeans or something too that's crashing? I'm using the latest cvs version of wine. From: "Dan Kegel" <[EMAIL PROTECTED]> To: wine-devel Subject: My 1.0 wish list Date: Fri, 2 Jun 2006 21:55:43 -0700 ... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
RE: My 1.0 wish list
I just tested J2SE update 7 offline installation from sun and it installed with no problems. Are we trying to install netbeans or something too that's crashing? I'm using the latest cvs version of wine. From: "Dan Kegel" <[EMAIL PROTECTED]> To: wine-devel Subject: My 1.0 wish list Date: Fri, 2 Jun 2006 21:55:43 -0700 ... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
Re: How are we doing?
"Jeremy White" <[EMAIL PROTECTED]> wrote: grep Bestefich documentation/ChangeLog.ALPHA | wc -l 0 grep Bestefich ChangeLog | wc -l 0 And this is exactly the kind of comment and attitude that pushes people away from being Wine developers. This was a thread that asked the question: What would get more developers interested in Wine? A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented." Dismissing their input because they've never contributed code is exactly the wrong approach; if we're talking about getting new developers, then their impressions are particularly valuable. I'd suggest to return and carefully reread the whole paragraph I've quoted and replied to. It has nothing to do with a constructive talk about commenting the code, instead it's full of insults and hits. I'm not even talking about using the word "foreigners" for the contributors to the open source international project. I'd call the foreigners that kind of people who sends messages like the one I replied to, clearly that people absolutely don't understand what they are talking about. I apologize for my harsh wording, but I just can't stay aside when I see accusations like that one. When people are interested to contribute code they ask *technical* questions. -- Dmitry.
RE: My 1.0 wish list
What is broken in MingW installer?, Upon testing I was able to install 5.0.2 Mingw just fine, and selected all of the components and it installed fine. I also was able to install gdb, as the bug suggests you're not able. From: "Dan Kegel" <[EMAIL PROTECTED]> To: wine-devel Subject: My 1.0 wish list Date: Fri, 2 Jun 2006 21:55:43 -0700 ... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
RE: My 1.0 wish list
I can help debug some of these, and maybe contribute to the code/test cases. I haven't coded much in C in the last few years, I took some in college, but I've never used it yet in my career path, but I'm working on refreshing my memory, and working on trying to understand the most commonly used functions called in wine. From: "Dan Kegel" <[EMAIL PROTECTED]> To: wine-devel Subject: My 1.0 wish list Date: Fri, 2 Jun 2006 21:55:43 -0700 ... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
My 1.0 wish list
... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
Friday, June 2, 2006, 9:33:30 PM, Dan Kegel wrote: > On 6/2/06, Dan Kegel <[EMAIL PROTECTED]> wrote: >> > You need to have a thread waiting one way or another, since you need >> > to perform operations on the client side that require a thread >> > context. No, it's not an easy problem to solve, that's why it has not >> > been done yet... >> >> Are you willing to accept a patch which makes some common use >> cases work well, but does not address others? > Oh, heck, I guess we can keep thinking about it even if you do insist > on a full-on solution. > How 'bout we also implement remote thread creation, and create > a temporary service thread to service a remote memory allocation request? > That would give the thread context you say is required. > - Dan That would be wonderful actually. It seems that some new stile copy-protection technics include use of injected threads. Also that would help properly implementing braking any process for debugging. So the real use of this would be to support all sorts of debuggers - they all use all these functions on other processes. Vitaliy
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
On 6/2/06, Dan Kegel <[EMAIL PROTECTED]> wrote: > You need to have a thread waiting one way or another, since you need > to perform operations on the client side that require a thread > context. No, it's not an easy problem to solve, that's why it has not > been done yet... Are you willing to accept a patch which makes some common use cases work well, but does not address others? Oh, heck, I guess we can keep thinking about it even if you do insist on a full-on solution. How 'bout we also implement remote thread creation, and create a temporary service thread to service a remote memory allocation request? That would give the thread context you say is required. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: How are we doing?
From the viewpoint of a new developer (Summer of Code), having a few "The purpose of this function" comments would have been / still would be very useful! It's painfully having to figure out what exactly a function does, that calls five other functions that you have to look into, which each call another cryptically named function. Also, sometimes it's not obvious why a function is called. A comment like "Call funcResetStatusVariables because the above code triggers a redraw which can break them" would save a new developer twenty minutes of "But why update them THERE?! Does my code have to do that?". --Matt
Re: To K&R or not
On 6/2/06, Aneurin Price <[EMAIL PROTECTED]> wrote: How about setting a standard that will be used in the repository, and providing the indent commands to set it that way, then indenting *every file* in the repository to that standard. Then every developer can use indent or whatever equivalent they prefer when they checkout, if they don't like the chosen style. Our coding standard is that there shall be no coding standard. As was stated before, whoever creates the file, their style is the style that should be used when anyone makes changes to that file. Concerning the automatic source indenter, I know I would be peeved if i checked my code back out and it was changed to a style I don't like. There are way too many different styles of coding out there, and each developer has a right to like his or her own style, and we shouldn't force one specific style on anyone. http://www.winehq.org/site/docs/winedev-guide/style-notes -- James Hawkins
Re: To K&R or not
That said, I don't care what people do, I can read both... In my perfect world though, my SCM client would convert source code to my preferred format on checkout, and to whatever universal format the repository uses on checkin. Ho hum... (Personally I hate K&R because I want to be able to see the braces line up vertically, else I find it hard to read. Of course, that's an aside since, not being a Wine developer, it's a little pointless saying my opinion; I just happen to like doing so anyway :P) Anyway, the point: How about setting a standard that will be used in the repository, and providing the indent commands to set it that way, then indenting *every file* in the repository to that standard. Then every developer can use indent or whatever equivalent they prefer when they checkout, if they don't like the chosen style. By specifying a standard used by the repository it means that submitters can reformat their patches at submission time to avoid vast amounts of no-op changes caused by different formatting styles. This could be done automatically via an aliased `cvs diff` command, or whatever. Alternatively each patch could be considered by a script (which really wouldn't have to be at all complex) which tries applying it, reformats it appropriately, generates a more appropriate patch, then unapplies it. This would make the process transparent to most developers, with the cost of more processing needing to be done at submission time - perhaps that would be unacceptable; I've no idea what kind of resources are available compared to what it would take. Okay, I don't really expect this suggestion to be taken seriously since it involves modifying every file in the repository once, and potentially every patch, but I seriously think that it's an issue worth considering. Does anybody else think that it would be a feature that might really be used if it were implemented in ?
Freetype configure checks are backward
I believe the Freetype configure checks are backward. First we check for the library being present, and only then do we check for the freetype-config problem: AC_SUBST(FREETYPELIBS,"") AC_SUBST(FREETYPEINCL,"") AC_CHECK_LIB(freetype,FT_Init_FreeType,ft_lib=yes,ft_lib=no,$X_LIBS) if test "$ft_lib" = "no" then wine_cv_msg_freetype=no else AC_CHECK_PROG(ft_devel,freetype-config,freetype-config,no) This fails to work when Freetype is installed somewhere outside of /usr/ such as /usr/local/ with /usr/local/bin in the path. freetype-config would of course know where to look for the library, but we perform the check for the library first, without taking the output of freetype-config into concern. Wouldn't it make sense to revert these two changes? Gerald
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > How about this: we combine the original sychronous approach > with the small preallocated cache as a fallback for when > no threads are waiting? You need to have a thread waiting one way or another, since you need to perform operations on the client side that require a thread context. No, it's not an easy problem to solve, that's why it has not been done yet... Are you willing to accept a patch which makes some common use cases work well, but does not address others? If so, we can continue. Otherwise we'll have to wash our hands and walk away screaming. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: How are we doing?
> "Michael" == Michael Stefaniuc <[EMAIL PROTECTED]> writes: Michael> P.S.: Let the flame war begin. ;) Isn't it already raginh ;-) -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
"Dan Kegel" <[EMAIL PROTECTED]> writes: > How about this: we combine the original sychronous approach > with the small preallocated cache as a fallback for when > no threads are waiting? You need to have a thread waiting one way or another, since you need to perform operations on the client side that require a thread context. No, it's not an easy problem to solve, that's why it has not been done yet... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine 1.0 Tasks
Lionel Ulmer <[EMAIL PROTECTED]> writes: > But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X > window would be the easiest idea to investigate (because it would not only > fixes this issue but also the mutiple windows with multiple pixel formats > problem that the former 'extension' solution does not). That can't work, unless you want to go back to the old window management implementation; but then you'll have to volunteer to solve all the painting bugs yourself, I'm not doing this a second time ;-) -- Alexandre Julliard [EMAIL PROTECTED]
Re: Shell integration idea
Alexandre Julliard wrote: I think using COM for that sort of thing is overkill. If we want to allow multiple implementations then using a structure with callback functions is probably the easiest way. If we are using structures with callback functions then why not to make it COM interfaces - IMHO the overhead of adding the QueryInterface, AddRef, Release is relatively small and we obtain structures with which probably most of developpers are more of less familliar. Besides, you most likely want to put all of that in the explorer process, and communicate with shell32 using the same protocol that Microsoft is using, like we do already for the system tray. For the Trash I don't know if there is any protocol. I've placed a DELETE security audit on a file and it was the application trashing the file that triggered it - so it seems Windows also doesn't need to communicate with the explorer. For things like file associations, to maintain compatibility we will need to keep the settings in the registry. What we can do is to mirror the changes to the Linux database. That's a feature that is not present in Windows so we can choose a protocol. Mikolaj Zalewski
Re: Missing LeaveCriticalSection on error paths (found by Smatch).
Michael Stefaniuc wrote:
> can somebody more familiar with this code confirm that on the error
> paths the CriticalSection should be released? I'm not sure about it as
> the function is supposed to keep the lock held when exiting without
> error; there is a d3ddevice_unlock_update() function that releases the
> lock.
Asked Lionel Ulmer on irc and the patch is correct. But according to
Stefan Dösinger that code will be replaced by his code "in the next
couple of days".
bye
michael
> ---
>
> dlls/ddraw/device_opengl.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> dd0b9b20d26984ae408c1a7727323a08d44e0d95
> diff --git a/dlls/ddraw/device_opengl.c b/dlls/ddraw/device_opengl.c
> index d19996e..4c663a6 100644
> --- a/dlls/ddraw/device_opengl.c
> +++ b/dlls/ddraw/device_opengl.c
> @@ -3775,10 +3775,12 @@ static void d3ddevice_lock_update(IDirec
> buffer_color = GL_BGRA;
> } else {
> ERR(" unsupported pixel format at device locking.\n");
> +LeaveCriticalSection(&(d3d_dev->crit));
> return;
> }
> } else {
> ERR(" unsupported pixel format at device locking - alpha on frame
> buffer.\n");
> +LeaveCriticalSection(&(d3d_dev->crit));
> return;
> }
>
>
>
>
>
>
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Re: Re: Wine 1.0 Tasks
Lionel, Where can I learn more about ohsix's idea (i.e. thread in which mail list)? Thanks, W. From: Lionel Ulmer <[EMAIL PROTECTED]> To: Dan Kegel <[EMAIL PROTECTED]> CC: wine-devel@winehq.org, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>,[EMAIL PROTECTED] Subject: Re: Re: Wine 1.0 Tasks Date: Fri, 2 Jun 2006 21:27:53 +0200 But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X window would be the easiest idea to investigate (because it would not only fixes this issue but also the mutiple windows with multiple pixel formats problem that the former 'extension' solution does not). Lionel (in 'not even time to read wine-devel' mode :-) ) -- Lionel Ulmer - http://www.bbrox.org/ _ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > OK, new plan: how about we preallocate a memory > area just big enough for the common case, with the > structures all set up, and let the server hand it > out to the first process to ask for it? I don't think > it needs to be very big. Well, that may work for your specific problem, but it's clearly not an acceptable general solution. How about this: we combine the original sychronous approach with the small preallocated cache as a fallback for when no threads are waiting? If that's not good enough, what (short of a Linux kernel module) might do? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Re: Wine 1.0 Tasks
On Tue, May 30, 2006 at 05:32:26PM -0700, Dan Kegel wrote: > On 5/30/06, Scott Ritchie <[EMAIL PROTECTED]> wrote: > > > It might be, but the heavy hitters I know of who have taken a look at > > > it in detail have concluded that an X change really is needed.] > > > > Is this really a problem? Another version of X is due out in about 4 > > months (probably the earliest we could possibly see Wine 1.0), so why > > can't we just help write an X extension to tackle the bug? > > Not really a problem. It'll just take some time to trickle out to the world. > We may also have to get Nvidia and ATI on board so they can implement > the extension in their drivers. And for it to be taken, I guess we would need to not only write the extension, but a 'reference implementation' (I would guess in DRI / Mesa) and get it approved by the FD.o people. But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X window would be the easiest idea to investigate (because it would not only fixes this issue but also the mutiple windows with multiple pixel formats problem that the former 'extension' solution does not). Lionel (in 'not even time to read wine-devel' mode :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Re: How are we doing?
EA Durbin wrote: >> K&R style brack placements > > > was what i was referring to when I commented about coding style. They > are an eyesore and make things difficult to read. Oh, NO NO NO. K&R style IS the one and only true pure C style. As mutch as GNU did good work for OSS they did very wrong with the GNU coding standard. Especialy with the placement of the braces. Just read the Chapter 3 "Placing Braces" from the Linux Kernel CodingStyle. I quote: "Also, note that this brace-placement also minimizes the number of empty (or almost empty) lines, without any loss of readability. Thus, as the supply of new-lines on your screen is not a renewable resource (think 25-line terminal screens here), you have more empty lines to put comments on." ^^^ See more place for comments and we all agreed that more comments are good! bye michael P.S.: Let the flame war begin. ;) > >> A number of people said: >> "The code is too hard to read because it's >> completely unmovitated and uncommented." -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: How are we doing? (documentation + regression tests)
Am Freitag, den 02.06.2006, 08:03 -0500 schrieb Jeremy White: > But there are plenty of places in Wine where the code does > something screwball or out of the ordinary (hell, the API > itself is screwball), and those places deserve more comments. IMHO, more comment's help to teach someone, who read the code, what a Function does. Many of my Patches add the missing WineAPI - Documentation, but the overall API Documentation - Status is still to low. We can of course add the same Type of documentation for internal Functions. Example: http://source.winehq.org/source/dlls/winspool.drv/info.c#L214 Another big Place to teach someone what a Function does, are the regression tests. We are missing a lot of tests. Example: After a comment by Alexandre about my recent patch, i read again our WineAPI-Guide and MSDN. Both document's say the same, but our implementation is different. The affected Function is called only 3 times in our regression tests (WideCharToMultiByte). -- By By ... ... Detlef
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
"Dan Kegel" <[EMAIL PROTECTED]> writes: > OK, new plan: how about we preallocate a memory > area just big enough for the common case, with the > structures all set up, and let the server hand it > out to the first process to ask for it? I don't think > it needs to be very big. Well, that may work for your specific problem, but it's clearly not an acceptable general solution. -- Alexandre Julliard [EMAIL PROTECTED]
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > Why isn't a call to mmap enough? You need to build the proper structures on the client side, just like a normal VirtualAlloc would, otherwise the process won't know about that memory area. OK, new plan: how about we preallocate a memory area just big enough for the common case, with the structures all set up, and let the server hand it out to the first process to ask for it? I don't think it needs to be very big. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
"Dan Kegel" <[EMAIL PROTECTED]> writes: > On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: >> The problem here is that you don't control at what point you interrupt >> the process, so you can't do anything in it except system calls, and >> that won't be enough. > > Why isn't a call to mmap enough? You need to build the proper structures on the client side, just like a normal VirtualAlloc would, otherwise the process won't know about that memory area. -- Alexandre Julliard [EMAIL PROTECTED]
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: The problem here is that you don't control at what point you interrupt the process, so you can't do anything in it except system calls, and that won't be enough. Why isn't a call to mmap enough? (We're trying to support techniques like the one documented in http://msdn.microsoft.com/library/en-us/dnwinforms/html/autowforms.asp for retrieving control names and captions from another process, if that helps.) Another problem is that you make the server wait on the client to execute the code, and that's a big no-no, the server can't trust the client. Fine, he can move the wait to the client, that's no problem. - Dan
Re: How are we doing?
--- EA Durbin <[EMAIL PROTECTED]> wrote: > If I use K & R style, or not enough white space, > or don't align things perfectly at work my boss will kindly print off a > copy of the companies acceptable coding standards policy and bring it > over. Ah, so it's the lack of a defined style guideline that's the problem? That got me too back in the beginning. The Official Wine Code Style is something like this: 1. New file: whatever the author wants 2. Existing file: whatever others did This takes some getting used to, and since 2. isn't strictly enforced, we sometimes end up with colliding styles. Only one time that I remember did we manage to sneak in a bunch of formatting changes (into shell32, which was a real mess of conflicting styles.) I guess that could be documented better, though a quick google turns up statements to that effect: http://www.kerneltraffic.org/wine/wn20010305_85.html#4 http://www.winehq.org/pipermail/wine-devel/2004-July/028483.html It's also in the developer guide, though a bit buried: http://winehq.org/site/docs/winedev-guide/style-notes The fact that I couldn't find the darn thing quickly is a problem ;) --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
[EMAIL PROTECTED] writes: > I ran across the need to do memory allocations across processes and came upon > Alexander Yaworsky's patch at > http://www.winehq.org/pipermail/wine-devel/2004-September/029953.html and took > a different approach. Instead of waiting for the target process to check a fd, > I changed the implementation to use ptrace to interrupt the target process and > execute code in kernel32 that does an mmap/munmap. The problem here is that you don't control at what point you interrupt the process, so you can't do anything in it except system calls, and that won't be enough. Another problem is that you make the server wait on the client to execute the code, and that's a big no-no, the server can't trust the client. -- Alexandre Julliard [EMAIL PROTECTED]
Re: test case for MSI problem in America's Army installer
I think you can just compile and run it with visual C++ as a standalone app,
with the right commandline options to the compiler. Let's see: try
the instructions here:
http://www.winehq.com/hypermail/wine-devel/2005/05/0865.html
You can also build with the wine build system and then
run the executable with a single commandline option
giving the name of the test to run. Better ask on wine-devel, I have to run.
On 6/2/06, EA Durbin <[EMAIL PROTECTED]> wrote:
How does one use the test application in the msi/tests folder?
I know you run it with wine, but without looking through all of the code in
the application to determine this could you maybe advise me what it expects
for arguments, or how to work with it?
Do you pass it an misdatabase, and a DB argument, or how does this utility
work?
I don't usually hack in C, but im somewhat capable. I could write a mean
Hello World Application back in college. My day usually consists of parsing
data with PERL, but that doesn't mean I can't pick up C again.
I'd appreciate it if you focused some energy on it, but I would also like to
know how it works so I can contribute in the future.
>From: "Dan Kegel" <[EMAIL PROTECTED]>
>To: wine-devel
>Subject: re: test case for MSI problem in America's Army installer
>Date: Fri, 2 Jun 2006 07:06:30 -0700
>
>Mike M. wrote:
[America's Army install crashes, see
http://bugs.winehq.org/show_bug.cgi?id=5139 ]
>>>
>>>This is as close as I will be able to come to including a test case, as
>>>this is how I obtained my results.
>>
>>If you want me to fix the problem, please submit a regression test to
>>wine-patches with a todo_wine{} around the code that doesn't work.
>
>If that's too hard for EA (he admits he's not a C hacker), maybe
>I can focus some energy on it...
>- Dan
>
>
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Shell integration idea
Mikołaj Zalewski <[EMAIL PROTECTED]> writes: > The main idea is not to hard-code one implementation of things like > the Trash into shell32 - not everything is standardized by the > freedesktop and even if it would this might not work on other systems > like MacOS X. We should allow for many implementations. The correct > one is loaded depending on a registry settings (so that a winecfg > entry can be added). My implementation uses COM objects as it's > standard dlls provides support for such tasks. Currently there is one > interface (IWineShellIntegration) that acts as a factory for > specialized objects. That could also be implemented using COM > Aggregation - when we do that we could use QueryInterface instead of > GetIntegrationObejct. I think using COM for that sort of thing is overkill. Besides, you most likely want to put all of that in the explorer process, and communicate with shell32 using the same protocol that Microsoft is using, like we do already for the system tray. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winedbg: newbie question (sorry...)
Molle Bestefich wrote: Hello Carsten Niehaus ([EMAIL PROTECTED]) over on wine-users gets a page fault when he tries to print with this app: http://www.learn-line.nrw.de/angebote/gefahrstoffdb/Gefahrstoffe.zip He's posted a backtrace: fixme:commdlg:PRINTDLG_SetUpPrinterListComboA Can't find '(null)' in printer list so trying to find default wine: Unhandled page fault on write access to 0x002e at address 0x7f6a2540 (thread 0009), starting debugger... Backtrace: =>1 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32 (0x7f6a2540) 2 0x7f6a2fb6 in comdlg32 (+0x32fb6) (0x7f6a2fb6) [snip!] 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32: movw %ax,0x2e(%edx) I'm slightly cli-debugger-clueless, so could one of you guys please tell me how to convert this: PRINTDLG_WMCommandA+0x619 into a proper line number reference to the source file? If you don't strip comdlg32 then winedbg will pick up the debug information from the .dll.so and give you a filename and line number. So tell the user to install a build with debug information. -- Rob Shearman
Re: How are we doing?
I'm just nitpicky I guess. If I use K & R style, or not enough white space, or don't align things perfectly at work my boss will kindly print off a copy of the companies acceptable coding standards policy and bring it over. I guess I'm just used to having things that way, and the shifting coding style and lack of comments in places in wine makes the learning curve steeper than it needs to be for beginning wine developers. Just my 2 cents as a beginning wine developer. From: Juan Lang <[EMAIL PROTECTED]> To: EA Durbin <[EMAIL PROTECTED]> CC: wine-devel@winehq.org Subject: Re: How are we doing? Date: Fri, 2 Jun 2006 10:56:15 -0700 (PDT) > Especially the code that is responded to as , I know it's a mess to > look at, but I didn't write it. Can you give us examples? Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll. There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along. For example, SHFileOperation was a complete mess until James fixed it up. Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions. I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep. Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/ --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Shell integration idea
I think the general approach is good. The way you handle the built in implementation seems odd to me. I think setting the registry key to make the freedesktop.org version as the default would be good enough. If we don't have built-in trash etc. objects then when we add a new object we will require all the implementations have it, with no backward compatibility. However this should not be a big problem as the freedesktop.org implementation can be kept up-to-date with shell32 and the other implementation can fallback to it if they don't support a specific object. I'm not convinced we need IWineShellIntegration. I think it would be cleaner to directly create an IWineTrash object. If we integrate more closely with the desktop environments we may need to have one central object that will know that e.g. KDE 3.4 uses the freedesktop.org Trash but KDE 3.3 has it's own Trash implementation. If we read the Trash CLSID from the registry such an implementation would require creating proxy classes or hacks in the class factory. Also by storing only one CLSID we don't have a problem which implementation to use if a new kind of objects is introduced. Of course when we use COM aggregation instead of a factory pattern we will have all the interfaces visible under one CLSID so we will be able to construct a IWineTrash directly with the main object hidden behind the scene. Mikolaj Zalewski
winedbg: newbie question (sorry...)
Hello Carsten Niehaus ([EMAIL PROTECTED]) over on wine-users gets a page fault when he tries to print with this app: http://www.learn-line.nrw.de/angebote/gefahrstoffdb/Gefahrstoffe.zip He's posted a backtrace: fixme:commdlg:PRINTDLG_SetUpPrinterListComboA Can't find '(null)' in printer list so trying to find default wine: Unhandled page fault on write access to 0x002e at address 0x7f6a2540 (thread 0009), starting debugger... Backtrace: =>1 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32 (0x7f6a2540) 2 0x7f6a2fb6 in comdlg32 (+0x32fb6) (0x7f6a2fb6) [snip!] 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32: movw %ax,0x2e(%edx) I'm slightly cli-debugger-clueless, so could one of you guys please tell me how to convert this: PRINTDLG_WMCommandA+0x619 into a proper line number reference to the source file?
Re: How are we doing?
> Especially the code that is responded to as , I know it's a mess to > look at, but I didn't write it. Can you give us examples? Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll. There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along. For example, SHFileOperation was a complete mess until James fixed it up. Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions. I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep. Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/ --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
To K&R or not
EA Durbin wrote: >K&R style brack placements They are an eyesore and make things difficult to read. Highly subjective. I think K&R has distinct advantages, namely it unites the scope begin token with the relevant control statement. For me, this makes code easier and faster to read, since I can follow the indentation and arrive immediately at the relevant control statement. Also I think that K&R is nice in that it saves screen real estate, which again for me makes code easier to read because I can see more of it at once. I personally consider non-K&R style an eyesore because of this. CMIIW, but the only thing that non-K&R has going for it is that you can visually make out whether you've made the correct number of opening versus closing braces. I don't think that's much of an advantage, especially considering that any modern source code editor will highlight the starting brace or relevant control statement for you. That said, I don't care what people do, I can read both... In my perfect world though, my SCM client would convert source code to my preferred format on checkout, and to whatever universal format the repository uses on checkin. Ho hum...
Re: [Darwine] RFC - wine-macos mailing list
That being the case, why not clear up the name? Call the list [EMAIL PROTECTED] This makes clear it is for the ppc version, not the Intel version. The currently proposed name makes me think that the project refers to both Intel and PPC. Dave --- Jim White <[EMAIL PROTECTED]> wrote: > Joshua Root wrote: > > > C.W. Betts wrote: > > > >>If you could have it so that wine-macos is > instantly sent to > >>darwine-devel, and vice-versa. > > > > That seems rather redundant. Might as well just > migrate all the > > darwine-devel subscribers over to wine-macos and > discontinue the former, > > rather than have two lists with the same content. > > I'll repeat myself, because the message still is > getting missed. > > The goal of the Darwine Project is to run Wine on > *PowerPC* Mac OS X. > > We know that is definitely *not* the goal of WineHQ > because Wine Is Not > an Emulator. > > The point of this wine-macos @ WineHQ discussion is > because Alexandre & > Jeremy want Wine development work for *Intel* Mac OS > X to be focused at > wine-devel, and I want darwine-devel to focus on > Wine + QEMU development > work for *PowerPC* Mac OS X. > > Jim White > > > > ___ > Darwine-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/darwine-devel > -- David Bialac [EMAIL PROTECTED]
Ecco Pro hangs when accessing "2nd level" dialogs
I'm a heavy user of Ecco Pro on Windows, and am trying to port myself as completely as possible to Linux (Ubuntu currently). Wine does a good job of supporting most of Ecco's features, but there are a couple of places (unfortunately important ones) where it hangs up tight. I've just submitted Bug #5335 about this problem. I'm a long-time programmer with good (if rusty) knowledge of C/C++ and Unix, just getting up to speed on Linux. I'm at the point where I might be willing to tackle this myself, if the learning curve isn't too steep. I'm posting this to ask for guidance on the best way to proceed. At least, if there's a good way to get more information on the hangup, I'm definitely willing to add to the bug report. Thanks for any good words, -- Don Dwiggins [EMAIL PROTECTED] "The truth will make you free, but first it will make you miserable" -- Tom DeMarco
Re: How are we doing?
K&R style brack placements was what i was referring to when I commented about coding style. They are an eyesore and make things difficult to read. A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented." Especially the code that is responded to as , I know it's a mess to look at, but I didn't write it. These portions of code could use a comment or two to explain what is going on, not every line, but explain what happens in that chunk of code. From: Jeremy White <[EMAIL PROTECTED]> To: Dmitry Timoshkov <[EMAIL PROTECTED]> CC: Mike McCormack <[EMAIL PROTECTED]>, wine-devel@winehq.org Subject: Re: How are we doing? Date: Fri, 02 Jun 2006 11:24:06 -0500 > grep Bestefich documentation/ChangeLog.ALPHA | wc -l > 0 > > grep Bestefich ChangeLog | wc -l > 0 > And this is exactly the kind of comment and attitude that pushes people away from being Wine developers. This was a thread that asked the question: What would get more developers interested in Wine? A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented." Dismissing their input because they've never contributed code is exactly the wrong approach; if we're talking about getting new developers, then their impressions are particularly valuable. With that said, and all joking aside, I have never seen Alexandre reject a patch with comments or strip a single comment out. To get material comments in the code would require the imposition of a kind of standard that is far beyond anything we could reasonably expect. Heck, we can't even standardize indenting or do away with those abominable K&R style brack placements . I just hope that the bulk of the anti comment pogrom is mostly posturing and jest (which is what I suspect), and that folks do try to comment tricky and inobvious bits. Cheers, Jeremy
Re: How are we doing?
> grep Bestefich documentation/ChangeLog.ALPHA | wc -l > 0 > > grep Bestefich ChangeLog | wc -l > 0 > And this is exactly the kind of comment and attitude that pushes people away from being Wine developers. This was a thread that asked the question: What would get more developers interested in Wine? A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented." Dismissing their input because they've never contributed code is exactly the wrong approach; if we're talking about getting new developers, then their impressions are particularly valuable. With that said, and all joking aside, I have never seen Alexandre reject a patch with comments or strip a single comment out. To get material comments in the code would require the imposition of a kind of standard that is far beyond anything we could reasonably expect. Heck, we can't even standardize indenting or do away with those abominable K&R style brack placements . I just hope that the bulk of the anti comment pogrom is mostly posturing and jest (which is what I suspect), and that folks do try to comment tricky and inobvious bits. Cheers, Jeremy
Re: Shell integration idea
I think the general approach is good. The way you handle the built in implementation seems odd to me. I think setting the registry key to make the freedesktop.org version as the default would be good enough. I'm not convinced we need IWineShellIntegration. I think it would be cleaner to directly create an IWineTrash object. /Ulrich On Thu, Jun 01, 2006 at 10:12:12PM +0200, Miko??aj Zalewski wrote: > As a SoC project I'll try to improve the integration of wine with the > Unix shells. My first step will be to implement the freedesktop.org > Trash. I've written some code that doesn't add any new features but > shows how I want to add it. I'd like to know if this is a good design? > The main idea is not to hard-code one implementation of things like > the Trash into shell32 - not everything is standardized by the > freedesktop and even if it would this might not work on other systems > like MacOS X. We should allow for many implementations. The correct one > is loaded depending on a registry settings (so that a winecfg entry can > be added). My implementation uses COM objects as it's standard dlls > provides support for such tasks. Currently there is one interface > (IWineShellIntegration) that acts as a factory for specialized objects. > That could also be implemented using COM Aggregation - when we do that > we could use QueryInterface instead of GetIntegrationObejct. > Some COM objects can run in the address space of the calling process - > e.g. the trash can be implemented like that. For others it would be a > waist of resources (e.g. there is no need for every process to watch is > the file associations have changed) - it's enough to load them only > once. The explorer seems to be a good candidate to create such objects. > In the attached patch there is one specialized interface - the > IWineTrash. The SHELL_DeleteFile[AW] is patched to use it - it shows a > different icon if the file can be trashed (these are not the correct > icons as wine's shell32 uses a message box instead of a special dialog) > and calls the trash method then. Currently there is only one built-in > trash that can't trash anything. (note that SHELL_DeleteFile is called > in the folders that are decendents of My Computer. If choose delete on a > file that is a decendent of the '/', it will be deleted without a warning). > > Mikolaj Zalewski >
Re: comctl32: Fix loading string from resources (take 2)
"Thomas Weidenmueller" <[EMAIL PROTECTED]> wrote: LoadString() cannot be used to measure the length of a string resource. It will not return the length of the string if no buffer is provided, instead it will return 0! This patch fixes the broken property sheet code. It would be appropriate to provide a test case showing correct LoadString behaviour and fix LoadString in Wine if it confirms the statement above since Wine clearly returns the size of the string resource if the passed buffer is NULL. -- Dmitry.
Re: How are we doing?
Mike McCormack wrote: Add all the great comments you like, but you still actually have to read the code and understand it to figure out how to fix it. Often the goal is not to fix it, the goal is to understand it in order to fix something else. So, IMO, you're better off striving for the Utopian goal of well structured code that trying to make everybody understand what your reason or intention was when you were writing the code, as in the end you must understand the code and all it's subtleties anyway. As per above, often you're trying to figure out the big picture, not fix the particular function you're looking at. Increasing the speed of that process would be truly great.
Re: Wine VM86 exception handling bug?
On 6/2/06, Andrey Turkin <[EMAIL PROTECTED]> wrote: > How about writing a conformance test that demonstrates > the problem? I would be happy to do it. Unfortunely, I cannot imagine how to implement such test: 1) DOS code needed - it would need binary or some sort of source to be compiled prior to test or some temporary file with a binary You can embed a trivial DOS executable as data in the .c file 2) method to catch failure inside of ntdll I'm sure you can work something out. At the very least, you can check that the DOS executable runs ok. It is just not seems to be possible to do all this inside of some .c file. Hmm, is there any test for kernel or winedos at all? If not, there sure ought to be... - Dan
Re: Wine 1.0 tasks: installers
Thats a good one, since its on the Top 25 of the App DB, ranked #2 i believe, and freely available. The sudden of influx of people testing Americas Army in wine came from the America's Army community, after America's Army announced they would no longer support a linux port for the client, which is what brought me to wine. There's much discussion about wine on the America's Army forums. From: "Dan Kegel" <[EMAIL PROTECTED]> To: wine-devel Subject: Re: Wine 1.0 tasks: installers Date: Fri, 2 Jun 2006 07:35:36 -0700 On 6/2/06, Dan Kegel <[EMAIL PROTECTED]> wrote: http://bugs.winehq.org/show_bug.cgi?id=3590 ActiveState python msi (see 5237?) http://bugs.winehq.org/show_bug.cgi?id=3972 .NET framework 2.0 http://bugs.winehq.org/show_bug.cgi?id=4227 QuickTest Pro http://bugs.winehq.org/show_bug.cgi?id=4280 J2SE 1.5 http://bugs.winehq.org/show_bug.cgi?id=4492 MinGW installer stalls http://bugs.winehq.org/show_bug.cgi?id=4569 Oregon Trail 5 wants DX8 http://bugs.winehq.org/show_bug.cgi?id=4802 Oracle client library (munich) http://bugs.winehq.org/show_bug.cgi?id=4700 spss demo (munich) http://bugs.winehq.org/show_bug.cgi?id=4860 java plugin http://bugs.winehq.org/show_bug.cgi?id=5296 Kidspiration install window hidden? http://bugs.winehq.org/show_bug.cgi?id=5237 wsh (and ActiveState perl msi) http://bugs.winehq.org/show_bug.cgi?id=5275 google earth http://bugs.winehq.org/show_bug.cgi?id=5325 art2kmin.exe (munich, UK EPBD-NCM) http://bugs.winehq.org/show_bug.cgi?id=5322 VB6 / VC++6 installers fail early Oh, I forgot one: http://bugs.winehq.org/show_bug.cgi?id=5139 America's Army msi bug - Dan
Re: How are we doing?
"Molle Bestefich" <[EMAIL PROTECTED]> wrote: Teaching people to write good comments is infinitely easier - it's a simple case of banging 'em on the head and forcing them to write a comment every time they've done a piece of code that they know required cunning skill for whatever reason. You may need to perfect the english phrasing from some of the foreigners around here once they learn to actually write the comments, but that's a minor nit. Teaching people to write good comments is definitely much easier than writing real code. grep McCormack documentation/ChangeLog.ALPHA | wc -l 1084 grep McCormack ChangeLog | wc -l 220 grep Bestefich documentation/ChangeLog.ALPHA | wc -l 0 grep Bestefich ChangeLog | wc -l 0 -- Dmitry.
Re: RFC - device notifications idea
Damjan Jovanovic wrote: I was disappointed to see that "dynamic drive configuration" (http://www.winehq.org/?issue=313#Dynamic%20Drive%20Configuration) amounts to a few HAL functions in wine's explorer. Windows has been using device notifications for at least 11 years now (since Windows 95), and neither wine nor ReactOS have even begun this feature. I would be interested in implementing it by using dbus/HAL in wineserver, and translating HAL device notifications into equivalent WM_DEVICECHANGE messages which then get broadcast to all windows. WM_DEVICECHANGE is sent from explorer, but only for new drives. What's wrong with doing this in explorer still, but expanding the number of devices that are notified? Is any work being done in this area? If not, would this work? Are long-running functions requiring I/O (hal_device_get_property_...()) allowed in wineserver (which seems to be event-driven)? Any other comments? Absolutely not. Any long-running functions will cause all of the user's winelib applications to freeze until the server unblocks. Also, note that there is an exception handler in explorer around some hal functions because they assert on some platforms. You won't be able to port that to wineserver and it would be really bad news if an assert fired there. -- Rob Shearman
Re: Wine VM86 exception handling bug?
Dan Kegel wrote: Andrey wrote: My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 would restore vm86 registers correctly. I think i know what is the problem; however, I lack experience to fix it myself :) I need help; any hints would be appreciated. How about writing a conformance test that demonstrates the problem? That will help focus discussion and energy on it, and keep it from coming back. Thanks! - Dan I would be happy to do it. Unfortunely, I cannot imagine how to implement such test: 1) DOS code needed - it would need binary or some sort of source to be compiled prior to test or some temporary file with a binary 2) method to catch failure inside of ntdll 3) maybe something else... It is just not seems to be possible to do all this inside of some .c file. Hmm, is there any test for kernel or winedos at all?
Re: Wine 1.0 tasks: installers
On 6/2/06, Dan Kegel <[EMAIL PROTECTED]> wrote: http://bugs.winehq.org/show_bug.cgi?id=3590 ActiveState python msi (see 5237?) http://bugs.winehq.org/show_bug.cgi?id=3972 .NET framework 2.0 http://bugs.winehq.org/show_bug.cgi?id=4227 QuickTest Pro http://bugs.winehq.org/show_bug.cgi?id=4280 J2SE 1.5 http://bugs.winehq.org/show_bug.cgi?id=4492 MinGW installer stalls http://bugs.winehq.org/show_bug.cgi?id=4569 Oregon Trail 5 wants DX8 http://bugs.winehq.org/show_bug.cgi?id=4802 Oracle client library (munich) http://bugs.winehq.org/show_bug.cgi?id=4700 spss demo (munich) http://bugs.winehq.org/show_bug.cgi?id=4860 java plugin http://bugs.winehq.org/show_bug.cgi?id=5296 Kidspiration install window hidden? http://bugs.winehq.org/show_bug.cgi?id=5237 wsh (and ActiveState perl msi) http://bugs.winehq.org/show_bug.cgi?id=5275 google earth http://bugs.winehq.org/show_bug.cgi?id=5325 art2kmin.exe (munich, UK EPBD-NCM) http://bugs.winehq.org/show_bug.cgi?id=5322 VB6 / VC++6 installers fail early Oh, I forgot one: http://bugs.winehq.org/show_bug.cgi?id=5139 America's Army msi bug - Dan
re: Wine VM86 exception handling bug?
Andrey wrote: My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 would restore vm86 registers correctly. I think i know what is the problem; however, I lack experience to fix it myself :) I need help; any hints would be appreciated. How about writing a conformance test that demonstrates the problem? That will help focus discussion and energy on it, and keep it from coming back. Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Wine 1.0 tasks: installers
James Hawkins and I think we should come up with a list of installers that need to run before we release Wine 1.0. Looking at http://www.winehq.org/pipermail/wine-devel/2006-March/045634.html and http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=install&product=Wine&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=download&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED I made a list biased towards freely downloadable apps, programming tools, things Munich wants, stuff that has been passionately discussed of late (e.g. America's Army), educational apps, and anything that smacks of long-unfinished business. Here's what I ended up with: http://bugs.winehq.org/show_bug.cgi?id=3590 ActiveState python msi (see 5237?) http://bugs.winehq.org/show_bug.cgi?id=3972 .NET framework 2.0 http://bugs.winehq.org/show_bug.cgi?id=4227 QuickTest Pro http://bugs.winehq.org/show_bug.cgi?id=4280 J2SE 1.5 http://bugs.winehq.org/show_bug.cgi?id=4492 MinGW installer stalls http://bugs.winehq.org/show_bug.cgi?id=4569 Oregon Trail 5 wants DX8 http://bugs.winehq.org/show_bug.cgi?id=4802 Oracle client library (munich) http://bugs.winehq.org/show_bug.cgi?id=4700 spss demo (munich) http://bugs.winehq.org/show_bug.cgi?id=4860 java plugin http://bugs.winehq.org/show_bug.cgi?id=5296 Kidspiration install window hidden? http://bugs.winehq.org/show_bug.cgi?id=5237 wsh (and ActiveState perl msi) http://bugs.winehq.org/show_bug.cgi?id=5275 google earth http://bugs.winehq.org/show_bug.cgi?id=5325 art2kmin.exe (munich, UK EPBD-NCM) http://bugs.winehq.org/show_bug.cgi?id=5322 VB6 / VC++6 installers fail early Some of those might already be fixed, hopefull we can just close out a couple. And a couple might be too hard for 1.0 (.net, say), it's ok to defer them to 1.1 later if we have to. Ideally we'd also have cxtest scripts for all of these installers, so Codeweavers can use them to validate new releases. How's that sound? - Dan
Re: RFC - device notifications idea
Damjan Jovanovic <[EMAIL PROTECTED]> writes: > I was disappointed to see that "dynamic drive > configuration" > (http://www.winehq.org/?issue=313#Dynamic%20Drive%20Configuration) > amounts to a few HAL functions in wine's explorer. What's disappointing about that? > I would be interested in implementing it by using > dbus/HAL in wineserver, and translating HAL device > notifications into equivalent WM_DEVICECHANGE messages > which then get broadcast to all windows. That's exactly what the current code in explorer does... -- Alexandre Julliard [EMAIL PROTECTED]
RFC - device notifications idea
I was disappointed to see that "dynamic drive configuration" (http://www.winehq.org/?issue=313#Dynamic%20Drive%20Configuration) amounts to a few HAL functions in wine's explorer. Windows has been using device notifications for at least 11 years now (since Windows 95), and neither wine nor ReactOS have even begun this feature. I would be interested in implementing it by using dbus/HAL in wineserver, and translating HAL device notifications into equivalent WM_DEVICECHANGE messages which then get broadcast to all windows. Is any work being done in this area? If not, would this work? Are long-running functions requiring I/O (hal_device_get_property_...()) allowed in wineserver (which seems to be event-driven)? Any other comments? Thank you Damjan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: How are we doing?
Molle Bestefich wrote: Sure, that would help with understanding the call structure. But your angle of attack is utopian, since making up function names perfect enough to convey all needed information in the context of all callers, and always structuring code perfectly - especially when the code has to work exactly like Windows code - is practically impossible. And getting everybody to do it is even worse. Teaching people to write good comments is infinitely easier - it's a simple case of banging 'em on the head and forcing them to write a comment every time they've done a piece of code that they know required cunning skill for whatever reason. You may need to perfect the english phrasing from some of the foreigners around here once they learn to actually write the comments, but that's a minor nit. Teaching people to write well structured code is definitely much harder, as sloppy programmers can be easily trained to write better comments about their badly structured code. Add all the great comments you like, but you still actually have to read the code and understand it to figure out how to fix it. So, IMO, you're better off striving for the Utopian goal of well structured code that trying to make everybody understand what your reason or intention was when you were writing the code, as in the end you must understand the code and all it's subtleties anyway. Mike
Wine VM86 exception handling bug?
Hi all! I think i found a bug in VM86 exception handling (must be regression, i guess). Short Wine function flow: On privileged instruction __wine_enter_vm86 saves vm86 registers in CONTEXT and starts raise_segv_exception. raise_segv_exception routes exception to the INSTR_EmulateInstruction and then to winedos I/O emulator, then tries to use NtSetContextThread(GetCurrentThread(), CONTEXT). NtSetContextThread obviously fails because of VM86 segment values in CONTEXT. My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 would restore vm86 registers correctly. I think i know what is the problem; however, I lack experience to fix it myself :) I need help; any hints would be appreciated.
re: test case for MSI problem in America's Army installer
Mike M. wrote:
[America's Army install crashes, see
http://bugs.winehq.org/show_bug.cgi?id=5139 ]
This is as close as I will be able to come to including a test case, as
this is how I obtained my results.
If you want me to fix the problem, please submit a regression test to
wine-patches with a todo_wine{} around the code that doesn't work.
If that's too hard for EA (he admits he's not a C hacker), maybe
I can focus some energy on it...
- Dan
Re: How are we doing?
Mike McCormack wrote: If what you really want is code that's easier to understand we're better off scrapping all comments... And we can encourage safe driving by removing airbags and seatbelts, and installing big shiny sharp metal spikes on the steering wheel, and executing anybody who has an accident and survives. Code CANNOT explain "why" - there simply is no way to encode that into the source EXCEPT comments. The solution is to review code and to reject patches that contain "Fixme - this is busted" without a more detailed explanation.
ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
Hello,
I ran across the need to do memory allocations across processes and came upon
Alexander Yaworsky's patch at
http://www.winehq.org/pipermail/wine-devel/2004-September/029953.html and took
a different approach. Instead of waiting for the target process to check a fd,
I changed the implementation to use ptrace to interrupt the target process and
execute code in kernel32 that does an mmap/munmap.
This is a simple implementation that does not do a full-on call to
Nt(Allocate|Free)VirtualMemory inside the target process, mainly because the
locks taken in the allocation management code would cause deadlocks.
I've done informal testing to make sure the code doesn't crash Wine by running
applications alongside this memory-churner:
http://www.seas.ucla.edu/~kho/wine/alloc_test/alloc_test.exe
http://www.seas.ucla.edu/~kho/wine/alloc_test/alloc_test.cpp
One thought that has recently crossed my mind: Building off his framework and
putting much of the code in the server may not have been a great idea, since
the only real need for the server is to get the unix pid of the thread.
Is this a step in the right direction? Comments appreciated!
Thomas Kho
---
Index: dlls/kernel/kernel32.spec
===
RCS file: /home/wine/wine/dlls/kernel/kernel32.spec,v
retrieving revision 1.174
diff -u -r1.174 kernel32.spec
--- dlls/kernel/kernel32.spec 27 May 2006 11:36:56 - 1.174
+++ dlls/kernel/kernel32.spec 2 Jun 2006 05:43:15 -
@@ -1239,3 +1239,8 @@
# Init code
@ cdecl __wine_kernel_init()
+
+# Remote memory allocation
+# kernel32 is mapped to the same place in every process
+@ cdecl wine_remote_NtAllocateVirtualMemory(ptr long long)
+@ cdecl wine_remote_NtFreeVirtualMemory(ptr long)
Index: dlls/kernel/virtual.c
===
RCS file: /home/wine/wine/dlls/kernel/virtual.c,v
retrieving revision 1.18
diff -u -r1.18 virtual.c
--- dlls/kernel/virtual.c 23 May 2006 12:48:03 - 1.18
+++ dlls/kernel/virtual.c 2 Jun 2006 05:43:15 -
@@ -42,6 +42,7 @@
#include "wine/exception.h"
#include "excpt.h"
#include "wine/debug.h"
+#include "wine/library.h"
#include "kernel_private.h"
@@ -778,3 +779,77 @@
__ENDTRY
return FALSE;
}
+
+/***
+ * wine_remote_NtAllocateVirtualMemory (KERNEL32.@)
+ *
+ * Reentrant function that allocates memory
+ *
+ * PARAMS
+ * base [I] Desired base address
+ * size [I] Number of bytes to allocate
+ * prot [I] Memory protection flags
+ *
+ * RETURNS
+ * Success: %eax contains base address of allocated region of pages.
+ * Failure: %eax is NULL.
+ */
+void wine_remote_NtAllocateVirtualMemory( LPVOID base, DWORD size, DWORD prot )
+{
+char *mem;
+size += sizeof(int *);
+mem = wine_anon_mmap(base, size, prot, 0);
+/*printf("mmap base=0x%08x size=%d prot=%d, allocated at 0x%x\n",
+ base, size, prot, mem);*/
+*(int *) mem = size;
+
+mem += sizeof(int);
+/* return base address of allocated memory in eax */
+asm("movl %0, %%eax"
+:
+:"r"(mem)
+:"%eax");
+asm("int3"); /* execution doesn't continue past here */
+return;
+}
+
+/***
+ * wine_remote_NtFreeVirtualMemory (KERNEL32.@)
+ *
+ * Reentrant function that frees mmap'd memory
+ *
+ * PARAMS
+ * base [I] Desired base address
+ * size [I] Number of bytes to free
+ *
+ * RETURNS
+ * Success: %eax contains size of unmapped region
+ * Failure: %eax is 0.
+ */
+void wine_remote_NtFreeVirtualMemory( LPVOID base, DWORD size )
+{
+int result;
+if (size == 0)
+{
+base = (char *) base - sizeof(int *);
+size = *(int *) base;
+result = munmap(base, size);
+}
+else /* FIXME unsafe for invalid base */
+result = 1;
+
+/*printf("munmap base=0x%08x size=%d, result: %d (%s)\n",
+ base, size, result, result == 0 ? "success" : "failure");*/
+
+if (result == 0) /* munmap success */
+result = size;
+else
+result = 0;
+/* return munmap return value in eax */
+asm("movl %0, %%eax"
+:
+:"r"(result)
+:"%eax");
+asm("int3"); /* execution doesn't continue past here */
+return;
+}
Index: dlls/ntdll/virtual.c
===
RCS file: /home/wine/wine/dlls/ntdll/virtual.c,v
retrieving revision 1.90
diff -u -r1.90 virtual.c
--- dlls/ntdll/virtual.c23 May 2006 12:48:22 - 1.90
+++ dlls/ntdll/virtual.c2 Jun 2006 05:43:16 -
@@ -144,6 +144,36 @@
/***
+ * remote_op
+ *
+ */
+NTSTATUS remote_op( HANDLE process, int opcode,
+void* params, int params_size,
+
Re: RFC - wine-macos mailing list
C.W. Betts wrote: If you could have it so that wine-macos is instantly sent to darwine-devel, and vice-versa. That seems rather redundant. Might as well just migrate all the darwine-devel subscribers over to wine-macos and discontinue the former, rather than have two lists with the same content. - Josh
Re: [Darwine] RFC - wine-macos mailing list
If you could have it so that wine-macos is instantly sent to darwine-devel, and vice-versa.
Re: How are we doing?
> If what you really want is code that's easier to understand we're better > off scrapping all comments, then enforcing good coding style, so that > the code is readable without comments. If the functions are kept small, > things are well named, and the complexity confined (eg. no 7 level > indent), you'll be able to understand the code without the auth > > If you need to comment your code so others can understand it, it's > probably badly structured and unclear. I think that above argument, and the gripe about: i++; /* increment i */ are both overrated and overused to get away with laziness and to excuse a lack of discipline that would create better code. Yes, obviously written code to perform an obvious function needs few, if any, comments. And I think I would agree that the Wine server is commented about right; it is, imho, a beautiful piece of code. But there are plenty of places in Wine where the code does something screwball or out of the ordinary (hell, the API itself is screwball), and those places deserve more comments. I think David hit the nail on the head. I don't need a comment to tell me what the code is doing, I agree that the code itself is more clear. I need a comment to tell me why the @#$ you decided to do that. And the problem is that that prevailing attitude discourages people from being thoughtful about where a comment *would* do some good. I'd far rather discard a bunch of /* increment i */ comments but still have some comments as to an authors state of mind than have no comments at all (what we have now). But that's too bad, because Alexandre feels exactly the opposite; and so long as he's in charge (and I very much want him to continue being in charge), that's the way it's gonna be. @[EMAIL PROTECTED]@#$ Wine Maintainer... Cheers, Jeremy
Re: How are we doing?
Mike McCormack wrote: /* My tests reveal that it's done this way */ /* FIXME: this is broken */ /* go forward in the array */ Then you've got the whole issue of maintaining the comments in synchronization with the code. You've gravely misunderstood what good code commenting is? Good comments tell what the _purpose_ of a block of code or a whole function is. The purpose of comments is to let strangers get approximately acquainted with how the code works in abstract, what the call structure is, etc. - NOT to document what individual lines of code do. Comments that simply state what the code right in front of you effectively does are of course useless. That goes both for dumb oneline comments like the ones you stated earlier, but also for comments that just describe what effects come from nesting a block of code like this and that. If what you really want is code that's easier to understand we're better off scrapping all comments, then enforcing good coding style, so that the code is readable without comments. You're missing the point. If the functions are kept small, things are well named, and the complexity confined (eg. no 7 level indent), you'll be able to understand the code without the auth Sure, that would help with understanding the call structure. But your angle of attack is utopian, since making up function names perfect enough to convey all needed information in the context of all callers, and always structuring code perfectly - especially when the code has to work exactly like Windows code - is practically impossible. And getting everybody to do it is even worse. Teaching people to write good comments is infinitely easier - it's a simple case of banging 'em on the head and forcing them to write a comment every time they've done a piece of code that they know required cunning skill for whatever reason. You may need to perfect the english phrasing from some of the foreigners around here once they learn to actually write the comments, but that's a minor nit.
Re: [Darwine] RFC - wine-macos mailing list
Joshua Root wrote: > C.W. Betts wrote: > >>If you could have it so that wine-macos is instantly sent to >>darwine-devel, and vice-versa. > > That seems rather redundant. Might as well just migrate all the > darwine-devel subscribers over to wine-macos and discontinue the former, > rather than have two lists with the same content. I'll repeat myself, because the message still is getting missed. The goal of the Darwine Project is to run Wine on *PowerPC* Mac OS X. We know that is definitely *not* the goal of WineHQ because Wine Is Not an Emulator. The point of this wine-macos @ WineHQ discussion is because Alexandre & Jeremy want Wine development work for *Intel* Mac OS X to be focused at wine-devel, and I want darwine-devel to focus on Wine + QEMU development work for *PowerPC* Mac OS X. Jim White
Re: winspool: [3/3] Add GetPrintProcessorDirectoryA
Am Freitag, den 02.06.2006, 11:30 +0200 schrieb Alexandre Julliard:
> Detlef Riekenberg <[EMAIL PROTECTED]> writes:
>
> > +if (ret) {
> > +needed = WideCharToMultiByte( CP_ACP, 0, InfoW, -1, (LPSTR)Info,
> > cbBuf, NULL, NULL);
> > +if (pcbNeeded) *pcbNeeded = needed;
> > +ret = (needed > cbBuf) ? FALSE : TRUE;
>
> This check is wrong, WideCharToMultiByte will return 0 if the buffer
> is too small.
Hm.
Our documentation and MSDN states for WC2MB:
Success: If dstlen > 0, the number of characters written to dst.
http://source.winehq.org/WineAPI/WideCharToMultiByte.html
I took the code from GetPrinterDriverDirectoryA.
The UNICODE-Buffer was allocated with:
HeapAlloc(GetProcessHeap(), 0, cbBuf * sizeof(WCHAR));
The only Situation for WC2MB to run out of space here is, that
the ANSI-String has MultiByte-Characters in it.
Since our WC2MB returns 0, when the Destination-Buffer is to small,
something is wrong.
This situation is not tested in dlls/kernel/tests/*
I investigate in this.
--
By By ...
... Detlef
Re: How are we doing?
On Fri, Jun 02, 2006 at 07:27:18AM -0500, EA Durbin wrote: > >There is precious little "Why" in the comments of a lot of projects - Why > >does this function exist, why would I call it, why does it return what it > >does, etc. > > > >BS comments like those within the function don't help, obviously - but > >sometimes a comment block describing WHY a given chunk of code does what > >it does would be nice. > > > > > > Exactly my point. > > As in the case of wine, you must try to figure out what a block of code > does, then that block of code calls existing wine functions that you've > never seen before in your life. So then you have to trace that back to find > out what the already implemented function does, and look through the code > to it, because there is no documentation for it either, then it calls > another function, so go ahead and trace back through the code for it too to > find out what it does. Kind of like why i switched to gentoo, I didn't > like the rpm dependency hell of fedora, and this is eerily similar. As a > new developer, one is not familiar with all of the functions being used in > wine, a block of comment explaining what a function does would be nice, > instead of having to trace back through various parts of wine code, just to > find out what one function is doing. If you find something missing, patches or even comments pointing to such problems are welcome. Ciao, Marcus
Re: How are we doing?
David D. Hagood wrote: ARRRG! This whole thing is just a bullshit strawman. Indeed. However my strawman demonstrates that it's difficult to enforce code commenting, as you'll just end up with a bunch of bs. You also can't comment somebody else's code properly, obvious things don't need commenting, and non-obvious things either have a comment, or you won't see them. You can't force other people to add comments, and you can't add them for yourself. So if you like comments, you can jump up and down and say there should be more, but that changes nothing. My pet hate comments are stuff like: /* My tests reveal that it's done this way */ ofcourse, those tests aren't in the test suite. /* FIXME: this is broken */ With no explanation of why. /* go forward in the array */ i--; Then you've got the whole issue of maintaining the comments in synchronization with the code. If what you really want is code that's easier to understand we're better off scrapping all comments, then enforcing good coding style, so that the code is readable without comments. If the functions are kept small, things are well named, and the complexity confined (eg. no 7 level indent), you'll be able to understand the code without the auth If you need to comment your code so others can understand it, it's probably badly structured and unclear. Mike
Re: How are we doing?
There is precious little "Why" in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc. BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice. Exactly my point. As in the case of wine, you must try to figure out what a block of code does, then that block of code calls existing wine functions that you've never seen before in your life. So then you have to trace that back to find out what the already implemented function does, and look through the code to it, because there is no documentation for it either, then it calls another function, so go ahead and trace back through the code for it too to find out what it does. Kind of like why i switched to gentoo, I didn't like the rpm dependency hell of fedora, and this is eerily similar. As a new developer, one is not familiar with all of the functions being used in wine, a block of comment explaining what a function does would be nice, instead of having to trace back through various parts of wine code, just to find out what one function is doing.
Re: How are we doing?
On Friday, June 02, 2006 07:25, Mike McCormack wrote:
> >> lack of comments in the code
> >
> > +1, I think it's horrifying.
>
> void the_function_that_adds_one_to_i(int i)
> {
> /* this adds one to i */
> i = i + 1;
>
> /* this returns i to the caller */
> return i;
> }
>
> Horrifying, yes :)
>
> Mike
Particularly horrifying is the return i in a void function! Is there a test
for what native does in this case?
- Neil
Re: How are we doing?
Huw Davies wrote:
There's a bug in this code, let's try this:
/* change by Huw Davies 02-Jun-2006, to fix the return type of the function */
int the_function_that_adds_one_to_i(int i)
{
/* this adds one to i */
i = i + 1;
/* this returns i to the caller */
return i;
}
That's so much better ;-)
Huw.
ARRRG! This whole thing is just a bullshit strawman. The real
complaint about the lack of comments is not this kind of trivial
comment, but more like:
/* the_function_that_adds_one_to_i - return 1+value
This function is necessary because of a compiler bug in FooC 0.8,
wherein just incrementing the loop variable in
WinGenCryptokeyAllHailBillOurDarkLord will generate incorrect code.
*/
int the_function_that_adds_one_to_i(int i)
{
/* this adds one to i */
i = i + 1;
/* this returns i to the caller */
return i;
}
There is precious little "Why" in the comments of a lot of projects -
Why does this function exist, why would I call it, why does it return
what it does, etc.
BS comments like those within the function don't help, obviously - but
sometimes a comment block describing WHY a given chunk of code does what
it does would be nice.
Re: How are we doing?
On Fri, Jun 02, 2006 at 08:25:42PM +0900, Mike McCormack wrote:
>
> >>lack of comments in the code
> >
> >+1, I think it's horrifying.
>
> void the_function_that_adds_one_to_i(int i)
> {
>/* this adds one to i */
>i = i + 1;
>
>/* this returns i to the caller */
>return i;
> }
There's a bug in this code, let's try this:
/* change by Huw Davies 02-Jun-2006, to fix the return type of the function */
int the_function_that_adds_one_to_i(int i)
{
/* this adds one to i */
i = i + 1;
/* this returns i to the caller */
return i;
}
That's so much better ;-)
Huw.
--
Huw Davies
[EMAIL PROTECTED]
intermediate fontconfig 2.3.94 problems
Hi, SUSE Linux 10.1 contains fontconfig 2.3.94, which changed the FcPatternGetString() function from return path names to return only the filenames. We received this bugreport: https://bugzilla.novell.com/show_bug.cgi?id=179457 However, Bernd Rosenkraenzer reported this problem already and the change was reverted for fontconfig 2.3.95. Its just that it might be broken only in SL 10.1 (perhaps fixed with online update, still in discussion). So this is just a heads-up, if more bugreports should appear. Ciao, Marcus
Re: How are we doing?
Molle Bestefich wrote: EA Durbin wrote: lack of comments in the code +1, I think it's horrifying. The lack of comments in your email is more horrifying. Yes, yes, I know you will say that your email is self-documenting, but that isn't the point. ;-) -- Rob Shearman
Re: How are we doing?
lack of comments in the code
+1, I think it's horrifying.
void the_function_that_adds_one_to_i(int i)
{
/* this adds one to i */
i = i + 1;
/* this returns i to the caller */
return i;
}
Horrifying, yes :)
Mike
Re: How are we doing?
EA Durbin wrote: lack of comments in the code +1, I think it's horrifying.
Re: user32, x11drv: patch to send WM_SIZE at window state change (bug 4964)
Juris Smotrovs <[EMAIL PROTECTED]> writes: > The defwinproc mismatch itself appears > because, after solving the WM_SIZE issue, this message -- > correctly -- is sent, so the actual message queue shifts > relative to the expected message queue, and -- due to > some messages still missing -- three expected defwinproc > messages coincide with three actual non-defwinproc messages > which are expected later-on. Thus this failure is actually > not about messages sent from incorrect place, but simply > about missing messages which is a very typical failure > among the todo tests. Ah OK, I get it now. Thanks, I'll put it in. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winspool: [3/3] Add GetPrintProcessorDirectoryA
Detlef Riekenberg <[EMAIL PROTECTED]> writes:
> +if (ret) {
> +needed = WideCharToMultiByte( CP_ACP, 0, InfoW, -1, (LPSTR)Info,
> cbBuf, NULL, NULL);
> +if (pcbNeeded) *pcbNeeded = needed;
> +ret = (needed > cbBuf) ? FALSE : TRUE;
This check is wrong, WideCharToMultiByte will return 0 if the buffer
is too small.
--
Alexandre Julliard
[EMAIL PROTECTED]
Prospects of an OpenAL audio driver...
I have started work on an openal driver for wine... So far I have playback and recording working (with minor issues) (for some reason the DSound HEL is unhappy with my driver) OpenAL seems to have enough functionality to do the job. Are there any problems with using OpenAL for such a purpose? - Nick
Re: [Darwine] RFC - wine-macos mailing list
Jeremy White <[EMAIL PROTECTED]> writes: > My driving concern is that I think we need to welcome the Mac > community to the Wine Project and do all that we can to > enable the Mac developers and users to use mainstream Wine resources. > I don't think anyone wants www.winehq.org to be perceived as > a 'Linux only' environment. (Although I do see that www.winehq.org > doesn't list Mac OS X...hmmm). I think creating a separate list for Mac is only going to reinforce that impression, which is just the opposite of what we want. Mac users should be considered first-class citizens just like Linux users, and we must make it clear that they are welcome on our standard mailing lists. If at some point there's too much traffic on wine-users we can split it, but we are not there yet. -- Alexandre Julliard [EMAIL PROTECTED]
