January 2004 - Wine-Devel - list.winehq.org

Re: uxtheme: lots of infrastructure

by Alexandre Julliard

Kevin Koltzau <kevin(a)plop.org> writes: > As far as inefficent that wasnt my concern as the data is only > loaded once at startup and never touched again > If it is an issue I will change this and resubmit Startup performance is definitely an issue. This is done for every app, and we are already doing way too much init work at startup, we should not add any more than strictly necessary. -- Alexandre Julliard julliard(a)winehq.com

Jan. 13, 2004

Re: wine/ windows/scroll.c include/user.h dlls/x11 ...

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > Yay! (I submitted a similar patch some time ago, but you > didn't like the {Start,End}GraphicsExposures functions. > I still think they are decent GUI abstractions :)): And I still disagree <g> > Speaking of these things, I also don't think the driver > should know about the caret. I see no need for the USER > driver to know anything about the caret, we can just always > implement it ourselves, no? Absolutely, and the patch has been in for quite some time now... -- Alexandre Julliard julliard(a)winehq.com

Jan. 12, 2004

Re: uxtheme: lots of infrastructure

by Kevin Koltzau

The reason I did that was because of the large quantity of data, it was easier to define unicode strings in resources then it is to do in code, and I got a free method of seperating part/state data for each class As far as inefficent that wasnt my concern as the data is only loaded once at startup and never touched again If it is an issue I will change this and resubmit On Monday 12 January 2004 04:57 pm, Alexandre Julliard wrote: > Kevin Koltzau <kevin(a)plop.org> writes: > > This is a ton of infrastructure for my future patches, and a full > > implementation of GetThemeDocumentationProperty which I primarilly > > used to test my INI file processing, and its now possible to set the > > current theme through the API..not that its much use to do that yet > > The part about storing the string maps as resources seems > unnecessarily complicated and inefficient. Why can't you store an > array directly in the code?

Jan. 12, 2004

Re: [WINEALSA] Add Midi IN support (take 3)

by Alexandre Julliard

Christian Costa <titan.costa(a)wanadoo.fr> writes: > Alexandre Julliard wrote: > >>This isn't thread-safe. >> > The function that uses them is a timer callback. You are right, this doesn't matter then. > Well, I intended, in later patches, to update the poll fds when > opening or closing devices and thus > avoid the retreival of poll fds each time. > But well, I can accomodate with your proposal at this for the moment > since I don't known if this is usefull. If you are planning to change it then that's fine, I can put it in as is. But if you are not sure, then it would be better to put in a fixed version for now. -- Alexandre Julliard julliard(a)winehq.com

Jan. 12, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Martin Fuchs

> > There are also a number of unneeded whitespace changes that make the > > patch larger than it should be. > > Yes, I tried to make some functions I had to alter a bit more readable. > What about running a pretty printer, for example astyle > (http://astyle.sourceforge.net/) > on the whole code (or at least the shell32 directory) ? > Some sections are currently indented with 2, some with 4 and some with > 8 spaces - even mixed in the same function. This was no joke. If you say, you would accept such as reformating patch, I can easyly create one that eliminates all tab-characters, and generates nice and uniform indented code. This will make it a bit easier to create the small self-contained patches you want to see instead of the big one. As additional bonus you will get a very better formated shell32 code base. Regards Martin

Jan. 12, 2004

Re: wine/ windows/scroll.c include/user.h dlls/x11 ...

by Dimitrie O. Paun

On Mon, 12 Jan 2004, Alexandre Julliard wrote: > Log message: > ScrollDC doesn't need to be in the graphics driver. Yay! (I submitted a similar patch some time ago, but you didn't like the {Start,End}GraphicsExposures functions. I still think they are decent GUI abstractions :)): http://www.winehq.com/hypermail/wine-patches/2002/09/0196.html Speaking of these things, I also don't think the driver should know about the caret. I see no need for the USER driver to know anything about the caret, we can just always implement it ourselves, no? http://www.winehq.com/hypermail/wine-patches/2002/09/0174.html I think there is a bug in the above patch (IIRC, I used to get some freezing in certain situations), but the idea still stands. -- Dimi.

