March 2007 - Wine-Devel - list.winehq.org

Re: [try3, 1/4] msi: Added handlers for JScript/VBScript actions that call one script function.

by James Hawkins

On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > I am resending the entire patchset as James Hawkins suggested. The only > changes from my previous patchset are in patch #2 (add full IDL from > Windows Installer 3.0 vs 2.0 in the old patchset) and patch #3 (added > more proper variant handling using GetDispId as per Rob's suggestion and > removed unnecessary comments as per James' suggestion). > > Just as a reminder, these patches add JScript/VBScript support for > MSI (as the MSI specs specifically state that applications that need > this functionality must install Windows Script themselves) and partial > but easily expandable OLE automation functionality for MSI. As a proof > of concept, sufficient automation support is added to fix bug #7357. > > Patch #1 creates custom action handlers for all 8 script custom action > types using a framework similar to that used for calling DLL functions. > These custom action handlers all converge on one function that is passed > a script and a function to be called (if any), and it outputs these in a > FIXME. > > Changelog: > > * msi: Added handlers for JScript/VBScript actions that call one script > function. > +static DWORD WINAPI ACTION_CallScript( const LPGUID guid ) +{ + msi_custom_action_info *info; + MSIHANDLE hPackage; + UINT r = ERROR_FUNCTION_FAILED; + + info = find_action_by_guid( guid ); + if (!info) + { + ERR("failed to find action %s\n", debugstr_guid( guid) ); + return r; + } + + FIXME("function %s, script %s\n", debugstr_w( info->function ), debugstr_w( info->dllname ) ); + + hPackage = alloc_msihandle( &info->package->hdr ); + if (hPackage) + { + r = S_OK; + MsiCloseHandle( hPackage ); + } + else + ERR("failed to create handle for %p\n", info->package ); + + return r; +} Looks like you're leaking info. If you're going to go down this route, leaving a stub ACTION_CallScript, then just print the FIXME and be on your way. Each patch should be atomic, and assuming this patch gets applied but none of the others do, you're left with some weird code that allocates a handle then frees it for no apparent reason. + r = MSI_RecordReadStream(row, 2, buffer, &sz); + if (r != ERROR_SUCCESS) + { + msi_free(buffer); + return r; + } + + buffer[sz] = 0; + szw = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, 0); + bufferw = msi_alloc(sizeof(WCHAR)*szw); + if (!szw) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } + + r = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, szw); + msi_free(buffer); + if (!r) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } This would be a lot cleaner if you used a 'goto done;' at each of these error points. Also, is there a reason you're not using strdupAtoW? done: msi_free(bufferw) ... return r; -- James Hawkins

March 1, 2007

Re: Forum proposal

by Carl-Daniel Hailfinger

On 01.03.2007 23:25, Alexandre Julliard wrote: > Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> writes: > >> Now imagine a breakin on a site hosted on winehq. The consequences >> would be far worse than for the average toy project. Wine depends on >> people trusting us that the code is legally clean (especially due to >> various FUD campaigns claiming otherwise). A breakin will always >> result in claims that the codebase has been polluted with MS code. > > You cannot modify the codebase even if you break into the server. > Everything in the git repository is authenticated by its SHA-1, so any > change would be immediately noticed. I know about this special feature of git (basically not only every file is identified by its SHA-1 hash, but also the complete timeline and with that the complete repository are secured with SHA-1). There was a post on the linux-kernel list some time ago about this topic. However, in case of a breakin there will always be somebody without this knowledge writing about the breakin. And nobody will read what we have to say about the security of git because the first article has always more readers than any followup or response. Regards, Carl-Daniel -- http://www.hailfinger.org/

March 1, 2007

Re: Forum proposal

