- Wine-Devel - list.winehq.org

Re: [Wine] Edit Windows XP registry with wines regedit?
by Saulius Krasuckas Oct. 3, 2004

Oct. 3, 2004

On Sat, 2 Oct 2004, Martin Bammer wrote: > When I remove the Enum-key under hkey_local_machine then Windows redetects all > hardware. So a reinstall would not be needed. Wine has a regedit. But I don't > know how to tell wine that it uses the registry from the installed windows. For sure it would not be needed, but as for Wines regedit I am not sure. AFAIK, it can only read NT-system registry, but not write it. > Would be a nice "recovery" feature for Linux to be able to edit windows > registries, because a defective registry is often a problem in windows... You can always try using Offline NT Password & Registry Editor. It uses console UI and is more of command line editing, but whatever [1]. BTW, you or someone else can try merging both the ntreg library [1] and Wine registry editor code to make a GUI tool to suffice your needs. I hope there would be no license [2] collisions. [1] http://home.eunet.no/~pnordahl/ntpasswd/ [2] http://home.eunet.no/~pnordahl/ntpasswd/COPYING.txt

2 1

systemparamatersw question
by Ivan Leo Puoti Oct. 3, 2004

Oct. 3, 2004

Are all SPI values in windows/sysparams.c,SystemInformationW() stored in the registry somewhere? If yes, is there a not to difficult way to find which registry key it is for a given SPI value? I have a few win boxes available to find this out. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

2 1

TIME_GetTZAsStr problem with "UTC"
by Jacek Caban Oct. 2, 2004

Oct. 2, 2004

Hi. I got this communicat: fixme:ntdll:TIME_GetTZAsStr Can't match system time zone name "UTC" to an entry in TZ_INFO fixme:ntdll:TIME_GetTZAsStr Please add appropriate entry to TZ_INFO and submit as patch to wine-patches so I wanted to send patch, but "UTC" is time convencion, not Local Time Zone. I've checked my Linux configuration: $ date sob paź 2 23:06:33 UTC 2004 It seems to be bad Linux configuration, but it's my default configuration (I use Fedora Core 2, my Local Time Zone is CEST). I think Wine should do something in this this case, but I don't know what. Any idea? Thanks, Jacek

2 1

Re: Tab control update
by Vitaliy Margolen Oct. 2, 2004

Oct. 2, 2004

Looks ok to me with few exceptions: It would be really nice to separate formatting changes from other changes. It's hard to see what's got changed and what not. >+#define MIN_ICONTAB_WIDTH 54 /* Magic number, but it works */ >+ if (icon_width > MIN_ICONTAB_WIDTH) >+ curr->rect.right += icon_width; >+ else >+ curr->rect.right += MIN_ICONTAB_WIDTH; This is wrong (see below). >"Only create a scroll control when/if we need one (like native)" Nothing got changed. It's being created when needed, and hidden when not longed used. Is there something else I missed? > Combine all Unicode/Ascii calls together I'm not sure here, but should it be based on the unicode state of the whole control rather which message got sent to it? I can see how you can send ASCII message first and then send UNICODE message which will screw things up. >+/* Since items are variable sized, cannot directly access them */ >+#define TAB_GetItem(info,i) \ >+ ((TAB_ITEM*)((LPBYTE)info->items + (i) * TAB_ITEM_SIZE(info))) If this is the case we need to store pointers in array of pointers. >+ hwTab = create_tabcontrol(0, TCIF_TEXT|TCIF_IMAGE); >+ >+ trace_tab ("Testing non fixed width no imagelist...\n"); You missed insert items with text part inside create_tabcontrol. Besides as is it's failing for me. When I change text of the first tab "Tab 123" it's changing returned width. The reason why I didn't test this is because the width of the tab depends on it's text width. Which is kind of hard to test (different fonts, different font sizes etc.). Vitaliy Margolen Friday, October 1, 2004, 8:58:23 AM, Vitaliy Margolen wrote: > Hi, > A fairly large update to the tab control. This makes it work as per > native in my app. > Regards, > Jon > +dlls/comctl32/tab.c dlls/comctl32/tests/tab.c > Items can be variable sized; use an accessor to retrieve them > Send WM_NOTIFYFORMAT/WM_QUERYUISTATE to match native messages > Only create a scroll control when/if we need one (like native) > Dump tab extra data when tracing > Pass infoPtr around instead of fetching it multiple times, store > hwnd and focus state in it too. > Calculate correct tab widths when TCS_FIXEDWIDTH is not given > Code simplifications/const correctness/formatting fixes > Add some new combinations to tests for correct tab sizes > ===== > "Don't wait for the seas to part, or messiahs to come; > Don't you sit around and waste this chance..." - Live > jon_p_griffiths(a)yahoo.com > __________________________________ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. > http://promotions.yahoo.com/new_mail