Jan. 12, 2004

Re: [WINEALSA] Add Midi IN support (take 3)

by Christian Costa

Alexandre Julliard wrote: >Christian Costa <titan.costa(a)wanadoo.fr> writes: > > > >>+static int npfd; >>+static int pfd_array_size = 0; >>+static struct pollfd *pfd = NULL; >> >> > >This isn't thread-safe. > The function that uses them is a timer callback. > Why don't you simply allocate the array in the >function and free it when you are done? > > > Well, I intended, in later patches, to update the poll fds when opening or closing devices and thus avoid the retreival of poll fds each time. But well, I can accomodate with your proposal at this for the moment since I don't known if this is usefull. Bye, Christian

Jan. 12, 2004

Re: stray file

by Steven Edwards

--- Hans Leidekker <hans(a)it.vu.nl> wrote: > It must be a leftover from a configure run. I suspected my own tree > but > but it came back after I removed it and did a cvs update. I have seen it before and always thought it was supposed to be there. =) Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 12, 2004

Re: uxtheme: lots of infrastructure

by Alexandre Julliard

Kevin Koltzau <kevin(a)plop.org> writes: > This is a ton of infrastructure for my future patches, and a full > implementation of GetThemeDocumentationProperty which I primarilly > used to test my INI file processing, and its now possible to set the > current theme through the API..not that its much use to do that yet The part about storing the string maps as resources seems unnecessarily complicated and inefficient. Why can't you store an array directly in the code? -- Alexandre Julliard julliard(a)winehq.com

Jan. 12, 2004

Re: [WINEALSA] Add Midi IN support (take 3)

by Alexandre Julliard

Christian Costa <titan.costa(a)wanadoo.fr> writes: > +static int npfd; > +static int pfd_array_size = 0; > +static struct pollfd *pfd = NULL; This isn't thread-safe. Why don't you simply allocate the array in the function and free it when you are done? -- Alexandre Julliard julliard(a)winehq.com

Jan. 12, 2004

Re: [Janitorial] ResetDCA->ResetDCW

by Vincent Béron