by Alexandre Julliard

Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> writes: > Now imagine a breakin on a site hosted on winehq. The consequences > would be far worse than for the average toy project. Wine depends on > people trusting us that the code is legally clean (especially due to > various FUD campaigns claiming otherwise). A breakin will always > result in claims that the codebase has been polluted with MS code. You cannot modify the codebase even if you break into the server. Everything in the git repository is authenticated by its SHA-1, so any change would be immediately noticed. -- Alexandre Julliard julliard(a)winehq.org

March 1, 2007

Re: Forum proposal

by Wojciech 'arab' Arabczyk

Hello > Have you ever logged onto the IRC channels? Their seems to be a > healthy community built up around them. Have You ever been on a chann witch 1000+ users? Believe me, that's not a healthy community - it's noizzzzze: -- user x joined -- user y parted (loop indefinetly) But i've been on forums with 2k+ users, and they're still readable. Still - i'm not advocating for a forum - a mailing-list is still perfeclty readable as far as i'm concerned. Tho i do know, that many younger people have no clue about mailing lists, or how to even subscribe, on the contrary they can point a browser and easily register/log in on a forum. -- Best regards Wojciech Arabczyk

March 1, 2007

re: Forum proposal

by Dan Kegel

Wojciech wrote: >But there's one thing with forums that IMVHO mailing-lists can't do. TBMS >forums build better comunities than mailing-lists. Mailing lists are just >concentrated on the topics, disallowing any OT. Good. Let's keep it that way. I think we have a great community as it is. If you really want a web interface that makes posting to the mailing list easy, maybe we could get Google Groups to carry wine-devel. It's as close to a nice web interface as you're going to get, I think. The other gateways I've seen between 'forums' and mailing lists all sucked, IMHO. - Dan

March 1, 2007

Re: [final, sorry] msi: Expand IDL file to contain all OLE automation interfaces.

by Misha Koshelev

On Thu, 2007-03-01 at 12:46 -0800, James Hawkins wrote: > On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > On Thu, 2007-03-01 at 12:29 -0800, James Hawkins wrote: > > > On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > Ok, sorry about posting patches to uncomitted patches, I have > > > > reintegrated these changes back into my patches. The change in this > > > > patch is the IDL file now contains all OLE automation interfaces as of > > > > native installer version 3.0 (as opposed to 2.0). > > > > > > > > As a reminder this is part 2 of 4 of my patchset: > > > > > > > > 1. > > > > http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html > > > > 2. This patch > > > > 3. Next patch > > > > 4. > > > > http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html > > > > > > > > > > You need to resubmit the whole series if you resubmit parts of it. > > > > > > > I feel bad crowding the wine-patches list with my posts and I sent > > Alexandre an email with the URLs to all four patches. Do you think I > > really need to send all four again? > > > > Misha > > > > 1. > > http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html > > 2. http://www.winehq.org/pipermail/wine-patches/2007-March/036541.html > > 3. http://www.winehq.org/pipermail/wine-patches/2007-March/036542.html > > 4. > > http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html > > > > That's the way the submission process works. Also, you should > append/prepend a [tryX], where X is the number of times you've tried > to send this in before + 1, so we know exactly which patch emails are > the most up to date. > Ok, I resent them. Misha

March 1, 2007

Re: Forum proposal

by Matt Finnicum

> But there's one thing with forums that IMVHO mailing-lists can't do. TBMS > forums build better comunities than mailing-lists. Mailing lists are just > concentrated on the topics, disallowing any OT. With a forum you can easily > moderate a "on-topic only" subforum, allowing people to exchange opinions in > other forums. Have you ever logged onto the IRC channels? Their seems to be a healthy community built up around them. --Matt Finnicum (aka 'murph')

March 1, 2007

Re: DIB Engine & GSoC

by Benoit Pradelle