1 0

Re: Tab control update
by Dimitrie O. Paun Oct. 1, 2004

Oct. 1, 2004

On Fri, Oct 01, 2004 at 07:58:23AM -0700, Jon Griffiths wrote: > Hi, > > A fairly large update to the tab control. This makes it work as per > native in my app. Nice. While you're at it (and have it fresh in your mind), can you please also provide an audit (and a list of TODOs) as per comctl 6.0? We're getting closer to having a full audit of the controls, and this one has not been audited: http://winehq.org/site/status_ui TIA, Dimi.

2 1

Re: COBJMACROS patch 3
by Dmitry Timoshkov Oct. 1, 2004

Oct. 1, 2004

"Francois Gouget" <fgouget(a)free.fr> wrote: > COBJMACROS is very C unfriendly as it requires the caller to define it > if it wants to use COM objects. The following check is much better as > it does the right thing automagically: > > #if !defined (__cplusplus) || defined(CINTERFACE) > > So for internal interface, let's use the C friendly check instead of > COBJMACROS. This way we'll have fewer '#define COBJMACROS' to sprinkle > through the code. But that change makes Wine code not compilable with SDK and Mingw headers, I don't think it's an acceptable change. -- Dmitry.

2 3

Troubles with GetVarDesc function.
by MIKEL CARRASCO Oct. 1, 2004

Oct. 1, 2004

Hi: Recently I've been having troubles with the GetVarDesc function. It's supposed to return the description of a COM server's property(given the property index), but instead, it returns the description of one of the methods of the COM server. I've realized that the varlist list of the ITypeInfo class is filled with the COM server methods, and it must be filled with properties. I think the problem is in MSFT_DoVars function, which is the responsible of the creation of varlist. I've fixed the problem just actualizing the offset variable to point to the begin of the variables description, instead of the begin of the functions description (the bold line below), I don't know if this is the right place to make the correction, but definitely It has solved my problem. .............................. offset = offset + (cFuncs*sizeof(INT)); for(i=0;i<cVars;i++){ .............................. I hope this could be of value for someone... Mikel.

1 0

RE: SystemFunction006
by Rolf Kalbermatter Oct. 1, 2004

Oct. 1, 2004

Hans Leidekker wrote: +NTSTATUS WINAPI SystemFunction006( LPCSTR password, LPSTR hash ) +{ + unsigned char buffer[16]; + + hash = CRYPT_LMhash( buffer, password, strlen(password) ); + + return STATUS_SUCCESS; +} I don't think this will work properly. The returned pointer from CRYPT_LMHash() will never be passed out to the caller of the function. There should be probably a function call before the return of the function along the lines of memcpy(hash, buffer, 16); The question here would also be why use an intermediate buffer at all in the first place? Also the use of strcmp() for comparing a hash in the according test seems a little misplaced to me. Or is a DES hash guaranteed to never contain 0x00 bytes? It doesn't occur in the test case so it is not a big problem in this case but principially it seems not right to me. Rolf Kalbermatter

2 1

WINEDLLOVERRIDES for all dlls?
by James Hawkins Sept. 30, 2004

Sept. 30, 2004

Hi, I'm working on getting ie6 sp1 to install without using any native dlls. The install is fine until about 78% of the way through installing the files, the installer loads a native advapi32 that it downloaded to a temp directory and then the install seems to pause as this message is continuously printed: fixme:thunk:CommonUnimpStub generic stub: ? I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still shows the downloaded native advapi32.dll being loaded. Does WINEDLLOVERRIDES only take dll's that are in the windows\system directory into account? I have a feeling that the install would go smoother if the builtin advapi32 was loaded instead of the native one. I'm guessing that the installer is calling LoadLibary("path to native advapi32")...that's just a guess though. -- James Hawkins

5 8

Problems with MSI installer
by Joaquín Fernández Sept. 30, 2004

Sept. 30, 2004

Hello I am trying to install an EXE file packed with MSI. I installed InstMsiA before running the program, but the installer don't finish, stay in endless loop when copying the files, and progress bar is over 70%. I put WINEDEBUG=trace+all and show PENDING() when the installer stop. I ran wine with WINEDLLOVERRIDES="*advapi32=b", WINEDLLOVERRIDES="*advapi32=b;msi=n", WINEDLLOVERRIDES="*advapi32=b;msiexec.exe=n" and WINEDLLOVERRIDES="*advapi32=b;msi,msiexec.exe=n", only the last option let the installer advance but don't finish. So what event wait installer for to continue? Do i need override other(s) dlls when use MSI installer? Regards Joaquín -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

1 0