Re: spying COM
This certainly looks useful, thanks! I suspect it'll need at least CoTreatAsClass to be implemented to work on Wine, but that isn't too hard (it may even be done by now, been a while since I checked). Saulius Krasuckas wrote: Am not sure would it be of any use for list members, but just some minutes ago I've discovered The COM spy. Quite old stuff, but whatever: http://staff.develop.com/jasonw/comspy/default.htm
Re: RFC: ntdll critical section debug
Actually nearly all critical sections in Wine are initialized statically. This improves performance, and avoids having lots of init functions called all over the place. I'm not convinced it's worth changing that just to be able to build a list of sections. It also lets you name them more easily which is *really* handy. I don't recall ever seeing an API to name a created critical section though I'm sure one must exist.
Re: resend: patch: shell32.dll - SHELL_ArgifyW expands env-vars
advert Check out the NEW! IMPROVED! Wine developer cheatsheet here: http://navi.cx/~mike/wine/developer-cheatsheet.html Everything you always wanted to know but were too afraid to ask, in ONE convenient document!! /advert In particular, it explains how to work with unicode strings in Wine. Look for the comments from Francois to see how to convert between A/W strings using Win32, I haven't had a chance to merge them in yet. thanks -mike Jens Collin wrote: thanks a lot! New patch is on it's way :) /Jens
Re: Directx9
My other concern is if I start doing it and have to give up due to work or other pressures, I could leave a half migrated setup. I assume its relavitevly easy with cvs to back out changes if this occurs, and I hope it wont, but it is a concern. I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest. This is the sort of thing we wanted arch for. Unfortunately, the way we use CVS means that we can't really do branching as only AJ commits. So, if it's not possible to do the migration without breaking things temporarily, there are three ways forward: 1) Have you set up arch or a local CVS repository and commit to that 2) Give you write access to WineHQ CVS and let you commit to a branch 3) Just have you submit a really huge patch which does the changes (2) is, as far as I can tell, unprecedented, but hey ... worth suggesting. (3) might not make Alexandre too happy but is the simplest. (1) is perhaps the best way forward, with the biggest disadvantage being that arch is rather cumbersome to learn for people new to it, and when I last used it was rather slow. But, it may work a lot better these days. thanks -mike
Re: winecfg (was Re: W-A calls)
It appears that Mike has been doing a lot of work on this. http://www.winehq.org/hypermail/wine-devel/2004/09/0221.html So you probably first want to coordinate with him. Yes. I'm aware that I'm holding people up right now due to my non-connectedness. I'm actually living in a bedbreakfast with no net connection, so I only have web/email access at work. It's kind of odd - I've been doing some work on it lately, and suddenly people pop up who want to work on it after a long period of inactivity. Oh well :) I would start by running winecfg, and seeing what doesn't work, which is a lot. For example, on the very first tab, you can select a Windows Version, but changing the setting doesn't actually change anything (it should make/alter a registry entry). The winecfg code is in wine/programs/winecfg. Fixed by me already. Actually, I've done quite a bit of work on it, I'd recommend waiting for 2 weeks at which point I'll have net access to my laptop again and can hopefully send off my work. At that point I'll be disappearing back into university life and doing CW work again so the coast will be clear for others to work on it. A long discussion of things that are needed is in the thread starting: http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html I've sorted some of these already, especially in the apps tab. So ... if you guys can wait for 2 weeks I should (hopefully) have something to show soon. thanks -mike
PEB documentation
This is interesting information, but where did it come from? Is this structure described in some MS documentation? If so, does it have the full layout of the TEB as well? Log message: Robert Reif [EMAIL PROTECTED] Document all the structure members up to SessionId in the PEB.
Re: Wininet: InternetSetStatusCallback Fix
Robert Shearman wrote: Hi, You can call InternetSetStatusCallback on a HTTP handle, not just a InternetOpen handle, so we should search up through the parents to find it. Oops, I just checked on MSDN and this patch is wrong. We should copy and store the status callback in every handle, not just in the top level one. I'll submit a new patch soon. Rob
Re: Http Fixes
On Mon, Sep 13, 2004 at 11:38:32AM +0100, Robert Shearman wrote: Hi, I have seen one server that likes to return ICY instead of HTTP/1.x. This patch allows the connection to the server continue, as native does. This would be icecast I suspect ;) Ciao, Marcus pgp4VgjdKu2qm.pgp Description: PGP signature
Re: Directx9
This is the sort of thing we wanted arch for. Unfortunately, the way we use CVS means that we can't really do branching as only AJ commits. So, if it's not possible to do the migration without breaking things temporarily, there are three ways forward: Well, why could we not live with DX8 / DX9 breakage for some time ? At the time D3D was resurected, it was broken for most of the time (and probably still is :-) ). And if someone disappears from development, it's just more motivations for others to pick up the work and continue (which would be more problematic with branches as this branch, if unmaintained, could really wither away without anyone working on it). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Directx9
I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest. I would be for solution 1) even if it means breaking somewhat D3D8 for some time. Note that this was Raphael's plan (although his was even more ambitious as he wanted the D3D1/7 code to use that same library). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Directx9
Well, why could we not live with DX8 / DX9 breakage for some time ? At the time D3D was resurected, it was broken for most of the time (and probably still is :-) ). And if someone disappears from development, it's just more motivations for others to pick up the work and continue (which would be more problematic with branches as this branch, if unmaintained, could really wither away without anyone working on it). Yes, this is true. But I think this isn't the direction we want to go in. At *some* point we have to stop simply releasing CVS snapshots which may or may not work/run important apps/eat your hard disk and actually do proper releases that are, you know, tested'n'stuff. Trivial example that's causing people problems today: apparently winecfg eats your drive configuration. People install wine, encounter this suggestively named winecfg program, run it, and now they get the dreaded C:\\Windows is not accessible error. Anyway. Yes. Releases. If we as a project are committed to doing 0.9, 1.0+ releases it means we can't simply break code people are using to play their games for months at a time and shrug it off. What other projects do this? I can't think of any. For most projects CVS is CVS and is where stuff is broken then fixed, and releases are what users install. They are expected to not ship with important features missing. Other projects typically use branches to deal with this, or in the case of the kernel fork off into separate projects that just maintain huge differentials which are folded back in when complete. So what do we do? thanks -mike
Re: Shwapi updates
Hi James, Can this patch be broken up into smaller, independent parts? It's more likely to be committed if that is the case. Aside from the tests, what constitutes independent? These are all new functions so there is no possibility of regressions, which is the main reason to split up patches. Ease of understanding/reviewing the patches is the other main reason, but each function is only 5-10 lines. Since each added function requires the spec file to be updated its much easier to add the functions together (It helps me clean up the diffs from my tree to wine-cvs faster too). Cheers, Jon = Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance... - Live [EMAIL PROTECTED] ___ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool
Re: Directx9
If we as a project are committed to doing 0.9, 1.0+ releases it means we can't simply break code people are using to play their games for months at a time and shrug it off After 1.0 there will be a stable and a development branch, the stable one for users, and the development one for new stuff, where it doesn't matter if things are broken for a while. A bit like the kernel with 2.4 stable and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least that's how most projects work. Ivan.
Re: Directx9
Ivan Leo Puoti wrote: if things are broken for a while. A bit like the kernel with 2.4 stable and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least that's how most projects work. It's also true that the kernel is not going to branch 2.7 anytime soon. I don't think that a breakage in d3d can be an option now. Wine is an 'old' project also if not stable or mature, and breaking stuff now is a big problem to users. Also, as I'm not using d3d myself, if the compilation is broken, I can neither use wine for normal 2d desktop apps. IMHO a temporary branch until completion of the new support can be a good way. -- Diego Flameeyes Pettenò [EMAIL PROTECTED] - http://flameeyes.web.ctonet.it/
Re: Directx9
On Mon, Sep 13, 2004 at 01:55:19PM +0100, Mike Hearn wrote:
At *some* point we have to stop simply releasing CVS snapshots which may
or may not work/run important apps/eat your hard disk and actually do
proper releases that are, you know, tested'n'stuff.
Yes, but what should I care about this ? I mean that doing branches,
handling releases is the job of a 'release manager' who should decide when
to freeze, what patches to accept in freezed code and stuff like that.
In my case, I would expect to work 99.99 % of the case on the trunk, the
instable branch (except, of course, if any game is in the 'supported by this
release' list and would need some bugfixing there).
For example, if DirectX is broken for 3 consecutive releases, I would expect
the people doing the release to label the old 'working' version and branch
from there if any bugs fixes are needed.
I do not want to be my own release manager ('oh this will take X months to
finish, I will branch').
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
(no subject)
For example, if DirectX is broken for 3 consecutive releases, I would expect the people doing the release to label the old 'working' version and branch from there if any bugs fixes are needed. Things in wine break all the time, users know it and are used to it, if d3d8 breaks for 3 releases, people will just use an old version until things are fixed. Many people stayed at wine-20031212 for months because of regressions that weren't fixed for a few months, but people just kept wine-20031212 and were happy. With alpha software this is quite normal. Ivan.
Re: Directx9
I don't think that a breakage in d3d can be an option now. Wine is an 'old' project also if not stable or mature, and breaking stuff now is a big problem to users. Well, if that is the case, we need to recruit someone to do 'proper' releases as there are no guarantees for now of any stability between any releases (the day the config file goes into the registry or when the new window management is comitted, I think that a LOT of breakage will occur). At least when the breakage is in the main tree, people are more motivated to fix it than when lying in a test branch that nobody will get and use :-) Also, as I'm not using d3d myself, if the compilation is broken, I can neither use wine for normal 2d desktop apps. Nobody ever told about any 'compilation' breakage... Any patch sent to the list will compile (modulo GL header issues :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Why is our OutputDebugString a server request?
Hi all, It seems that OutputDebugString is defined in the Win32 API as a set of client side operations. In wine, however, it is a server request. I have not traced it into the server to see whether they carry out the same operations or not. However, even if they do, I am wondering why we need them? Wouldn't it be better to not do server side things that can be done client side? (http://www.unixwiz.net/techtips/outputdebugstring.html) Shachar P.S. I perfectly understand that obtaining mutexes and waiting on events is a server side operation. However, it was my impression that such things are best carried out by mimicking the Win32 structure as much as possible. Isn't that the case? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
A window update problem in Dutch tax program.
Hi, I am looking in a display problem in the electronic declaration programs of the Dutch tax office. Here is a schematic of the windows involved: +--10022---+ | | | +--100c6-+ | || | | ..20110... | | | .. | | | .. | | | +-20114--+ | | | || | | | || | | | ++ | | || | || | ++ +--+ [10022] is a top level window. One of its child [20114] has itself a child window [20110] that initially lies outside the parent client area. A series of calls to ScrollWindowEx() brings it inside, simulating a drop down listbox. Now [20114] should normally not be visible because it lies behind another child of the main window: [10022] | +--[20114] | | | +--[20110] | | +-[100c6] | + ... No window styles that could affect this behavior (WS_CLIPCHILDREN, WS_CLIPSIBLINGS, WS_EX_TRANSPARENT) are used. Here the partial output of info wnd command: 00010022WindowIB2003 14cb Aangifte 2003 00020114 WindowIB2003 5000 -- Empty -- 00020110 @LISTBOX 50800141 -- Empty -- 000100c6 WindowIB2003 5000 TheContent The program first validates the update region of the main window with the rect of [20114]. |0009:Call user32.ValidateRect(00010022,4070f988) ret=00426f64 ... |trace:win:RedrawWindow Update region of hwnd 0x10022 is nil |0009:Ret user32.ValidateRect() retval=0001 ret=00426f64 As the extra trace message reports, this window has a null update region at this point. Then the first scroll is requested: |0009:Call user32.ScrollWindowEx(00020114,,000a,4070f6e4,4070f6b4,,,0001) ret=00426fd1 |trace:scroll:ScrollWindowEx 0x20114, 0,10 hrgnUpdate=(nil) rcUpdate = (nil) (0,-47)-(71,0) 0001 |trace:scroll:ScrollWindowEx clipRect = (0,0)-(71,10) ... |0009:Ret user32.ScrollWindowEx() retval=0001 ret=00426fd1 directly after this the same scroll rectangle (4070f6e4) is invalidated: |0009:Call user32.InvalidateRect(00020114,4070f6e4,0001) ret=00426fe6 |trace:win:RedrawWindow 0x20114 (0x137e) rect 0,0-71,10 (nil) flags=0005 |trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE ... |0009:Ret user32.InvalidateRect() retval=0001 ret=00426fe6 and directly UpdateWindow is called: |0009:Call user32.UpdateWindow(00020114) ret=00426fef |0009:Call x11drv.MsgWaitForMultipleObjectsEx(0001,4070f460,,00ff,) ret=40764927 |trace:event:EVENT_ProcessEvent called. UpdateWindow calls RedrawWindows that first looks for outstanding events, that is where the trouble starts: |trace:event:EVENT_ProcessEvent Got event Expose for hwnd/window 0x20114/3a001aa, GetFocus()=0x20112 |trace:x11drv:X11DRV_Expose win 0x20114 (3a001aa) 0,0 71x47 ... |0009:Call user32.RedrawWindow(00010022,4070f010,,0085) ret=40d519a2 |trace:win:RedrawWindow 0x10022 ((nil)) rect 291,142-362,189 (nil) flags=0085 |trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN and the main window and child [100c6] find them selves invalidated: |trace:win:RDW_Painthwnd 0x10022 [0x1382] - hrgn [0x139e], flags [0085] ... |trace:win:RDW_Painthwnd 0x100c6 [0x138a] - hrgn [0x139e], flags [0085] after the final scroll, a WM_PAINT message is dispatched to [100c6] and the scrolled window [20114] is invisible. I am not sure what the real problem is: either the expose event should not be there or the handling of the event is wrong. For the latter case: the handling in expose_window() sure does not expect to make visible a normally obscured window. Any suggestions? The program is available on-line, but I would need to give some instruction for non-Dutch users. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Why is our OutputDebugString a server request?
so that debuggers can intercept it (especially ones with GUI) and do what they want with it.A+ Message du 13/09/04 17:50 De : "Shachar Shemesh" <[EMAIL PROTECTED]> A : "Wine Development" <[EMAIL PROTECTED]> Copie à : Objet : Why is our OutputDebugString a server request?
Re: Why is our OutputDebugString a server request?
Pouech Eric DMI AEI CAEN wrote: so that debuggers can intercept it (especially ones with GUI) and do what they want with it. A+ Message du 13/09/04 17:50 De : Shachar Shemesh A : Wine Development Copie à : Objet : Why is our OutputDebugString a server request? But as far as I can see, this means that Windows debuggers won't get it. Wouldn't it be better to implement it the Win32 way? At the very least, implement it ALSO as the Win32 way? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
RE: Why is our OutputDebugString a server request?
Title: RE: Why is our OutputDebugString a server request? I agree - I got stumped on this very issue when I got into Wine last year. I was used to relying on these trace messages and it took me a while to understand where the messages were actually being sent! //raghavan -Original Message- From: Shachar Shemesh [mailto:[EMAIL PROTECTED]] Sent: Monday, September 13, 2004 9:11 AM To: [EMAIL PROTECTED] Cc: Wine Development Subject: Re: Why is our OutputDebugString a server request? Pouech Eric DMI AEI CAEN wrote: so that debuggers can intercept it (especially ones with GUI) and do what they want with it. A+ Message du 13/09/04 17:50 De : Shachar Shemesh A : Wine Development Copie à : Objet : Why is our OutputDebugString a server request? But as far as I can see, this means that Windows debuggers won't get it. Wouldn't it be better to implement it the Win32 way? At the very least, implement it ALSO as the Win32 way? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Directx9
On Mon, 13 Sep 2004 17:21:51 +0200, Ivan Leo Puoti [EMAIL PROTECTED] wrote: Things in wine break all the time, users know it and are used to it, if d3d8 breaks for 3 releases, people will just use an old version until things are fixed. Many people stayed at wine-20031212 for months because of regressions I think that's a bad attitude. I hear one of two things all the time: 1. Wine rocks. All my windows programs just work. 2. Wine sucks. Nothing will run. Lots of people install Wine, have a good experience, and never bother upgrading. Lots of other people install Wine, have a bad experience, and never bother trying it again. Personally, I like to hear stories like #1. Anyway, that wasn't really what I was getting at.. last spring Lionel had this to say about a wined3d library: http://www.winehq.org/?interview=15 It does make sense it could be done incrementally. -Brian
RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars - HOLD PATCH
Please hold this patch and don't commit it yet. I've been told that it contains things to be checked first. /J -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jens Collin Sent: den 11 september 2004 21:47 To: [EMAIL PROTECTED] Subject: patch: shell32.dll - SHELL_ArgifyW expands env-vars Patch updated with correct string constants handling. thanks James and Alexandre. changelog: * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. (Such as %SystemRoot%).
Re: Shwapi updates
Jon Griffiths [EMAIL PROTECTED] writes: Aside from the tests, what constitutes independent? These are all new functions so there is no possibility of regressions, which is the main reason to split up patches. Ease of understanding/reviewing the patches is the other main reason, but each function is only 5-10 lines. Since each added function requires the spec file to be updated its much easier to add the functions together (It helps me clean up the diffs from my tree to wine-cvs faster too). It's OK to send them in the same patch, but then please also send a single Changelog entry for the whole patch, not one per file. -- Alexandre Julliard [EMAIL PROTECTED]
Re: dlls/winsock/socket breakage
Gerald Pfeifer [EMAIL PROTECTED] writes: ChangeLog: Roderick Colenbrander [EMAIL PROTECTED] Gerald Pfeifer [EMAIL PROTECTED] Make WS2_Send(), WS_getsockopt(), and WS_setsockopt() work on FreeBSD. You shouldn't use #ifdef __FreeBSD__ for that, you should check for the actual features (for instance #ifdef SOL_IPX etc.), possibly adding configure checks if needed. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Shwapi updates
Aside from the tests, what constitutes independent? If the functions do not rely on each other, then they are independent of each other. You can leave it the way it is, but it was a suggestion to help from the case where say one of the functions has an error in it. If that is the case then none of th patch is committed where if it was split into seperate patches, 4/5 would be committed and only a minor change is required to finish it, but this is all preference of author/reviewer. On Mon, 13 Sep 2004 02:38:14 -0700 (PDT), Jon Griffiths [EMAIL PROTECTED] wrote: Hi James, Can this patch be broken up into smaller, independent parts? It's more likely to be committed if that is the case. Aside from the tests, what constitutes independent? These are all new functions so there is no possibility of regressions, which is the main reason to split up patches. Ease of understanding/reviewing the patches is the other main reason, but each function is only 5-10 lines. Since each added function requires the spec file to be updated its much easier to add the functions together (It helps me clean up the diffs from my tree to wine-cvs faster too). Cheers, Jon = Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance... - Live [EMAIL PROTECTED] ___ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool -- James Hawkins
Re: Directx9
Anyway, that wasn't really what I was getting at.. last spring Lionel had this to say about a wined3d library: It does make sense to have common code all in the same place... Ivan.
Re: Rename keyword variable
Andreas Mohr [EMAIL PROTECTED] writes: Hi, template is a keyword on c++, so better rename it to menu_template. We've been through this before; there's absolutely no reason to do that. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Directx9
On Mon, Sep 13, 2004 at 01:55:19PM +0100, Mike Hearn wrote: At *some* point we have to stop simply releasing CVS snapshots which may or may not work/run important apps/eat your hard disk and actually do proper releases that are, you know, tested'n'stuff. While this point will come eventually, it has not been reached: ANNOUNCE starts as follows: This is release 20040813 of Wine, a free implementation of Windows on Unix. This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly. As long as it's a developers only release, there is *absolutely no reason why developers should not be allowed to break things for a while. Also, please consider how often Alexandre rejects patches not because they would not be an improvement, but because they should be improved even more. *That* would also have to change once you start talking about making releases that are truly intended for users. Honestly, I don't think that this time has come already - and from my point of view, this may remain for quite a while. Those users who feel differently currently have the option the use wine versions that have been developed/modified for user- use: Codewavers and Transgamings wine flavours. Once Wine is declared to be ready for ordinary users, the development process should indeed change. A good example on how to continue is KDE: Currently, development is done in two different branches: HEAD and 3_3_BRANCH: In HEAD developers are free to develop things, add new things (and occasionally break things: HEAD doesn't even compile from time to time). 3_3_BRANCH must be stable, changes to it a reviewed etc. IMO, this would also be a good way for wine, once it's considered to be sufficiently stable and feature complete. Ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
Re: dlls/winsock/socket breakage
On Mon, 13 Sep 2004, Alexandre Julliard wrote:
You shouldn't use #ifdef __FreeBSD__ for that, you should check for
the actual features (for instance #ifdef SOL_IPX etc.), possibly
adding configure checks if needed.
You're right. Tested on FreeBSD 4.10 as well as SUSE Linux 9.1.
Gerald
ChangeLog:
Roderick Colenbrander [EMAIL PROTECTED]
Gerald Pfeifer [EMAIL PROTECTED]
Make WS2_Send(), WS_getsockopt(), and WS_setsockopt() work on FreeBSD.
Index: socket.c
===
RCS file: /home/wine/wine/dlls/winsock/socket.c,v
retrieving revision 1.155
diff -u -3 -p -r1.155 socket.c
--- socket.c7 Sep 2004 20:47:03 - 1.155
+++ socket.c13 Sep 2004 19:02:20 -
@@ -1108,6 +1108,7 @@ static int WS2_send ( int fd, struct iov
#ifdef HAVE_IPX
if(to-sa_family == WS_AF_IPX)
{
+#ifdef SOL_IPX
struct sockaddr_ipx* uipx = (struct sockaddr_ipx*)hdr.msg_name;
int val=0;
int len=sizeof(int);
@@ -1122,6 +1123,7 @@ static int WS2_send ( int fd, struct iov
TRACE(ptype: %d (fd:%d)\n, val, fd);
uipx-sipx_type = val;
}
+#endif
}
#endif
@@ -1580,17 +1582,33 @@ INT WINAPI WS_getsockopt(SOCKET s, INT l
switch(optname)
{
case IPX_PTYPE:
+ {
+#ifndef SOL_IPX
+ struct ipx val;
+ socklen_t len=sizeof(struct ipx);
+#endif
fd = get_sock_fd( s, 0, NULL );
-
+
+#ifdef SOL_IPX
if(getsockopt(fd, SOL_IPX, IPX_TYPE, optval, optlen) == -1)
{
return SOCKET_ERROR;
}
+#else
+ if(getsockopt(fd, 0, SO_DEFAULT_HEADERS, val, len)
+ == -1 )
+ {
+ return SOCKET_ERROR;
+ }
+*optval = (int)val.ipx_pt;
+#endif
+
TRACE(ptype: %d (fd: %d)\n, *(int*)optval, fd);
release_sock_fd( s, fd );
return 0;
break;
+ }
case IPX_ADDRESS:
/*
* On a Win2000 system with one network card there are useally three ipx devices one with a speed of 28.8kbps, 10Mbps and 100Mbps.
@@ -2305,18 +2323,31 @@ int WINAPI WS_setsockopt(SOCKET s, int l
switch(optname)
{
case IPX_PTYPE:
+ {
+#ifndef SOL_IPX
+ struct ipx val;
+#endif
fd = get_sock_fd( s, 0, NULL );
TRACE(trying to set IPX_PTYPE: %d (fd: %d)\n, *(int*)optval, fd);
/* We try to set the ipx type on ipx socket level. */
+#ifdef SOL_IPX
if(setsockopt(fd, SOL_IPX, IPX_TYPE, optval, optlen) == -1)
{
ERR(IPX: could not set ipx option type; expect weird
behaviour\n);
return SOCKET_ERROR;
}
+#else
+ /* Should we retrieve val using a getsockopt call and then
+* set the modified one? */
+ val.ipx_pt = *optval;
+ setsockopt(fd, 0, SO_DEFAULT_HEADERS, val, sizeof(struct ipx));
+#endif
+
release_sock_fd( s, fd );
return 0;
break;
+ }
case IPX_FILTERPTYPE:
/* Sets the receive filter packet type, at the moment we don't support
it */
FIXME(IPX_FILTERPTYPE: %x\n, *optval);
Re: Directx9
At *some* point we have to stop simply releasing CVS snapshots which may or may not work/run important apps/eat your hard disk and actually do proper releases that are, you know, tested'n'stuff. Also consider that the time wasted on testing/releasing/branching will slow up wine development, whoever would be doing that could certanly work on the wine code itself. I fully agree with what Joerg Mayer says, the time has not yet come. Ivan.
Re: Correct ConvertSidToStringSidW with test
Juan Lang [EMAIL PROTECTED] writes:
@@ -2230,13 +2232,23 @@
sz = 14 + pisid-SubAuthorityCount * 11;
str = LocalAlloc( 0, sz*sizeof(WCHAR) );
-sprintfW( str, fmt, pisid-Revision,
- pisid-IdentifierAuthority.Value[2],
- pisid-IdentifierAuthority.Value[3],
- pisid-IdentifierAuthority.Value[0]0x0f,
- pisid-IdentifierAuthority.Value[4]0x0f,
- pisid-IdentifierAuthority.Value[1]0x0f,
- pisid-IdentifierAuthority.Value[5]0x0f);
+sprintfW( str, fmt, pisid-Revision );
+for( i=2; i=3; i++ )
+{
+if( pisid-IdentifierAuthority.Value[i] )
+printingIdent = TRUE;
+if( printingIdent )
+sprintfW( str + lstrlenW( str ), identAuthFmt,
+ pisid-IdentifierAuthority.Value[i] );
+}
That doesn't look right, you'd need something like %02x for the second
value if the first was printed. It seems it would be a lot easier to
simply build an int from the various values and then format it with a
single %x.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Proper finalization in StartServiceW
Alexander Yaworsky [EMAIL PROTECTED] writes:
+if( WAIT_FAILED == r )
+{
+last_error = GetLastError();
+CloseHandle( procinfo.hProcess );
+goto done;
+}
-ReleaseSemaphore(data, 1, NULL);
-
-if( r == WAIT_FAILED)
-return FALSE;
+/* allright */
+CloseHandle( procinfo.hProcess );
+last_error = 0;
+ret = TRUE;
-return TRUE;
+done:
+CloseHandle( wait );
+ReleaseSemaphore(data, 1, NULL);
+CloseHandle( data );
+SetLastError( last_error );
+return ret;
You should never need to do that sort of thing. CloseHandle and
ReleaseSemaphore won't change last error if they are called for valid
handles, and if they are not you are just hiding a bug. Also, you very
probably don't want to set last error to 0 on success, unless you have
clear evidence that Windows does it in this case too.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Why is our OutputDebugString a server request?
Shachar Shemesh [EMAIL PROTECTED] writes: But as far as I can see, this means that Windows debuggers won't get it. Wouldn't it be better to implement it the Win32 way? At the very least, implement it ALSO as the Win32 way? It will generate an output string debug event, so Windows debuggers should be able to deal with it. The real Win32 way would be to raise an exception, which is certainly something we could do; but since Win32 provides a debug event for this purpose, it seemed reasonable to use it. Now, if you know of a case where it causes trouble, it can be changed. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Shell32: Reimplement SHGetFolder functions
Juan Lang [EMAIL PROTECTED] writes:
+static void loadShell32(void)
+{
+if (hShell32)
+{
+if (pMalloc)
+{
+pMalloc-lpVtbl-Release(pMalloc);
+pMalloc = NULL;
+}
+/* until it's really unloaded: */
+while (FreeLibrary(hShell32))
+;
I'm not sure what you are trying to do here, but this causes an
infinite loop on XP (and it probably should under Wine too, since the
test binary imports shell32). Also some tests fail on XP:
shellpath.c:433: Test failed: SHGetFolderPath returned 0x, expected 0x80070002
shellpath.c:438: Test failed: SHGetFolderLocation returned 0x, expected E_FAIL
shellpath.c:442: Test failed: SHGetSpecialFolderPath succeeded, expected failure
shellpath.c:447: Test failed: SHGetFolderLocation returned 0x, expected E_FAIL
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Shell32: Reimplement SHGetFolder functions
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
+static void loadShell32(void)
+{
+if (hShell32)
+{
+if (pMalloc)
+{
+pMalloc-lpVtbl-Release(pMalloc);
+pMalloc = NULL;
+}
+/* until it's really unloaded: */
+while (FreeLibrary(hShell32))
+;
I'm not sure what you are trying to do here, but
this causes an
infinite loop on XP (and it probably should under
Wine too, since the
test binary imports shell32).
Really? Odd, I first wrote this under XP. I'm trying
to force shell32 to unload; native shell32 caches
values you've already queried and won't reinitialize
them till you reload it.
But thanks, I'll test some more.
--Juan
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
RE: iostream and msvcrt?
Hi Dimi, Thanks for the offer but I have had the project pulled. Unfortunately I couldnt get a working model in time and the hardware has been recycled to another project ;-(. Basically I needed to compile STLport so I could use iostreams in a project I was converting to wine. I'm going to keep my eye on this list as I hope to have a new round of funding approved late in the year. I may also get an old PC at home working and have another go! thanks, scott. -Original Message- From: Dimitrie O. Paun [SMTP:[EMAIL PROTECTED] Sent: Wednesday, 8 September 2004 0:06 To: Scott Snell Cc: Dimitrie O. Paun; Boaz Harrosh; Wine-Devel (E-mail) Subject: Re: iostream and msvcrt? Just got back from vacation. Why is it including a cstdlib? Anyway, can you send me exactly what you did, so I can try to reproduce it on my box? -- Dimi.
extern variable question
I'm trying to write a Direct Input regression test and I ran into a problem I can't resolve (and the linker too). dinput.h defines an extern variable: extern const DIDATAFORMAT c_dfDIJoystick; I can't find this variable in dinput.dll but it is in dinput.lib on windows. It looks like I need to generate a dinput.a. How can I generate both a dinput.dll.so and a dinput.a from the same source?
Re: extern variable question
[EMAIL PROTECTED] wrote: I'm trying to write a Direct Input regression test and I ran into a problem I can't resolve (and the linker too). dinput.h defines an extern variable: extern const DIDATAFORMAT c_dfDIJoystick; I can't find this variable in dinput.dll ... It looks like it was added about ten days ago: http://www.winehq.org/hypermail/wine-patches/2004/08/0551.html What date is your wine source tree? - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change
Re: Why is our OutputDebugString a server request?
Alexandre Julliard wrote: Shachar Shemesh [EMAIL PROTECTED] writes: But as far as I can see, this means that Windows debuggers won't get it. Wouldn't it be better to implement it the Win32 way? At the very least, implement it ALSO as the Win32 way? It will generate an output string debug event, so Windows debuggers should be able to deal with it. The real Win32 way would be to raise an exception, which is certainly something we could do; Not according to my information. According to my information, this is merely a mutex and an event. (is that what you meant?). I'll do some proper looking into here. but since Win32 provides a debug event for this purpose, it seemed reasonable to use it. Now, if you know of a case where it causes trouble, it can be changed. I get the feeling that I misunderstood what you just said. What is the debug event? where do we do anything with it? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