Le lun 12/01/2004 à 02:35, Dmitry Timoshkov a écrit : > "Vincent Beron" <vberon(a)mecano.gme.usherb.ca> wrote: > > > Changelog: > > Get rid of a W->A crosscall (ResetDCA->ResetDCW). > > > -HDC WINAPI ResetDCW( HDC hdc, const DEVMODEW *devmode ) > > +HDC WINAPI ResetDCA( HDC hdc, const DEVMODEA *devmode ) > > { > > - return ResetDCA(hdc, (const DEVMODEA*)devmode); /* FIXME */ > > + DEVMODEW *devmodeW; > > + HDC ret; > > + > > + if (devmode) devmodeW = GdiConvertToDevmodeW(devmode); > > + else devmodeW = NULL; > > + > > + ret = ResetDCW(hdc, (const DEVMODEW*)devmode); > > It would be better to pass a real, newly allocated DEVMODEW* to > ResetDCW(). That way you shouldn't need to cast type of a pointer. Actually, devmodeW is already a real DEVMODEW, but I kept devmode in the ResetDCW call. Stupid me. I'll resend. Vincent

Jan. 12, 2004

Re: stray file

by Marcus Meissner

On Mon, Jan 12, 2004 at 09:12:54PM -0500, Hans Leidekker wrote: > > Hi, > > There's a stray file, dlls/checklink.c, in Wine CVS with these contents: > > int main(void) > { > return 0; > } > > It must be a leftover from a configure run. I suspected my own tree but > but it came back after I removed it and did a cvs update. No, it belongs there. It is for missing symbol checking. Ciao, Marcus

Jan. 12, 2004

Re: [ros-kernel] RE: #2 - Mdi Win16/32 Split

by Dimitrie O. Paun

On Mon, 12 Jan 2004, Steven Edwards wrote: > http://cvs.reactos.com/cvsweb.cgi/reactos/subsys/system/regedit/ BTW, I don't know who "weiden" is (he seems to have made all the commits), maybe he can help me with this questions. Does the commit with this log: updated regedit (and some minor changes) mark a resync with the Wine CVS? I think we have to come up with a protocol in the future (maybe we can sit down with Alexandre at WineConf and discuss this) so that I'll be able to tell in the future with _what_ version of regedit in the Wine tree was this resynched from. Right now you're making changes on your tree, we on ours, the result is a hard to figure out mess. We really need to fix this somehow. -- Dimi.

Jan. 12, 2004

Re: [ros-kernel] RE: #2 - Mdi Win16/32 SplitB

by Dimitrie O. Paun

On Mon, 12 Jan 2004, Steven Edwards wrote: > Mainly we just converted the bitmaps to icons and made > it look more like Windows regedit. Also there are some fixes for > writting string values. > > http://cvs.reactos.com/cvsweb.cgi/reactos/subsys/system/regedit/ I will try to extract stuff, thanks, but by glancing over the thing, the CVS log is not too informative: -- some more fixes -- more improvements -- updated regedit (and some minor changes) Yes, changes were made. That I know, no need to restate it in the log :))) This goes in part to the big patch problem we were discussing. By having unstructured commits in CVS like this, it's going to be real hard to come up with meaningful patches. -- Dimi.

Jan. 12, 2004

Re: [ros-kernel] RE: #2 - Mdi Win16/32 Split

by Steven Edwards

--- "Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote: > WineConf will a good chance to flush these things out. You guys > should > assemble a list of problems (as seen on your end), and we should try > to come up with a plan that maximizes the amount of files you can > reuse > "as is" (keyword: "as is"). We are going to put together a action list in a few days for Wineconf. I and two other ReactOS developers that I know of will be attending so we will have plenty to talk about. Also on the code sharing side we have some nice enhancments to regedit that you guys may want to merge. I wont have the time to do a diff of Winehq vs ReactOS cvs for a while so if you want to pick over Thomas's code feel free. Mainly we just converted the bitmaps to icons and made it look more like Windows regedit. Also there are some fixes for writting string values. http://cvs.reactos.com/cvsweb.cgi/reactos/subsys/system/regedit/ Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 12, 2004

Re: [ros-kernel] RE: #2 - Mdi Win16/32 Split

by Dimitrie O. Paun

On Mon, 12 Jan 2004, Steven Edwards wrote: > 1. They dont add much to WINE except cleaning up the TWEAK_WINELOOK > stuff. I would have already started sending patches to remove this code > from Winehq but I am wanting uxtheme to come along a little more so we > can see if we can create a Win 3.1 theme before I throw all of the > Win3.1 style support out the Window. Well, I personally think we should get rid of the Win31 look -- it's dated, and I don't think people still use it. If they do, the way to implement it is through uxtheme. And if there is enough motivation to move it there (even though I doubt there will be without users), the code can always be found in the CVS archive. > 2. We have quite a few hacks in our support of the controls. In quite a > few cases such as Menu and Scrollbar support its not just a matter of a > recompile but a major rewrite. If you guys want to share more code then > I will create a dummy implementation of Win32k.sys for WINE so we can > share everything. We should have these discussions more often, and you guys should push for ways to share as much code as possible. Right now these thing come out once in a blue moon during a heated argument, and we just find out that you can't share more code because of this hack or another. This is just justification for the current situation instead of a more proactive stance to correct it. WineConf will a good chance to flush these things out. You guys should assemble a list of problems (as seen on your end), and we should try to come up with a plan that maximizes the amount of files you can reuse "as is" (keyword: "as is"). -- Dimi.

Jan. 12, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Steven Edwards

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > There is csgrep in the tools/ module in CVS, but for that > to work you guys need to run our commit_prep and log_accum > in CVSROOT. If you do that, you get the wine-cvs - type > messages for free, and can use our patch.py script to > generate patches. From what I see in other similar systems > (used in projects such as SourceForge/gcc/KDE/etc.), ours > is the best -- comes highly recommended! ;) This would be nice anyway as our CVS commits dont currently show anything but the filenames of what was changed. Our CVS maintainer said he wasnt opposed to setting this up a while back to maybe this will be what we will have to do. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 12, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Dimitrie O. Paun

