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

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL? [FIXED]

by Molle Bestefich

Tony Lambregts wrote: > attached is the message source that I got throught gmane news server. Thanks. gmail seems to like to ruin line endings as much as Outlook does, so I've attached my reply to preserve the fine ASCII art :-). Please take a look... > (I do not get emails from wine patches even though I am subscribed...) Oh, ok.

Jan. 28, 2006

Re: Wine-wiki broken by design

by Dimi Paun

On Sat, January 28, 2006 1:25 pm, Molle Bestefich said: > SO, could someone *PLEASE* fix the Wiki so Google can index it??? Sure we can, no need to curse, just ask nicely. Or submit a patch. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Jan. 28, 2006

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL? [FIXED]

by Tony Lambregts

Molle Bestefich wrote: >Tony Lambregts wrote: > > >>http://www.winehq.org/pipermail/wine-patches/2006-January/023490.html >> >> > >Looks odd with all the MIME in there. > > > >>So... I went looking at the alternative and thought of >>GMANE and it turns out that this patch is not archived there at all. >> >> > >GMANE snips stuff with X-No-Archive set - just offering pointers. > >[snip body of email from Jonathan Ernst] > >Would you mind posting the entire email, including headers etc., as an >attachment? >I'd like to take a look at it too but I'm not subscribed to wine-patches =). > > > attached is the message source that I got throught gmane news server. (I do not get emails from wine patches even though I am subscribed...) Path: news.gmane.org!not-for-mail From: Jonathan Ernst <jonathan(a)ernstfamily.ch> Newsgroups: gmane.comp.emulators.wine.patches Subject: Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL? [FIXED] Date: Mon, 16 Jan 2006 15:05:21 +0100 Lines: 146 Approved: news(a)gmane.org Message-ID: <1137420321.19535.8.camel(a)localhost> References: <a71bd89a0601142200i129ec8f0peb4965721fd3c610(a)mail.gmail.com> <200601151021.k0FALevx017514(a)mailhost.geldorp.nl> <a71bd89a0601150740q21686c09lee0438f8318a6da8(a)mail.gmail.com> Reply-To: wine-devel(a)winehq.org NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0121623449==" X-Trace: sea.gmane.org 1137420449 22397 80.91.229.2 (16 Jan 2006 14:07:29 GMT) X-Complaints-To: usenet(a)sea.gmane.org NNTP-Posting-Date: Mon, 16 Jan 2006 14:07:29 +0000 (UTC) Original-X-From: wine-patches-bounces(a)winehq.org Mon Jan 16 15:07:24 2006 Return-path: <wine-patches-bounces(a)winehq.org> Envelope-to: comp-wine-patches(a)gmane.org Original-Received: from wine.codeweavers.com ([209.32.141.3]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EyV0w-0005FB-AD for comp-wine-patches(a)gmane.org; Mon, 16 Jan 2006 15:07:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by wine.codeweavers.com with esmtp (Exim 4.50) id 1EyUzk-00022z-RS; Mon, 16 Jan 2006 08:06:04 -0600 Original-Received: from localhost ([127.0.0.1]) by wine.codeweavers.com with esmtp (Exim 4.50) id 1EyUzi-00022n-DL for wine-patches(a)winehq.org; Mon, 16 Jan 2006 08:06:02 -0600 Original-Received: from wine.codeweavers.com ([127.0.0.1]) by localhost (wine [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01730-10 for <wine-patches(a)winehq.org>; Mon, 16 Jan 2006 08:06:02 -0600 (CST) Original-Received: from sun3.netoxygen.ch ([193.73.122.103]) by wine.codeweavers.com with esmtp (Exim 4.50) id 1EyUzX-000206-5u for wine-patches(a)winehq.org; Mon, 16 Jan 2006 08:06:02 -0600 Original-Received: from [192.168.1.13] (adsl-62-167-24-207.adslplus.ch [62.167.24.207]) (authenticated bits=0) by sun3.netoxygen.ch (8.12.10/8.12.10) with ESMTP id k0GE5SjV011432; Mon, 16 Jan 2006 15:05:29 +0100 Original-To: Filip Navara <xnavara(a)volny.cz>, wine-patches(a)winehq.org In-Reply-To: <a71bd89a0601150740q21686c09lee0438f8318a6da8(a)mail.gmail.com> X-Mailer: Evolution 2.4.2.1 X-Auth_User: ernstfamily.ch1 X-Scanned-By: MIMEDefang 2.51 on 193.73.122.103 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on wine X-Spam-Level: X-Spam-Status: No, score=-102.6 required=4.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.0.3 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at codeweavers.com X-BeenThere: wine-patches(a)winehq.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Wine Patch Submissions <wine-patches.winehq.org> List-Unsubscribe: <http://www.winehq.org/mailman/listinfo/wine-patches>, <mailto:wine-patches-request(a)winehq.org?subject=unsubscribe> List-Archive: <http://www.winehq.org/pipermail/wine-patches> List-Post: <mailto:wine-patches(a)winehq.org> List-Help: <mailto:wine-patches-request(a)winehq.org?subject=help> List-Subscribe: <http://www.winehq.org/mailman/listinfo/wine-patches>, <mailto:wine-patches-request(a)winehq.org?subject=subscribe> Original-Mime-version: 1.0 Original-Sender: wine-patches-bounces(a)winehq.org Errors-To: wine-patches-bounces(a)winehq.org X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: wine-patches-bounces(a)winehq.org X-SA-Exim-Scanned: No (on wine.codeweavers.com) SAEximRunCond expanded to false Xref: news.gmane.org gmane.comp.emulators.wine.patches:21235 Archived-At: <http://permalink.gmane.org/gmane.comp.emulators.wine.patches/21235> --===============0121623449== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Vvuh16CRO4mt6LCzAjUl" --=-Vvuh16CRO4mt6LCzAjUl Content-Type: multipart/mixed; boundary="=-hIMNUJu5LS0S9amw3+Fv" --=-hIMNUJu5LS0S9amw3+Fv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le dimanche 15 janvier 2006 =C3=A0 07:40 -0800, Dan Kegel a =C3=A9crit : > On 1/15/06, Ge van Geldorp <gvg(a)reactos.org> wrote: > > > The Mozilla ActiveX control download feature is cool and all, > > > but until we repackage the sucker to include MSVCP60.DLL to fix > > > http://bugs.winehq.org/show_bug.cgi?id=3D4064 ... > > > I could have sworn I saw somebody post a note saying they had > > > done said repackaging, but I can't find it now... > > > > http://www.winehq.org/pipermail/wine-patches/2005-December/022795.html > > Instructions on how to repackage can be found at > > svn://svn.reactos.org/trunk/tools/MozillaControl/ >=20 > Thanks! I've updated bug 4064. Now can somebody > update winehq.org's copy of the control so we can close that bug? > - Dan >=20 > -- > Wine for Windows ISVs: http://kegel.com/wine/isv >=20 >=20 >=20 Le lundi 16 janvier 2006 =C3=A0 14:30 +0100, Filip Navara a =C3=A9crit :=20 > Jonathan Ernst wrote: >=20 > > // Exact size of the file: > > $iFileSize =3D 4771240; > > > Shouldn't you change the file size too? >=20 > - Filip >=20 Sure, thanks for spotting it ;-) Changelog: - use repackaged Mozilla ActiveX control from ReactOS --=-hIMNUJu5LS0S9amw3+Fv Content-Disposition: attachment; filename=mozactivex.patch Content-Type: text/x-patch; name=mozactivex.patch; charset=utf-8 Content-Transfer-Encoding: base64 SW5kZXg6IG1vemFjdGl2ZXgucGhwDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvd2luZS90 b29scy9tb3phY3RpdmV4LnBocCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMQ0KZGlmZiAtdSAt cCAtcjEuMSBtb3phY3RpdmV4LnBocA0KLS0tIG1vemFjdGl2ZXgucGhwCTE5IE9jdCAyMDA1IDE2 OjE3OjA5IC0wMDAwCTEuMQ0KKysrIG1vemFjdGl2ZXgucGhwCTE2IEphbiAyMDA2IDE0OjAyOjMz IC0wMDAwDQpAQCAtMTQsMzEgKzE0LDI3IEBADQogDQogDQogLy8gTmFtZSBvZiB0aGUgZmlsZQ0K LSRzRmlsZU5hbWUgPSAiTW96aWxsYUNvbnRyb2wxNzEyLmV4ZSI7DQorJHNGaWxlTmFtZSA9ICJN b3ppbGxhQ29udHJvbDE3MTItUmVhY3RPUy5leGUiOw0KIA0KIC8vIEV4YWN0IHNpemUgb2YgdGhl IGZpbGU6DQotJGlGaWxlU2l6ZSA9IDQ3NzEyNDA7DQorJGlGaWxlU2l6ZSA9IDQ3MzUxNjA7DQog DQogLy8gTGlzdCBvZiBsb2NhdGlvbnMNCi0kYUxpc3QgPSBhcnJheSgiaHR0cDovL3d3dy5pb2wu aWUvfmxvY2thL21vemlsbGEvIiwNCi0gICAgICAgICAgICAgICAiaHR0cDovL29zZG4uZGwuc291 cmNlZm9yZ2UubmV0L3NvdXJjZWZvcmdlL3dpbmUvIiwNCi0gICAgICAgICAgICAgICAiaHR0cDov L25jaGMuZGwuc291cmNlZm9yZ2UubmV0L3NvdXJjZWZvcmdlL3dpbmUvIiwNCi0gICAgICAgICAg ICAgICAiaHR0cDovL2Vhc3luZXdzLmRsLnNvdXJjZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS93aW5l LyIsDQotICAgICAgICAgICAgICAgImh0dHA6Ly9tZXNoLmRsLnNvdXJjZWZvcmdlLm5ldC9zb3Vy Y2Vmb3JnZS93aW5lLyIsDQotICAgICAgICAgICAgICAgImh0dHA6Ly9wdXp6bGUuZGwuc291cmNl Zm9yZ2UubmV0L3NvdXJjZWZvcmdlL3dpbmUvIiwNCi0gICAgICAgICAgICAgICAiaHR0cDovL2Np dGtpdC5kbC5zb3VyY2Vmb3JnZS5uZXQvc291cmNlZm9yZ2Uvd2luZS8iLA0KLSAgICAgICAgICAg ICAgICJodHRwOi8vdW1uLmRsLnNvdXJjZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS93aW5lLyIsDQot ICAgICAgICAgICAgICAgImh0dHA6Ly9jb2dlbnQuZGwuc291cmNlZm9yZ2UubmV0L3NvdXJjZWZv cmdlL3dpbmUvIiwNCi0gICAgICAgICAgICAgICAiaHR0cDovL2phaXN0LmRsLnNvdXJjZWZvcmdl Lm5ldC9zb3VyY2Vmb3JnZS93aW5lLyIsDQotICAgICAgICAgICAgICAgImh0dHA6Ly9zdXJmbmV0 LmRsLnNvdXJjZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS93aW5lLyIsDQotICAgICAgICAgICAgICAg Imh0dHA6Ly9wZXRlcmhvc3QuZGwuc291cmNlZm9yZ2UubmV0L3NvdXJjZWZvcmdlL3dpbmUvIiwN Ci0gICAgICAgICAgICAgICAiaHR0cDovL3VmcHIuZGwuc291cmNlZm9yZ2UubmV0L3NvdXJjZWZv cmdlL3dpbmUvIiwNCi0gICAgICAgICAgICAgICAiaHR0cDovL29wdHVzbmV0LmRsLnNvdXJjZWZv cmdlLm5ldC9zb3VyY2Vmb3JnZS93aW5lLyIsDQotICAgICAgICAgICAgICAgImh0dHA6Ly9rZWlo YW5uYS5kbC5zb3VyY2Vmb3JnZS5uZXQvc291cmNlZm9yZ2Uvd2luZS8iLA0KLSAgICAgICAgICAg ICAgICJodHRwOi8vaGVhbmV0LmRsLnNvdXJjZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS93aW5lLyIs DQotICAgICAgICAgICAgICAgImh0dHA6Ly9zd2l0Y2guZGwuc291cmNlZm9yZ2UubmV0L3NvdXJj ZWZvcmdlL3dpbmUvIiwNCi0gICAgICAgICAgICAgICAiaHR0cDovL2ludGVybmFwLmRsLnNvdXJj ZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS93aW5lLyIsDQotICAgICAgICAgICAgICAgImh0dHA6Ly9v dmguZGwuc291cmNlZm9yZ2UubmV0L3NvdXJjZWZvcmdlL3dpbmUvIg0KKyRhTGlzdCA9IGFycmF5 KCJodHRwOi8vc3dpdGNoLmRsLnNvdXJjZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS9yZWFjdG9zLyIs DQorICAgICAgICAgICAgICAgImh0dHA6Ly9zdXJmbmV0LmRsLnNvdXJjZWZvcmdlLm5ldC9zb3Vy Y2Vmb3JnZS9yZWFjdG9zLyIsDQorICAgICAgICAgICAgICAgImh0dHA6Ly9jaXRraXQuZGwuc291 cmNlZm9yZ2UubmV0L3NvdXJjZWZvcmdlL3JlYWN0b3MvIiwNCisgICAgICAgICAgICAgICAiaHR0 cDovL2tlaWhhbm5hLmRsLnNvdXJjZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS9yZWFjdG9zLyIsDQor ICAgICAgICAgICAgICAgImh0dHA6Ly9oZWFuZXQuZGwuc291cmNlZm9yZ2UubmV0L3NvdXJjZWZv cmdlL3JlYWN0b3MvIiwNCisgICAgICAgICAgICAgICAiaHR0cDovL2Vhc3luZXdzLmRsLnNvdXJj ZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS9yZWFjdG9zLyIsDQorICAgICAgICAgICAgICAgImh0dHA6 Ly9vdmguZGwuc291cmNlZm9yZ2UubmV0L3NvdXJjZWZvcmdlL3JlYWN0b3MvIiwNCisgICAgICAg ICAgICAgICAiaHR0cDovL2phaXN0LmRsLnNvdXJjZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS9yZWFj dG9zLyIsDQorICAgICAgICAgICAgICAgImh0dHA6Ly9wdXp6bGUuZGwuc291cmNlZm9yZ2UubmV0 L3NvdXJjZWZvcmdlL3JlYWN0b3MvIiwNCisgICAgICAgICAgICAgICAiaHR0cDovL25jaGMuZGwu c291cmNlZm9yZ2UubmV0L3NvdXJjZWZvcmdlL3JlYWN0b3MvIiwNCisgICAgICAgICAgICAgICAi aHR0cDovL3N3aXRjaC5kbC5zb3VyY2Vmb3JnZS5uZXQvc291cmNlZm9yZ2UvcmVhY3Rvcy8iLA0K KyAgICAgICAgICAgICAgICJodHRwOi8va2VudC5kbC5zb3VyY2Vmb3JnZS5uZXQvc291cmNlZm9y Z2UvcmVhY3Rvcy8iLA0KKyAgICAgICAgICAgICAgICJodHRwOi8vb3B0dXNuZXQuZGwuc291cmNl Zm9yZ2UubmV0L3NvdXJjZWZvcmdlL3JlYWN0b3MvIiwNCisgICAgICAgICAgICAgICAiaHR0cDov L21lc2guZGwuc291cmNlZm9yZ2UubmV0L3NvdXJjZWZvcmdlL3JlYWN0b3MvIiwNCisgICAgICAg ICAgICAgICAiaHR0cDovL2ludGVybmFwLmRsLnNvdXJjZWZvcmdlLm5ldC9zb3VyY2Vmb3JnZS9y ZWFjdG9zLyINCiAgICAgICAgICAgICAgICApOw0KIA0KICAgICAgICAgICAgICAgIA0K --=-hIMNUJu5LS0S9amw3+Fv-- --=-Vvuh16CRO4mt6LCzAjUl Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDy6ghIW5mR/h6b38RAt7kAJ4pu3x50sV01szFkzhGuRH3rHB1BwCeKCvV up0s6nDm61QdZMhJrmlDD4A= =eCBO -----END PGP SIGNATURE----- --=-Vvuh16CRO4mt6LCzAjUl-- --===============0121623449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0121623449==--

