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

listview and LVS_OWNERDATA problems update

by Dan Kegel

I just revisited http://bugs.winehq.org/show_bug.cgi?id=1268 and found that things are improved, but not fully working; there is corruption to the left of column 1 in the demo app. I have not yet rechecked http://bugs.winehq.org/show_bug.cgi?id=1404 to see how well that demo app is doing. - Dan

Jan. 14, 2004

Re: Will function advapi32.dll.RegOpenUserClassesRoot will be implemented?

by MediaHost (TM)

Well, I guess, that there are people actively developing...It might be easier for them to get a fix done... Until I get into the source and understand, what you guys did.....win2000 will have finished end of life :-) Anyone knows where to insert this piece of code? Can be found here: http://msdn.microsoft.com/msdnmag/issues/1100/Registry/default.aspx the following: Registry API Flavors and New Functions There are basically three ways to program the registry: the Win32 API functions (advapi32.dll), the more recent Shell Lightweight API (shlwapi.dll), and various object models accessible mostly from Visual Basic® and Windows Script Host. If Visual Basic is your favorite development tool, I recommend taking a look at the RegObj library available from http://msdn.microsoft.com/vbasic/downloads. It is an object model that emulates the full Win32 API for working with the registry. The original set of registry functions provides you with the greatest flexibility. It requires you to open a key, to read or write to it, and then close it; the three basic operations for reading or writing an individual entry. The Shell Lightweight library-also available with Windows 98, Windows 95, and Windows NT 4.0 plus Internet Explorer 5.0 or higher-comes with some new functions that internally open and close the specified key when asked to read or write values. You just call SHGetValue or SHSetValue and let the function deal with the registry. In addition, the new API provides a SHDeleteKey function that recursively deletes non-empty keys. As explained earlier, this is the standard behavior in Windows 9x, but not in Windows NT or Windows 2000. The Windows 2000 SDK introduces three new functions that work with the registry: RegOpenUserClassesRoot, RegOpenCurrentUser, and RegDisablePredefinedCache. RegOpenUserClassesRoot returns a handle to HKCR for the specified user. You identify the user through an access token. The token can be returned by functions like LogonUser, and allows you to log onto the system as if you were another user. RegOpenCurrentUser retrieves a handle to HKCU. Notice that by default all the values stored in HKCU are cached for all threads in a process. To disable this practice and force the API to read and write from disk, remember to call RegDisablePredefinedCache. IQueryAssociations is another tool for working with the registry. It simplifies the information retrieval from HKCR and HKCU. You obtain a reference to the interface through IShellFolder's GetUIObjectOf or a new API function called AssocCreate. The IQueryAssociations methods allow you to set the root key and query for data, as shown in the following code: ----- Original Message ----- From: "Marcus Meissner" <meissner(a)suse.de> To: "MediaHost (TM)" <webmaster(a)startcom.org> Cc: <wine-devel(a)winehq.org> Sent: Wednesday, January 14, 2004 12:08 PM Subject: Re: Will function advapi32.dll.RegOpenUserClassesRoot will be implemented? --- StartCom Ltd. http://www.startcom.org Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004

Jan. 14, 2004

Re: slight trouble running winetests under windows

by Hans Leidekker

On Tuesday 13 January 2004 20:33, Alexandre Julliard wrote: > this doesn't help. A possibility could be to rename the library to > libuuid but install it in /usr/lib/wine to avoid conflicts. This will > require winegcc and winemaker to set the correct library path, but > they already have to do that for import libs anyway. Looks like a solution to me. What about dxguid? Should we split uuid up by creating a seperate directory with Makefile etc. or will a symlink to libuuid do? -Hans

Jan. 14, 2004

wwn #110 ??

by Tom

If I look at WWN #110 on winehq.org I get this http://www.winehq.org/?issue=110 If I look at 110 at : http://kt.zork.net/wine/wn20011212_110.html it is almost toatly different!! Do I need to start reading both sites each week? And I guess ill send a patch to fix this as there is alot of good crap here to read! :) Tom

Jan. 14, 2004

Re: Will function advapi32.dll.RegOpenUserClassesRoot will be implemented?

