Re: Generating patches from commit logs
On Wed, Aug 30, 2000 at 06:27:53AM +0200, Ove Kaaven wrote: On Tue, 29 Aug 2000, Dimitrie O. Paun wrote: -- the CGI program must reside on the CVS machine as it needs access to the commit log; the name of the machine gets hardcoded in the commit log entry. You don't need to be on the CVS machine to get the commit logs for each file. You can use the "cvs log" command. Marcus has a couple of Perl scripts to generate diffs from the Corel Wine tree using "cvs log" and "cvs diff" with the returned revision tags... it probably gives the server some load, but it otherwise works entirely client-side. If you want them, drop me a mail. But they do cause rather high load both on the server and network, if being run for the first time. (diffs every file for every version). It would be better and nicer if the wine-cvs log_accum script could generate mails that include the revisions of the affected files (could even send to another mailinglist wine-cvs-verbose or similar). Ciao, Marcus
Re: Generating patches from commit logs
On Wed, 30 Aug 2000, Marcus Meissner wrote: It would be better and nicer if the wine-cvs log_accum script could generate mails that include the revisions of the affected files (could even send to another mailinglist wine-cvs-verbose or similar). This is exactly what I did. Is my proposed solution acceptable? -- Dimi.
Re: possibility for massive wineserver speedup
Jeremy White [EMAIL PROTECTED] wrote: Wow. This is the coolest new idea I've seen posted to wine-devel for a while. Thanks *grin*. I suspect it has many hurdles and may never be practical with Wine, but I would really love to run winbench with Wine and have the numbers be faster than that of NT... (I'm not going to try to address the issues; I suspect that better minds than mine [e.g. Alexandre] will weigh in with a more complete analysis). Oh, I don't know, I think in some ways it is very practical. My thought is that anything it can't handle easily or quickly can be passed transparently to a server process to be done in userspace (ie: registry maintainance and access). As for not currently being compilable against Linux 2.2, I think that can be solved fairly easily. Do you mind if I ask what prompted you to undertake this process? I like kernel programming, I'd like to see Wine go faster (I've tried stracing it and seen the absolute mass of wineserver interactions flying past). On a more practical note, I run the PVCS command line tools (version control) under Wine at work, and they could be faster (they're implemented in threaded Java - yuk), so I recon this could speed them up a bit. I also occaisonally run the MSDEV command line compiler under Wine, and that could be a lot faster too. David Howells
Re: Generating patches from commit logs
This is pretty impressive stuff! We have a system here for our production repository that updates a web page with the log messages and links to CVSWeb for each file changed in each commit. It works, but the whole patch view is still hard to get. However, I have used the date of the commit to get "cvs diff -D date1 -D date2" to give me the real changes. CVS "diff" can give the diff between two timestamps (I'm not too sure about what happens with added and deleted files) Maybe generating that line as part of the commit log sent to wine-cvs would be a good stopgap? Yes one would have to cut and paste it to the shell of your choice, but then you get to play with it as you see fit. For example here is a recent post to wine-cvs: Alexandre Julliard wrote: CVSROOT:/opt/cvs-commit Module name:wine Changes by: julliard@wine2. 00/08/29 19:55:06 Modified files: dlls/dplayx: dplay.c dplay_global.h dplaysp.c dplaysp.h dplayx_messages.c dplayx_messages.h name_server.c Log message: Peter Hunnisett [EMAIL PROTECTED] - More implementation - Should be able to enumerate sessions anywhere with at least tcp/ip I would add the following lines } To view the patch given a wine tree checked out from cvs.winehq.com } execute } cvs diff -D "2000-08-29 23:54:00 UT" -D "2000-08-29 23:55:06 ut" I would be quite happy with this setup :) Another way to do this that would be better for the longer term would be to extend CVSWeb to do what you have described below. Albert "Dimitrie O. Paun" wrote: Hi people, For the longest time I wanted to be able to look at some of the changes that make it into the repository. It is a great way to review code, follow the latest changes, and understand/learn new code areas. For the time being, one can (partially) do that by reading the diffs sent out by Alexandre with each release. However, they are _very_ big, and one can not easily separate the logical changes from one another. Instead, what I was looking for was more on the lines of somehow being able to easily look at the diff associated with any of the email messages sent to wine-cvs list. That is, have a link sent out together with the message on which I can click to view the respective diff. Now, wanted this feature so badly that I actually went ahead and implemented it! :))) Here is the idea: -- generate a ID for each message sent out -- include it in the message along with a summary of changes -- include a link in the message that passes to a CGI program the ID of the commit -- the CGI program searches the commitlog, extracts the summary info and generates the patch It works. I am not 100% happy with the implementation, but it is good enough to be used in practice (it is used in production at my workplace). Here is a list of issues with the current implementation: -- the generated diff includes only the changes, it does not include the added or deleted files. What to do with those? -- the CGI program must reside on the CVS machine as it needs access to the commit log; the name of the machine gets hardcoded in the commit log entry. Not a big deal in Wine's case I think, as cvs.winehq.com is not likely to change. -- the program does a linear scan of the commit log, so in the long term, we can have problems. I would like to have each log message saved in a file in some sort of directory structure (I was considering: commitlog.d/year/week of year/id of msg) That would be much better and I would be happy to implement it if no one objects to it. How does the thing looks like? Well, here is a log message generated as explained above: message ChangeSet ID: 967585195303215279709548 CVSROOT: /usr/local/cvsroot Module name: evolve-client Changes by: [EMAIL PROTECTED] 00/08/29 17:39:55 Modified files: com/esolutions/mdl/dbaccess: AbstractUpdater.java ClientUpdater.java com/esolutions/mdl/logger: CreateLog_XML.java LogRecord.java UpdateLog.java Log message: Sync: fixed problem when there are more than one meta columns with the same table/field names in a meta object. Patch: http://cvs/patch?root=/usr/local/cvsrootlogs=/usr/local/cvsroot/CVSROOT/evo lvelogid=967585195303215279709548 Revision ChangesPath 1.19 +38 -20 evolve-client/com/esolutions/mdl/dbaccess/AbstractUpdater.java 1.8 +4 -2 evolve-client/com/esolutions/mdl/dbaccess/ClientUpdater.java 1.9 +88 -125 evolve-client/com/esolutions/mdl/logger/CreateLog_XML.java 1.4 +7 -7 evolve-client/com/esolutions/mdl/logger/LogRecord.java 1.7 +23 -20evolve-client/com/esolutions/mdl/logger/UpdateLog.java /message Now, my mailer may have wrapped some lines, but you
Re: Thunking problem is partially solved
"Dmitry Timoshkov" [EMAIL PROTECTED] writes: I already had burned my fingers with the Wine's "register" calling convention in the spec-files. Function, declared as "register" in a spec-file, can do at return any thing, what it wants: i.e. removing or adding WINAPI, cdecl etc. in the c-file doesn't change anything, no crashes at all. Is it by design? Yes; register functions restore the full context on return, so anything the called function does with the stack is irrelevant. cdecl/stdcall has to be implemented by fixing the stack pointer in the context before returning. Patrik Stridvall [EMAIL PROTECTED] wrote: I think you ask the wrong question. It don't think it is anything to do with CallTo16 in itself. The problem might be that the argsize is wrongly calculated. It is possible that the way argsize is calculated by subtracting 0x40 only worked for the specific application that was tested. In fact even if the right value is larger, subtracting 0x40 should still work for all apps, we will simply be transferring too many arguments to the 16-bit stack. So the fact that it works with 0x40 does not necessarily prove it is the correct value; but I don't claim to understand this thunking stuff... -- Alexandre Julliard [EMAIL PROTECTED]
RE: isZeroSizeWnd in x11drv/wnd.c calculated wrongly ?
The real problem of Wine code is that it does not handle correctly the case when a window is created with a zero size, then it is resized to a non-zero size; it's not mapped in this case You're right about that. My code was assuming that rectWindow wasn't changed yet when entering in X11DRV_WND_SetWindowPos function, which was a false assumption. The attached patch fix the problem. Changed log: Force mapping a window if the window wasn't map, the window is visible and we are changing the size of the window. This case could occur, if the previous size was zero. Modified file: window/x11drv/wnd.c I would appreciate some comment of the person who wrote this code (hey, Stephane :)). (I'm confused by the winposPtr pointer; why not use wndPtr directly ? is there any case where the hwnd in winpos could be different from the hwnd in wndptr ?) You're right, winposPtr will always be the same as wndPtr. Maybe in the past it wasn't the case, and the code hasn't be updated. Stephane Lussier Macadamian Technologies zerosized.diff
Re: Thunking problem is partially solved
Dmitry Timoshkov wrote: Examining the disassembled text of pm65.exe, I noted, that PM pushes different number of bytes in different places in the code before call to QT_Thunk. I assume, that it is an exact number of bytes, that 16-bit callee will get as arguments and should pop from the stack with pascal16 function return type. Right. The problem is that we implement thunks differently than Win95 does, with the most important difference being that we actually have two seperate stacks per app, a 16-bit one and a 32-bit one, where Win95 has only *one* stack: 16-bit apps have their 16-bit stack, and when thunking to 32-bit, ESP is simply set to the appropriate 32-bit flat pointer pointing to the current 16-bit stack location; 32-bit apps have their 32-bit stack, and when thunking to 16-bit, a temporary SS selector is allocated that covers the current 'window' on the 32-bit stack. This means that Win95 does not in fact copy *any* arguments in QT_Thunk and the other thunking routines; they simply stay on the stack. Similarly, all modifications made to SP by the called routine are preserved, so if the 16-bit routine pops N argument bytes, those arguments will also be popped on the 32-bit stack after return of QT_Thunk. We, on the other hand, have to copy arguments to the 16-bit stack. Unfortunately, we don't know how *many* arguments to copy, thus we copy in fact the largest possible size (i.e. from ESP to EBP-0x40. EBP-0x40 is because the region EBP-0x40..EBP is a parameter block for use by QT_Thunk that has to be set up by the caller). As we don't know the actual argument size, we don't know how much to pop off the 32-bit stack either. This works fine if the caller of QT_Thunk is one of the thunk stubs generated by the MS thunk compiler (which is supposed to be the *only* code that ever calls QT_Thunk), because these stubs don't have any other local variables on the stack, and return to their caller immediately after QT_Thunk returned. Apparently, your app calls QT_Thunk manually, from within a routine that does in fact care about the proper ESP value after return of QT_Thunk. This unfortunately doesn't work with the current Wine code. To fix this, we'd need to find out how many bytes the 16-bit routine popped off the stack, which is currently not possible. I made some addtional traces to find out the way to properly calculate number of bytes popped by 16-bit function from the 16-bit stack, but failed. The problem is that the return path in CallTo16 restores proper 32-bit register values, without taking care of saving the values left in the registers by the 16-bit function (except for the return value in AX/DX). Thus, the caller has no way of finding out these values. One option to fix this problem might be to update the context structure on return. This is unfortunately a little tricky because of the peculiar way we perform the 16-32 bit transition. Furthermore it might have probably an adverse impact on performance ... Another way might be to change the arg_size parameter from a pure input parameter to in/out, and update this with the actual argument size (as popped by the called routine). I'll have to think about this ... Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