Jan. 28, 2006

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL? [FIXED]

by Molle Bestefich

Tony Lambregts wrote: > http://www.winehq.org/pipermail/wine-patches/2006-January/023490.html Looks odd with all the MIME in there. > So... I went looking at the alternative and thought of > GMANE and it turns out that this patch is not archived there at all. GMANE snips stuff with X-No-Archive set - just offering pointers. [snip body of email from Jonathan Ernst] Would you mind posting the entire email, including headers etc., as an attachment? I'd like to take a look at it too but I'm not subscribed to wine-patches =).

Jan. 28, 2006

Wine-wiki broken by design

by Molle Bestefich

GuruLounge - MailLists wrote: > err:seh:setup_exception stack overflow 40 bytes in thread 000c Exception loop. Covered to some extent in: http://wiki.winehq.org/Debugging_'Wild_Metal_Country' For some reason, all pages in the Wine Wiki (like the above) is _fucking_ impossible to find with Google. I don't know why, but I think it might be because all the pages have "index: nofollow", which means that subpages are never found. GRR. Very unhelpful to newbies. Very tragic that fine Wiki documentation is available but that noone can find it because Google is disabled for the entire Wiki. And very annoying that I've had to answer this question 3 times now, when it should obviously be a top hit for "seh:setup_exception" on Google. SO, could someone *PLEASE* fix the Wiki so Google can index it??? Pretty please *smile* :-).