First thank you for your very complete answer, I'm not really familiar with Wine (and the Windows API) and I don't understand why do you think that it will be such an hard work. For me, the work will consist in redirect the GDI calls from the X11 pseudo-driver to some new functions which will draw circles, lines, etc.. over DIBs. Do I misunderstand the work to do or under evaluate it ? And I've understand by reading this mail-list how important are regression tests and fluent transitions in functionalities for Wine. Stefan Dösinger a écrit : > Am Donnerstag 01 März 2007 14:03 schrieb Benoit Pradelle: > >> Hi, >> >> I would like participate to the Google Summer Of Code with Wine by >> implementing a DIB Engine. I've searched a lot of informations about the >> DIB Engine but i still got one question : >> for you, how important is a DIB Engine in Wine ? >> > Hard to say, it depends on what applications are needed. > > If I said now "the most important thing" that would be obviously wrong, > otherwise someone would have implemented it already. I'd say it is one of the > top ranked items, but it requires a lot of work and a LOT of knowledge by the > programmer. From the importance vs work required it is rather low. > > The DIB engine would help applications which operate on DIB sections with both > direct access and GDI commands. For example DirectX games which use > IDirect*Surface?::GetDC regularly, or other applications(I think MS > powerpoint is one of them). It will not help Direct3D applications which do > not use GetDC. > > It would also allow is a X-Server / <Apple something> independent GDI > implementation. Right now our GDI implementation can only do what the X > server can do - not more. > > Another question is if the existing implementation using the X server can't be > optimized. One inefficient thing is that always the full DIB section is > converted and copied over. That is technically not necessary when a small > letter is drawn to the top left corner. Of course optimizations tend to be > tricky, and maybe do not compare with the cost/usability of a real DIB > engine. Maybe DirectDraw can be optimized too, by moving the depth conversion > from GetDC calls to surface locking. This would only shift the problem, but > if DDraw can read the state of the DIB section it could choose the most > efficient solution depending on the behavior of the game. > > Another thing that should be checked before starting is if a fluent transition > is possible. For example, when a new dibsection DC is created, create a > classic dib section and a DC using the server. If the app does something the > new code can't do yet, load the data into the server and use the existing > X-Server GDI code. This way a fluent transition is possible, with > implementing the important calls first, then adding rare things while still > keeping full functionality. > > Just some thoughts from my side. If you want this as a SOC project you will > need some menthor, and I think Alexandre is the only one who can do that for > implementing a DIB engine :-) > > ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com

March 1, 2007

Re: Forum proposal

by Wojciech 'arab' Arabczyk

Hello (flamines: +10) > Most people who use webforums are too stupid or lazy to set up or use an > SMTP/IMAP/NNTP client. Can't argue 'bout that. After all i'm just a stupid forum user. But there's one thing with forums that IMVHO mailing-lists can't do. TBMS forums build better comunities than mailing-lists. Mailing lists are just concentrated on the topics, disallowing any OT. With a forum you can easily moderate a "on-topic only" subforum, allowing people to exchange opinions in other forums. Just my random thoughts 'bout forums. -- Best regards Wojciech Arabczyk

March 1, 2007

Re: Forum proposal

by Felix Nawothnig

(Score:-1, Flaimbait) Wojciech 'arab' Arabczyk wrote: > Well - one could setup a forum<->mailing list gateway. Not easily doable due to the nature of SMTP. Also a forum would be completly useless for anything but wine-users... But let's be honest here: Most people who use webforums are too stupid or lazy to set up or use an SMTP/IMAP/NNTP client. And don't get me even started about usability of most forums, especially phpBB and the like. No proper threading but cool animated avatars, ranks and post counts... Yes, there is RForum (and I believe someone actually wrote an SMTP gateway for it) and others but I doubt it would be worth the hassle. And it's not like we are short of bug reports - do we really want to deal with people who will post on a forum but refuse or are unable to sign on at an ML? However - a new web-interface for the ml-archives would be nice (with integrated search, no silly month-splits and... well... a somewhat prettier design IMHO. Gmane is there but I usually end up using google on the winehq archives though... Felix

March 1, 2007