On January 12, 2004 09:14 am, Steven Edwards wrote: > There has to be a more simple way of us diffing our patches. Would any > of the scripts you use on Crossover merging help us? There is csgrep in the tools/ module in CVS, but for that to work you guys need to run our commit_prep and log_accum in CVSROOT. If you do that, you get the wine-cvs - type messages for free, and can use our patch.py script to generate patches. From what I see in other similar systems (used in projects such as SourceForge/gcc/KDE/etc.), ours is the best -- comes highly recommended! ;) -- Dimi.

Jan. 12, 2004

Re: [ros-kernel] RE: #2 - Mdi Win16/32 Split

by Steven Edwards

Hi, --- Ge van Geldorp <ge(a)gse.nl> wrote: > I am more than willing to do a little bit of extra work to keep our > trees in synch but the simple fact remains that if the only way to > get > something accepted into Wine is to create a new Win95 installation > and > see how things work there I'm probably not going to bother. I do quite a bit of work to keep things in sync and thats by working as much as I can by working out of winehq CVS but that doesnt mean the rest of the ReactOS developers are going to follow. I still try to merge thier patches as I can but I am only one person. A big part of the problem with us merging some of the changes for the controls back in is: 1. They dont add much to WINE except cleaning up the TWEAK_WINELOOK stuff. I would have already started sending patches to remove this code from Winehq but I am wanting uxtheme to come along a little more so we can see if we can create a Win 3.1 theme before I throw all of the Win3.1 style support out the Window. 2. We have quite a few hacks in our support of the controls. In quite a few cases such as Menu and Scrollbar support its not just a matter of a recompile but a major rewrite. If you guys want to share more code then I will create a dummy implementation of Win32k.sys for WINE so we can share everything. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 12, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Steven Edwards

Hiya M8, --- Alexandre Julliard <julliard(a)winehq.org> wrote: > I know it's a pain, but the real solution for next time is to submit > things as soon as they are done, instead of waiting a month and then > sending a huge patch that cannot possibly be reviewed. There has to be a more simple way of us diffing our patches. Would any of the scripts you use on Crossover merging help us? Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 12, 2004

Re: shell32 patches to be usable by ReactOS Explorer

by Martin Fuchs

On 12.01.2004 01:41:45 Alexandre Julliard wrote: > "Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > > > Mhh - could you please tell me which "ugly hacks" you are speaking of? > > From a quick look at the patch, what I noticed is mostly the ifdefs > and other various disabling/commenting out of parts of the code. We had to disable some calls to internal functions, which are only exported from WINE, no real Windows OS. > There are also a number of unneeded whitespace changes that make the > patch larger than it should be. Yes, I tried to make some functions I had to alter a bit more readable. What about running a pretty printer, for example astyle (http://astyle.sourceforge.net/) on the whole code (or at least the shell32 directory) ? Some sections are currently indented with 2, some with 4 and some with 8 spaces - even mixed in the same function. Regards, Martin

Jan. 12, 2004

Re: [Janitorial] ResetDCA->ResetDCW

by Dmitry Timoshkov