Jan. 28, 2006

Re: Fix: tab-control flickering

by Vitaliy Margolen

Saturday, January 28, 2006, 4:21:21 AM, Tobias Loew wrote: > Changelog: > dlls/comctl32/tab.c > Tobias Loew <tobi(a)die-loews.de> > Fix: tab-control flickering; tab-control redraws itself after a call to SetCurSel also > when the selection doesn't change > Tobias Loew > Index: dlls/comctl32/tab.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/tab.c,v > retrieving revision 1.122 > diff -u -p -r1.122 tab.c > --- dlls/comctl32/tab.c 8 Nov 2005 12:52:35 -0000 1.122 > +++ dlls/comctl32/tab.c 28 Jan 2006 10:25:40 -0000 > @@ -261,9 +261,11 @@ static inline LRESULT TAB_SetCurSel (TAB > if (iItem >= 0 && iItem < infoPtr->uNumItem) { > prevItem=infoPtr->iSelected; - infoPtr->>iSelected=iItem; > - TAB_EnsureSelectionVisible(infoPtr); > - TAB_InvalidateTabArea(infoPtr); + if (infoPtr->>iSelected != iItem) { + infoPtr->>iSelected=iItem; > + TAB_EnsureSelectionVisible(infoPtr); > + TAB_InvalidateTabArea(infoPtr); > + } > } > return prevItem; > } Please follow the same formatting as the rest of the file/function. In this case it is 4 spaces indent. Vitaliy Margolen

