Now WIDL is good enough to generate a drop-in replacement for Wine's wtypes.h (attached) from a suitably crafted Wine-compatible wtypes.idl (also attached). I've included all the definitions that were already in Wine's wtypes.h (but I was too lazy to do everything that's in Microsoft's wtypes.idl yet).
What do you think, is this good enough to go into Wine? Are there some desirable changes to widl or wtypes.idl? And should IDL files go into the main include dir along with the other Win32 headers?
IDL-generated files would also eventually obsolete all the current wine/obj_*.h files, but those obj_* files seem to be somewhat more logically structured than MS's own IDL files, should we craft Wine's IDL files accordingly, and maybe have some top-level .idl files in include/ and some sub-.idl files under include/wine/, like it's done now in e.g. objidl.h?
Note that I will work on ReWind, not directly on Wine, so I probably won't be able to submit massive "change all files to include this instead of that" patches (that apply to Wine) with any new files.
On Thursday 31 October 2002 06:08 pm, Ove Kaaven wrote:
Note that I will work on ReWind, not directly on Wine, so I probably won't be able to submit massive "change all files to include this instead of that" patches (that apply to Wine) with any new files.
I get the ReWind-patches digest. I'd be happy to continue merging your changes back into wine, at least insofar as I know how... but will they all funnel through that list, or do I need to watch cvs?
On Thu, 31 Oct 2002, Greg Turner wrote:
On Thursday 31 October 2002 06:08 pm, Ove Kaaven wrote:
Note that I will work on ReWind, not directly on Wine, so I probably won't be able to submit massive "change all files to include this instead of that" patches (that apply to Wine) with any new files.
I get the ReWind-patches digest. I'd be happy to continue merging your changes back into wine, at least insofar as I know how... but will they all funnel through that list, or do I need to watch cvs?
I haven't decided yet. But I probably won't send to rewind-patches, since I don't usually use that list (if it's something useful to Wine, I'd just send a patch to wine-patches and have the rewind patch tracker pick it up from there. But if it's not useful to Wine, I commit it directly to rewind without sending it to any mailing list first). If it's a patch that needs merging, maybe I could either send it to wine-patches or directly to you?
On Friday 01 November 2002 06:47 am, Ove Kaaven wrote:
On Thu, 31 Oct 2002, Greg Turner wrote:
On Thursday 31 October 2002 06:08 pm, Ove Kaaven wrote:
Note that I will work on ReWind, not directly on Wine, so I probably won't be able to submit massive "change all files to include this instead of that" patches (that apply to Wine) with any new files.
I get the ReWind-patches digest. I'd be happy to continue merging your changes back into wine, at least insofar as I know how... but will they all funnel through that list, or do I need to watch cvs?
I haven't decided yet. But I probably won't send to rewind-patches, since I don't usually use that list (if it's something useful to Wine, I'd just send a patch to wine-patches and have the rewind patch tracker pick it up from there. But if it's not useful to Wine, I commit it directly to rewind without sending it to any mailing list first). If it's a patch that needs merging, maybe I could either send it to wine-patches or directly to you?
Last night, I caved, and checked out ReWind from CVS, and set up my little scripts to keep track of changes... so just proceed as normal and I'll keep my eye on it. This weekend I will also try and whip up a roll-up patch for ReWind with all unmerged RPC stuff.
Nevertheless, don't hesitate to send stuff my way if you think it will make my work easier, and of course, sending stuff to wine-patches is never a bad thing, even if only for the peer-review it gets.
Ove Kaaven ovehk@ping.uio.no writes:
I haven't decided yet. But I probably won't send to rewind-patches, since I don't usually use that list (if it's something useful to Wine, I'd just send a patch to wine-patches and have the rewind patch tracker pick it up from there. But if it's not useful to Wine, I commit it directly to rewind without sending it to any mailing list first). If it's a patch that needs merging, maybe I could either send it to wine-patches or directly to you?
Please don't send to wine-patches things that don't apply cleanly to the Wine tree, either merge them first or find someone to do it for you.
On 1 Nov 2002, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
I haven't decided yet. But I probably won't send to rewind-patches, since I don't usually use that list (if it's something useful to Wine, I'd just send a patch to wine-patches and have the rewind patch tracker pick it up from there. But if it's not useful to Wine, I commit it directly to rewind without sending it to any mailing list first). If it's a patch that needs merging, maybe I could either send it to wine-patches or directly to you?
Please don't send to wine-patches things that don't apply cleanly to the Wine tree, either merge them first or find someone to do it for you.
Can I bring your (apparently minor) widl changes into rewind, so that I can generate a diff from there that'll apply directly to wine?
Ove Kaaven ovehk@ping.uio.no writes:
Can I bring your (apparently minor) widl changes into rewind, so that I can generate a diff from there that'll apply directly to wine?
Not sure what I changed, if it's only a couple of lines you can certainly put them in. But still I would really appreciate if the things you send to wine-patches were generated from the WineHQ CVS; I get nervous when I see too many patch warnings, even if the patch applies.
On 5 Nov 2002, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
Can I bring your (apparently minor) widl changes into rewind, so that I can generate a diff from there that'll apply directly to wine?
Not sure what I changed, if it's only a couple of lines you can certainly put them in.
You added enum attr_type and changed stuff to use that instead of the bison tokens from y.tab.h (no real idea why). Probably around 30 lines.
But still I would really appreciate if the things you send to wine-patches were generated from the WineHQ CVS; I get nervous when I see too many patch warnings, even if the patch applies.
Well, I try to do a smoke test by doing a patch --dry-run against a clean wine tree. I'm also known to diff against the wine tree itself under certain circumstances, but in most cases it doesn't seem necessary.
Ove Kaaven ovehk@ping.uio.no writes:
You added enum attr_type and changed stuff to use that instead of the bison tokens from y.tab.h (no real idea why). Probably around 30 lines.
I think it was to fix a problem with header dependencies. Sure, you can merge that into rewind.
Well, I try to do a smoke test by doing a patch --dry-run against a clean wine tree. I'm also known to diff against the wine tree itself under certain circumstances, but in most cases it doesn't seem necessary.
It's not really necessary, but it would make my life easier. And especially if you already do a dry run it doesn't seem much more work to apply the patch into your wine tree and do a cvs diff from there.
On Wednesday 06 November 2002 12:50 pm, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
You added enum attr_type and changed stuff to use that instead of the bison tokens from y.tab.h (no real idea why). Probably around 30 lines.
I think it was to fix a problem with header dependencies. Sure, you can merge that into rewind.
Well, I try to do a smoke test by doing a patch --dry-run against a clean wine tree. I'm also known to diff against the wine tree itself under certain circumstances, but in most cases it doesn't seem necessary.
It's not really necessary, but it would make my life easier. And especially if you already do a dry run it doesn't seem much more work to apply the patch into your wine tree and do a cvs diff from there.
as usual, I'm happy to fill in any gaps between Ove's submissions and Alexandre's needs.
In case they are helpful for Ove or anyone else, here are my shitty, but handy, little scripts to generate "perfect" wine-patches compatible patches. They assume the presence of "wine" and "wine.test" directories in the same location. so, for example, let's say a full vanilla cvs wine exists at
/some/random/place/wine/
Just do
cd /some/random/place cp -a ./wine ./wine.test
Now hack on or patch /some/random/place/wine however you want. To generate a diff for all the changes, put the 3 attached scripts into /some/random/place/wine, with execute permissions, of course. The names are important, keep them. Now just do
cd /some/random/place/wine mkdir mydiffs ./bigdiff.full > mydiffs/patch_for_alexandre.diff
Out will come a beatiful diff ready for submission to wine-patches, including appropriate handling of any added or removed files.
There is no need to "make clean" in /some/random/place/wine before running the script -- but you may need to do so in /some/random/place/wine.test.
Oh, and if you create a new directory you'll need to do so in /both/ trees manually, the scripts don't handle missing directories very well.
What they do:
bigdiff: generates a diff between all files that exist in both trees bigdiff.new: generates a list of files that are only in one tree or the other. bigdiff.full: generates a full diff of all changes ready for submission to wine-patches, including diffing new/deleted files
These probably contain references to stuff peculiar to my tree, of course, but ought to work for anyone nevertheless. They are the result of incremental hacking over time and are a /terrible/ example of shell script design, and probably contain bugs, so you should audit the output manually before you hit the *send* button :)
Uh.. these are public domain, please feel free to slap your company name on these, and sell them, for millions of dollars, without sending me royalties -- just don't complain to me if they format your hard drive.
bigdiff.new: generates a list of files that are only in one tree or the other.
Interesting, using 8-bit encoding, it wraps even as an enclosure. Here's another try...
Ove Kaaven ovehk@ping.uio.no writes:
IDL-generated files would also eventually obsolete all the current wine/obj_*.h files, but those obj_* files seem to be somewhat more logically structured than MS's own IDL files, should we craft Wine's IDL files accordingly, and maybe have some top-level .idl files in include/ and some sub-.idl files under include/wine/, like it's done now in e.g. objidl.h?
No, I think we should follow the Microsoft way. Sure it's a mess, but so is the rest of the API anyway... And every time we tried to do things better than Microsoft we ended up having to revert it.
On 31 Oct 2002, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
IDL-generated files would also eventually obsolete all the current wine/obj_*.h files, but those obj_* files seem to be somewhat more logically structured than MS's own IDL files, should we craft Wine's IDL files accordingly, and maybe have some top-level .idl files in include/ and some sub-.idl files under include/wine/, like it's done now in e.g. objidl.h?
No, I think we should follow the Microsoft way. Sure it's a mess, but so is the rest of the API anyway... And every time we tried to do things better than Microsoft we ended up having to revert it.
Well, the current structure hasn't been reverted yet (probably because the componentization only breaks the MS files into sub-files that's all included from the MS-compatible file, it doesn't seem to try to restructure them in any other way). I was thinking of writing an objidl.idl that contained something like
import "unknwn.idl" /* included in the real objidl.h (encompasses wine/obj_base.h) */ import "wine/obj_misc.idl" import "wine/obj_channel.idl" ...
which would make the generated objidl.h file have
#include "unknwn.h" #include "wine/obj_misc.h" #include "wine/obj_channel.h" ...
much like Wine's current objidl.h file does. Then we wouldn't have to change all those COM-using .c file to stop including wine/obj_*.h (and I could more easily convert the files). Or would you really prefer getting rid of wine/obj_*.h?
Ove Kaaven ovehk@ping.uio.no writes:
Then we wouldn't have to change all those COM-using .c file to stop including wine/obj_*.h (and I could more easily convert the files). Or would you really prefer getting rid of wine/obj_*.h?
Yes, I want to get rid of them. They are a real pain to deal with, you need to get the include order just right otherwise it breaks. And they don't really make finding things easier anyway.
-
Alexandre Julliard -
Greg Turner -
Ove Kaaven