"Vincent Beron" <vberon(a)mecano.gme.usherb.ca> wrote: > Changelog: > Get rid of a W->A crosscall (ResetDCA->ResetDCW). > -HDC WINAPI ResetDCW( HDC hdc, const DEVMODEW *devmode ) > +HDC WINAPI ResetDCA( HDC hdc, const DEVMODEA *devmode ) > { > - return ResetDCA(hdc, (const DEVMODEA*)devmode); /* FIXME */ > + DEVMODEW *devmodeW; > + HDC ret; > + > + if (devmode) devmodeW = GdiConvertToDevmodeW(devmode); > + else devmodeW = NULL; > + > + ret = ResetDCW(hdc, (const DEVMODEW*)devmode); It would be better to pass a real, newly allocated DEVMODEW* to ResetDCW(). That way you shouldn't need to cast type of a pointer. -- Dmitry.

Jan. 12, 2004

Re: #2 - Mdi Win16/32 Split

by Dimitrie O. Paun

On January 11, 2004 09:56 pm, Ge van Geldorp wrote: > o you guys really believe that a pile of 107 > patch mails while Alexandre was unavailable would have been a better > idea? Absolutely. It's way better than a big huge patch. A huge patch is meaningless for anybody reviewing, we can just put it in and hope it works. Smaller patches have _many_ advantages: -- can be easily reviews -- since people can understand them, they can comment on them -- these discussions result in a lot of useful information -- all this info gets archived for future hackers (_very_ useful)\ -- even if the patches are bad, they document a dead end so others don't have to waste time going there ... and so on ... Yes, you seem to be frustrated by the tight control that Alexandre uses on the Wine tree. I know, I've been many times, and I can tell you that I've got worked up over this a number of times. But I'd be hard pressed to look back and list a single instance where he wasn't correct in rejecting my changes. Also, you don't seem to appreciate that you get access to a _huge_ codebase of high quality code. And the reason it's good code, it's because of this tight control. I am sorry to say but I've sensed a bit of a "if you don't like it, screw you" attitude, and that's not helpful. We've tried hard to make our code useable as much as possible "as is" in you tree, because we believe cooperation will help both our projects. This attitude is not at all in this spirit. And if you think you can just fork the Wine codebase, and take it from here, you're only going to shoot yourself in the foot. We went over this issue before, I think we all understand we need to work together on this one, if we are to get some decent results before the turn of this (very young) century... -- Dimi.

Jan. 12, 2004

Re: [Janitorial] ResetDCA->ResetDCW

by Dimitrie O. Paun

On January 11, 2004 03:43 pm, Vincent Béron wrote: > Dimi, do you prefer to keep track of progress on this yourself, or > should I send a patch for the janitorial page too? It would be great if you'd send the update to the janitorial page. I try to keep track, but it's so much easier if patch authors lend a hand. But please wait until Alexandre commits it. -- Dimi.

Jan. 12, 2004

RE: #2 - Mdi Win16/32 Split

by Ge van Geldorp

> From: Dimitrie O. Paun > Sent: Monday, January 05, 2004 05:33 > > On January 2, 2004 01:12 pm, Steven Edwards wrote: > > http://cvs.reactos.com/cvsweb.cgi/reactos/lib/user32/controls/ > > Is a good example of a place where we have been able to > > import a large chunck of WINE user32 code without a lot of > > nasty changes. > > BTW, did any of the fixes from your tree been ported back to > Wine? I guess not, and that's just not nice. You guys need to > adopt a decent system of keeping track of what sources where > imported from Wine, what got merged back to Wine, etc. I'd be > willing to help, if you guys are interested. One of the first controls to be ported was the static control. I submitted the fixes back to Wine, but the patch was dropped, 'cause someone said one of the flags worked a little bit differently on Win95/98. Well, guess what, I really don't care about 95/98 and I'm certainly not going to install it to figure it out. I think Casper Hornstrup had a similar experience recently with a LockResource16 call in ole32.dll. Ofcourse, I do realize that patches are dropped for good reasons (I submitted a patch to comctl32 recently where someone pointed at a better solution), but in general I get the feeling that I should be thankful if a patch gets accepted. Another case is the mega-shell32 patch that Martin Fuchs submitted. Serious work on shell32 began around 17 dec, just as Alexandre was about to go on vacation. So we (actually, 95% of the work was done by Martin) used the ReactOS CVS repository. I just counted, there were 107 separate commits to shell32 between 17 Dec and 02 Jan (I can't count the commits after 02 Jan easily). Do you guys really believe that a pile of 107 patch mails while Alexandre was unavailable would have been a better idea? I am more than willing to do a little bit of extra work to keep our trees in synch but the simple fact remains that if the only way to get something accepted into Wine is to create a new Win95 installation and see how things work there I'm probably not going to bother. Gé van Geldorp.

Jan. 12, 2004