by Marcus Meissner

On Wed, Jan 14, 2004 at 11:09:15AM +0200, MediaHost (TM) wrote: > Hi, > > Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be implemented? If someone implements it, yes. > As I can see, most up 2 date software of Micro$oft (Explorer etc.) is using this function and can not run on a W2K environment. > > Any suggestions? Feel free to send a patch, even with a function just printing a FIXME() message. Ciao, Marcus

Jan. 14, 2004

Will function advapi32.dll.RegOpenUserClassesRoot will be implemented?

by MediaHost (TM)

Hi, Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be implemented? As I can see, most up 2 date software of Micro$oft (Explorer etc.) is using this function and can not run on a W2K environment. Any suggestions? Regards Signer: Eddy Nigg Company: StartCom Group at http://www.startcom.org MediaHostT at http://www.mediahost.org --- StartCom Ltd. http://www.startcom.org Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.560 / Virus Database: 352 - Release Date: 1/10/2004

Jan. 14, 2004

Wine User's guide : using Windows ODBC driver manager seems to work

by Emmanuel Charpentier

Following a suggestion in Wine User's Guide, (§ 1.1.2), I'd like to suggest an addition. The "ODBC" section (§ 5.12) gives details (§ 5.12.1) about the use of the native ODBC driver, routed through a fake "builtin" ODBC driver. I have not yet had to test it in real conditions. All I can tell is that I wasn't able to use it to "Attach" (M$ jargon) Postgres data in MS Access (see PPS for the setup) : when I tried to select "ODBC sources" from the "Attach tables" dialog, I got immediately an error box from unixODBC telling me that no data source was specified. However, the User's Guide is quite terse about the Windows ODBC driver. Exhaustive quotation : " Does anyone actually have any experience of this and anything to add?". Well, I do. In the same setup as before, I have been able to use the *native* odbc32.dll ODBC driver by pulling it from a real Windows instalation and adding "odbc32"="native,builtin" in the config file. I Installed the psqlodbc driver from the Postgres database, and retried : selecting "ODBC sources" in the "Attach tables" dialog box led me to the usual ODBC manager dialogs, where I have been able to create a DSN to my Postgres database. I have then been able to "Atach" my Postgres tables and views to an M$ Access database and peruse them. My conclusion is that such a setup can be used, if only to be able to export MS Access data to a more reasonable database manager. This information could be of some help to some people, and I'd like to see it reflected in the User's guide. Of course, I'm aware that such a quick test is no substitute to real tests and explorations. Feel free to reach to me for further information, test cases, etc ... Sincerely yours, Emmanuel Charpentier PS : I'm not on this list. Please Cc: me if you wishme to react to your answers. PPS : Setup : Debian (unstable), 2.4.21 kernel, Wine 20031212 as packaged in Debian, Win98SE (french), "fake windows" setup, using native stdole.tlb, ole32.dll, oleaut32.dll, rpcrt4.dll and, of course, odbc32.dll, MS Office 97 (installed without a hitch from the CD, except for a "Can't DDE connect to desktop" error in the setup, ignored) + SR1 parch. I have had success with SR2b, but this needs a lot more native DLLs, and I can't recall them at the moment (work machine). -- Emmanuel Charpentier

Jan. 14, 2004

Oleaut32 tests fail

by Sylvain Petreolle

Running the oleaut32 tests shows that vartype and vartest are failing. The 25 tests that fail are returning DISP_E_TYPEMISMATCH (0x80020005) Has someone an idea about these ? vartest.c:2653:======== Testing different VARTYPES ======== fixme:ole:VarParseNumFromStr dwInFlags & NUMPRS_HEX_OCT not yet implemented! vartest.c:2680: Test failed: 14: vt 83, return value 80020005, expected was 0 ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 14, 2004

Re: PATCH: Port Tim Ferguson's ICCVID codec to Wine

by Dimitrie O. Paun

On January 14, 2004 01:05 am, Dmitry Timoshkov wrote: > I don't mind either, but if the new iccvid code will be placed under > dlls/ then dlls/msvideo/msrle32 should be moved there as well. I'd much rather move msrle32 to dlls/, then create new DLLs deep inside the dir hierarchy. Ideally we should have all DLLs just under dlls/, let's not make the problem worse. -- Dimi.