Jan. 28, 2006

Re: Win32HandleToDosFileHandle / DosFileHandleToWin32Handle

by Derek Fawcus

On Sat, Jan 28, 2006 at 10:52:26AM +0100, Eric Pouech wrote: > > I suppose one could do something in the VDM process to mark the file > > handles as having multiple references, and then do proper open / close > > handling. But that would require a valid JFT anyway. > yes, what's currently missing is the JFT layer... one can consider that > the Win32HandleToDosHandle (and its friends) to handle the SFT, and > allow to bridge between the DOS world and the Win32 world. What I'm suggesting is that as soon as there is a JFT, and we have to store a reference count outside the JFT, then the place we store it is an equivalent to the SFT. > > So th JFT gives a way to update a reference count in the SFT. > but, you'll have to patch every possible file usage in winedos so that > you don't mixup sft indexes and jft indexes... I know :-( But the majority of it will be where Win32HandleToDosFileHandle is called - i.e. the FCB code, as for a lot of the rest the existing code using DosFileHandleToWin32Handle _could_ be retained. > > Another place where I think it'll come in handy is for redirection, > > where it'll allow for stashing an equivalent of the device info word. > > I think this'll make some of the console handling a bit better. > you mean regarding the char / block caps for example? Yup. Since it could (also) be used to revector some routines on a per file type basis - i.e. move the special case code that currently exists out of the common path. > not sure we need > to store that in the SFT, we can get it back from the win32 handle anyway. Well with a round trip. But the 'inherit file handle' bit is one that DOS stores in the device info word. We'd really need to store the same bit. At which point the rest of the word is available for use. DF

Jan. 28, 2006

Re: NetUserEnum

by Vijay Kiran Kamuju

Hi, If you could also post the FIXME message or the winedebug trace it would be helpful. It would help us to locate if its a regression or unimplemented case. Thanks, VJ On 1/28/06, suppandi <suppandi(a)gmail.com> wrote: > Hi, > > I was trying to run notes7 and it was crashing because NetUserEnum() was not > implemented. So i tried writing a simple implementation. Could anybody have > a look at this, and tell me whats wrong. Now notes just crashes without any > doc. unfortunately i amn't a windows programmer to write a simple program > to make the call. > > NetUserEnum(LPCWSTR servername, DWORD level, DWORD filter, LPBYTE* bufptr, > DWORD prefmaxlen, LPDWORD entriesread, LPDWORD totalentries, > LPDWORD resume_handle) > { > struct USER_INFO_20 > { > LPWSTR usri20_name; > LPWSTR usri20_full_name; > LPWSTR usri20_comment; > DWORD usri20_flags; > DWORD usri20_user_id; > }; > > switch(level) > { > case 20: > { > struct USER_INFO_20 *data; > char user[]={'t','e','s','t'}; > NetApiBufferAllocate(sizeof(struct USER_INFO_20), > (LPVOID *) bufptr); > data = (struct USER_INFO_20 *)malloc(sizeof(struct USER_INFO_20)); > data->usri20_name = (LPWSTR)malloc(20); > memcpy((void*)data->usri20_name,user,4); > data->usri20_full_name = (LPWSTR)malloc(20); > memcpy((void*)data->usri20_full_name,user,4); > data->usri20_comment = (LPWSTR)malloc(20); > memcpy((void*)data->usri20_comment,user,4); > data->usri20_flags = UF_NORMAL_ACCOUNT; > data->usri20_user_id = 1000; > *entriesread = *totalentries = 1; > return 0; > } > break; > default: > FIXME("(%s,%ld, 0x%ld,%p,%ld,%p,%p,%p) stub!\n", > debugstr_w(servername), level, > filter, bufptr, prefmaxlen, entriesread, totalentries, > resume_handle); > > return ERROR_ACCESS_DENIED; > break; > } > } > > > > >

Jan. 28, 2006

Re: Small CVS-Update-Script

by Christian Lachner

I've updated my git-updatescript once again. There now is a new mode 3 which allows you to compile your local tree without updating it. It's just a small feature addition. I will also update the cvs-version if there is someone that wants so but please -> use the git-version :) The current version is now 0.11. greets

Jan. 28, 2006

Re: setupapi: unimplemented function setupapi.dll.SetupPromptReboot

by Saulius Krasuckas

* On Sat, 28 Jan 2006, James Hawkins wrote: > * On 1/28/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > > > Then we can simply remove #if 0 and be fine. No? > > No, you'd have to add the string resources for the shutdown message. > You'd also have to add handling for the FileQueue parameter because it's > missing in ReactOS. Of course, but I was talking about the code, not the data. :) As for FileQueue handling I prefer to leave this case as a stub for a while. BTW, James, maybe are you were working on this function by yourself already?

Jan. 28, 2006