Jan. 14, 2004

Re: PATCH: Port Tim Ferguson's ICCVID codec to Wine

by Mike McCormack

Hi Dmitry, I asked Alexandre where it should go, and he said wine/dlls was an appropriate place. I don't mind either way... Mike Dmitry Timoshkov wrote: > > Mike, could you put the iccvid sources at the same place > as msrle32 (dlls/msvideo) and resend the patch? >

Jan. 14, 2004

Re: PATCH: Port Tim Ferguson's ICCVID codec to Wine

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > I asked Alexandre where it should go, and he said wine/dlls was an > appropriate place. I don't mind either way... I don't mind either, but if the new iccvid code will be placed under dlls/ then dlls/msvideo/msrle32 should be moved there as well. -- Dmitry.

Jan. 14, 2004

Re: PATCH: Port Tim Ferguson's ICCVID codec to Wine

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > Tim Ferguson <Tim.Ferguson(a)infotech.monash.edu.au> > Mike McCormack <mike(a)codeweavers.com> > * Port Tim Ferguson's ICCVID codec to Wine Mike, could you put the iccvid sources at the same place as msrle32 (dlls/msvideo) and resend the patch? -- Dmitry.

Jan. 14, 2004

Re: ifenum.c mtu acquisition - Solaris

by Dimitrie O. Paun

On January 13, 2004 09:46 pm, Robert Lunnon wrote: > +#if !defined sun > *mtu = ifr.ifr_mtu; > +#else > + *mtu=ifr.ifr_metric; > + #endif The #endif is not properly indented, any special reason? -- Dimi.

Jan. 14, 2004

Re: slight trouble running winetests under windows

by Chris Morgan

It doesn't show up in the object/library modules list, maybe something is wrong there? Chris On Tuesday 13 January 2004 07:33 pm, Francois Gouget wrote: > On Tue, 13 Jan 2004 chmorgan(a)charter.net wrote: > [...] > > > Ahh yes, this appears to be the issue. If I go to "project > > settings->link->object/library modules" and add "uuid.lib" to the list > > then the test compiles without many other issues. Shouldn't the > > script be adding this to the .dsp/.dsw? > > That's strange. I thought that msvcmaker was already systematically > including uuid.lib in the generated .dsp/.dsw files. > > > I'm having great troubles compiling the test against vs6 header files > > as well, should I upgrade to the latest platform sdk? > > YEs. Unfortunately compiling most of Wine's tests with the 'Windows > headers' requires a pretty recent SDK (and getting the latest SDK is > somewhat painful). The headers that come with VC6 just don't cut it.

Jan. 14, 2004

Re: slight trouble running winetests under windows

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > On Tue, 13 Jan 2004 11:33:25 -0800, Alexandre Julliard wrote: >> The current problem is that Wine itself is not built with winegcc so >> this doesn't help. A possibility could be to rename the library to >> libuuid but install it in /usr/lib/wine to avoid conflicts. This will >> require winegcc and winemaker to set the correct library path, but >> they already have to do that for import libs anyway. > > Would having two DSOs with the same SONAME that are actually different > break prelink in any way? libuuid is a static lib not a DSO. -- Alexandre Julliard julliard(a)winehq.com

Jan. 14, 2004

Re: slight trouble running winetests under windows

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > Right. For some reason I've read winetest and understook winemaker :) > Sorry for the confusion. But we could build the tests with winegcc > right now, no? And programs/* as well. We can't deal with DLLs in > winegcc, I'm a lazy bum, I admit :/ The main problem is that winegcc only knows about gcc, and we want Wine to build with other compilers too. So no, we can't use it yet. -- Alexandre Julliard julliard(a)winehq.com

Jan. 14, 2004

Re: Re: slight trouble running winetests under windows

by Francois Gouget

On Tue, 13 Jan 2004 chmorgan(a)charter.net wrote: [...] > Ahh yes, this appears to be the issue. If I go to "project > settings->link->object/library modules" and add "uuid.lib" to the list > then the test compiles without many other issues. Shouldn't the > script be adding this to the .dsp/.dsw? That's strange. I thought that msvcmaker was already systematically including uuid.lib in the generated .dsp/.dsw files. > I'm having great troubles compiling the test against vs6 header files > as well, should I upgrade to the latest platform sdk? YEs. Unfortunately compiling most of Wine's tests with the 'Windows headers' requires a pretty recent SDK (and getting the latest SDK is somewhat painful). The headers that come with VC6 just don't cut it. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

Jan. 14, 2004

Re: Implement LockWindowUpdate [take 2]

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > Alright. It'd be nice if somebody who knew all the rules of DLL separation > would write them up somewhere. At the moment I basically have to guess. > Apologies if it's already written up or the rules are obvious to all > except me :) Basically you can only use stuff that is officially exported by the Windows dlls and headers. The WND structure is not exported, since it's not declared in any standard header file, and you need to call Wine internal functions to get access to it. > If using WND is not OK, what is the best way to get information from USER > to x11drv then? A wine-specific export that we GetProcAddress() for? Using > SetProp()? That depends on the problem. In this case it really depends on the inter-process behavior of LockWindowUpdate; probably at least part of it needs to be handled in the server, but the doc is not really clear on that point. -- Alexandre Julliard julliard(a)winehq.com

Jan. 14, 2004

Re: slight trouble running winetests under windows

by Mike Hearn

On Tue, 13 Jan 2004 11:33:25 -0800, Alexandre Julliard wrote: > The current problem is that Wine itself is not built with winegcc so > this doesn't help. A possibility could be to rename the library to > libuuid but install it in /usr/lib/wine to avoid conflicts. This will > require winegcc and winemaker to set the correct library path, but > they already have to do that for import libs anyway. Would having two DSOs with the same SONAME that are actually different break prelink in any way?

Jan. 13, 2004

Re: Implement LockWindowUpdate [take 2]

by Mike Hearn

On Tue, 13 Jan 2004 13:39:48 -0800, Alexandre Julliard wrote: > Extending the WND structure is OK (though it doesn't seem necessary in > that case), but accessing it from x11drv is a violation of dll > separation. We still do that in a number of places but they will have > to be fixed, so we probably shouldn't add new ones. Alright. It'd be nice if somebody who knew all the rules of DLL separation would write them up somewhere. At the moment I basically have to guess. Apologies if it's already written up or the rules are obvious to all except me :) If using WND is not OK, what is the best way to get information from USER to x11drv then? A wine-specific export that we GetProcAddress() for? Using SetProp()?

Jan. 13, 2004

Re: Cdrom driver

by Mike Hearn

Well, I used c:\windows\cdplayer.exe :) It works perfectly, in fact... On Wed, 14 Jan 2004 07:40:04 +1000, Robert Lunnon wrote: > I have just finished embelishing the cdrom driver to support solaris but I > have nothing to test it against. Can anyone recommend a good test program for > excercising CDROM ioctls ? > > Thanks > > Bob

Jan. 13, 2004

Re: Solaris compile time fixes for CVS wine

by Alexandre Julliard

Robert Lunnon <bobl(a)optushome.com.au> writes: > There are quite a few patches in that kit, they are organised as separate > patches for each file and a description to make application easy. After > extracting you could construct a single liner that would apply the entire > kit. Actually it doesn't make application easy, it's a pain to have to extract the tar, review everything, keep track of what has been applied or not, match up the changelogs, etc. The rule is one patch per mail, and there are many good reasons for that. > Does this answer your questions, oh and should I resubmit the patches or will > the kit do. Please resubmit, thanks. -- Alexandre Julliard julliard(a)winehq.com

Jan. 13, 2004

Re: slight trouble running winetests under windows

by Dimitrie O. Paun

On Tue, 13 Jan 2004, Alexandre Julliard wrote: > The current problem is that Wine itself is not built with winegcc so > this doesn't help. Right. For some reason I've read winetest and understook winemaker :) Sorry for the confusion. But we could build the tests with winegcc right now, no? And programs/* as well. We can't deal with DLLs in winegcc, I'm a lazy bum, I admit :/ > A possibility could be to rename the library to > libuuid but install it in /usr/lib/wine to avoid conflicts. This will > require winegcc and winemaker to set the correct library path, but > they already have to do that for import libs anyway. Yes, we can do that, but it introduces a _little_ inconsistency. Even though you could argue it's not a big deal since this is a static lib, so ld is not concerned with it. Anyway is good. -- Dimi.

Jan. 13, 2004

Re: Solaris compile time fixes for CVS wine

by Dimitrie O. Paun

On Wed, 14 Jan 2004, Robert Lunnon wrote: > It would be relatively easy to send a dozen or so emails though, providing you > don't want me to collect up the dependencies into a single e-mail Well, a patch should be a logical atomic change, no matter how many files it touches. You can't for example have one patch use a new variable (say in a file.c), and another declare it (in header.h). > As for status: > > Wine works quite well under Solaris x86 (Possibly better than linux based on > my experience with 18062003) but can't be built and run successfully without > two key patches that Alexandre has elected not to accept, and one patch which > is probably acceptable but I haven't sent yet (not sure if the semantics of > the code are correct for the OS yet). The reason I'm interested in the status is that I'm trying to assemble a porting page for Wine. But that page has to refer to the stock Wine. Can you please tell me which DLLs don't build cleanly in the stock tree on Solaris? Do you have any experience building Wine on Sparc? > Hence my port is not a stock wine. I must maintain at least the critical > patches locally to be able to offer wine under solaris. As per the (L)GPL the > patches are all offered to the project and the diffs are distributed as a > patch kit with the binary with a pointer to winehq for the rest of the > source. Do you publish Solaris binaries regularly? If so, would you be interested in pushing them on SourceForge, with the rest of the other binary builds? > Does this answer your questions, oh and should I resubmit the patches or will > the kit do. For the purposes of getting them in the standard tree, I think you need to resubmit. I hope we can get the standard tree to build on Solaris soon. -- Dimi.

Jan. 13, 2004

Re: Solaris compile time fixes for CVS wine

by Robert Lunnon

On Thursday 08 January 2004 17:51, Dimitrie O. Paun wrote: > On January 8, 2004 01:22 am, Robert Lunnon wrote: > > Here are a buch of Solais compatibility patches for wine (Some but not > > all of them). Within the enclosed tarball the diffs are structured > > according to the wine cvs tree. There is a readme file accompanying each > > diff to explain what the change is. > > Please break the archive into one patch per message, not compressed > (preferably inlined). Here are a few pointers on how to send patches: > http://www.winehq.org/site/sending_patches > > BTW, what's the status of building Wine under Solaris? What architecture > (i386, etc) are you using? There are quite a few patches in that kit, they are organised as separate patches for each file and a description to make application easy. After extracting you could construct a single liner that would apply the entire kit. It would be relatively easy to send a dozen or so emails though, providing you don't want me to collect up the dependencies into a single e-mail As for status: Wine works quite well under Solaris x86 (Possibly better than linux based on my experience with 18062003) but can't be built and run successfully without two key patches that Alexandre has elected not to accept, and one patch which is probably acceptable but I haven't sent yet (not sure if the semantics of the code are correct for the OS yet). I also distribute it with some experimental threading code which seems to work better than the CVS code. Again the project has elected not to accept this code at this time due to it's present implementation (Because it's experimental I have arranged things to be able to select the threading model at runtime through an environment variable) Hence my port is not a stock wine. I must maintain at least the critical patches locally to be able to offer wine under solaris. As per the (L)GPL the patches are all offered to the project and the diffs are distributed as a patch kit with the binary with a pointer to winehq for the rest of the source. Right at this point I am trying to add cdrom support which is kinda tricky because the CDROM ioctl raw reading support is broken under Solaris x86 and you need to go right down to the SCSI level for raw read operations. Unfortunately this is restricted to root. But I'm doing it anyway for when it changes (less maintenance later). Does this answer your questions, oh and should I resubmit the patches or will the kit do. Bob

Jan. 13, 2004