September 2004 - Wine-Devel

Re: Acknowledgement page
by Brian Vincent Sept. 8, 2004

Sept. 8, 2004

On Sun, 5 Sep 2004 00:34:48 +0200, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > Hmm, just found that some other major developers are missing: > Aric Stewart (or is that "Codeweavers"?), Marcus Meissner, > Eric Poeuch (and that was 3 out of 5 author tries that I did). Should have explained that bit.. anyone listed on the Who's Who page doesn't show up here. This list will fall right under that on the introduction page.. but perhaps I need to add a reference back to the Who's Who page. -Brian

2 1

Simple bugzilla question
by Ann and Jason Edmeades Sept. 8, 2004

Sept. 8, 2004

Hiya, I've just set up a temporary Linux system to try to get back into doing some wine development following a break and thought I'd start by looking at some bugzilla bugs for now. I'm sure there used to be a page which showed the lifespan of a bug but for the life of me I cant see it. My understanding is I accept it and assign to myself, then fix it, then what... Do I put the bug in fixed state and submit the patch or leave that change to the raised? Jason

2 1

Re: Allow assignment of olefonts to other olefonts
by Mike Hearn Sept. 8, 2004

Sept. 8, 2004

Alexandre, is there anything wrong with this patch? > ChangeLog: > Allow assignment of olefonts to other olefonts

2 2

Installing Platform SDK on Wine
by Dan Kegel Sept. 8, 2004

Sept. 8, 2004

After (more or less) installing IE6 on Wine, I tried installing the Platform SDK. Looks like their Setup.exe program invokes IE and some ActiveX control. And it looks like I don't know how to install the msi packages without their setup.exe (maybe someone else knows?). This was with Wine-20040813, I think. I'm trying to get a valid windows.h for use with cl out of this. I may punt and just use the windows.h that comes with wine -- it doesn't work off the bat, but maybe it's easier to fix (possibly by just adding some -D's to the commandline) than the real platform sdk install. - Dan p.s. here's how I tried to install the Platform SDK #!/bin/sh # Download and install Platform SDK # See # http://www.eggheadcafe.com/ng/microsoft.public.vstudio.development/post2716… and # http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm set -ex # Platform SDK for file in \ PSDK-FULL.1.cab PSDK-FULL.2.cab PSDK-FULL.3.cab PSDK-FULL.4.cab PSDK-FULL.5.cab PSDK-FULL.6.cab \ PSDK-FULL.7.cab PSDK-FULL.8.cab PSDK-FULL.9.cab PSDK-FULL.10.cab PSDK-FULL.11.cab PSDK-FULL.12.cab \ PSDK-FULL.13.cab ; do wget -c http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-… done # Extract. Requires 1.4 GB free space! # We could download Extract.exe from the above dir, and use wine to run it, but # may as well use the native command. cabextract -d ~/.wine/c/psdk *.cab # Install. Tries to invoke IE. Doesn't work for me... cd ~/.wine/c/psdk wine Setup.exe # Directly install part of it. Doesn't work for me either; just chews CPU? cd setup wine msiexec /i CoreSDK-x86.msi -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: define RPC_NO_WINDOWS_H to prevent rpc.h from including windows.h
by Alexandre Julliard Sept. 8, 2004

Sept. 8, 2004

Mike McCormack <mike(a)codeweavers.com> writes: > ChangeLog: > * define RPC_NO_WINDOWS_H to prevent rpc.h from including windows.h Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: Wine and industrial communication like OPC
by Rickard Svensson Sept. 8, 2004

Sept. 8, 2004

> > > > Now I also got some questions from your answers: > > > > * Did I understand correctly. Wine doesn't have a built in support for DCom, to be abel to use Dcom I have to add the DCom support from Windows 98 to the Linux system? > > And the problem with that is the MS License, it stops me from distribute those XXX.dll with a Linux product (hardware and software in this case.) > > It doesn't stop you, basically the license says "you must have a Windows > license to use this code". Because it's technically a part of Windows, see? Yyyy! I hate license issues! I can see that for many people this wouldn't be an issue, because they probably have some old Win 98 CD/Licens somewhere (if they even care). But for a company that would like to send it as part of an embedded computer with Linux I can se a lot of problems. > However a Windows license is quite cheap relative to $3000-$4000 for the > APIs so maybe this isn't a problem. But that was per development project, not per system we want to use OPC in. > You could even buy copies of Windows 98 off ebay or something for > ultra-cheap living. The license can be for any version of Windows AFAIK. That could perhaps be an idea.... What does AFAIK stand for? > The difficulty may be that nobody has tested network DCOM servers on > Wine as far as I know, even using Microsofts implementation. So you'd be > doing some pioneering work :) That is good ;-) In the industry we are a lot of people who really question the total madness of letting the OPC standard be that depended on Windows, when it is supposed to be a "free" organization. My hope if I can get this to work is to publish a site on the net so all who want to use Linux in the industrial computing can do that quite easy... But then we have the license issues to :-( > - Wines own, builtin code. This is incomplete and cannot do what you want. > > - Microsofts DCOM implementation > > Wine *does* have support for MSRPC, and I think it's wire compatible > with Windows these days and capable of making simple RPCs. However the > RPC runtime (rpcrt4.dll) is just the first layer of DCOM, all the rest > don't work right yet. Ok, now I understand, and also why I got confused before. And there is a lot of work needed to make DCom to work in Wine? Is someone working on it or is it something that not is that important in other cases? Thanks a lot Mike for you answer! /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

5 4

Re: Fix bin2res Help Text
by Dimitrie O. Paun Sept. 7, 2004

Sept. 7, 2004

On Mon, Sep 06, 2004 at 02:37:05AM +0100, Robert Shearman wrote: > " /* BINRES idb_std_small.bmp */\n" > - " {}\n" > + " IDB_STD_SMALL BITMAP idb_std_small.bmp\n" > + " /* {\n" > + " } */\n" What's wrong with the current help. I thought BINRES is the marker... -- Dimi.

1 0

More winecfg todos
by Mike Hearn Sept. 7, 2004

Sept. 7, 2004

On Thu, 29 Jul 2004 23:19:11 -0500, Alexandre Julliard wrote: > Log message: > James Hawkins <truiken(a)gmail.com> > Under the Drives tab, remove the 'Windows Drive' section. You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff. Also we should kill the autodetect button. This is done by wineprefixcreate these days, or should be. Other things are: - Drive editing seems broken. The list box only updates the second time I hit edit. err:winecfg:applyDriveChanges unable to set volume label for devicename of 'H:\', label of '' - Browse in the "Add/Edit drive" dialog is a WRITEME - Build system isn't right: I did a cvs update but the res files weren't recreated properly. I had to do a make clean to get the gui updates. - "Add Application" has poor usability: we always use a file browser dialog box even though the most common use case is just "foo.exe", ie the user knows the name and doesn't care about the location. Worse we start in the c:\windows\desktop folder for some reason, meaning users might accidentally select a .lnk file! Ditto for Libraries tab. - The Add/Remove application buttons are *way* too big! - Obviously, once audio autodetection has been moved into the drivers we need to kill the audio tab. - Libraries tab just has generally poor usability, actually. The first item in the radio group is "Builtin" meaning that's the one users are most likely to select, it should be "builtin, native" followed by "native, builtin" - We ask the user to understand a magic * symbol to set the default - what is up with that? - There are no helpful default entries in the drop down box for setting a DLL override, and when you add one the tree does not expand so to actually *set* it you have to expand the tree then select the new override. - We have way too many (eg, more than zero) tree controls in this app. - Drive mappings list is really unclear, there's no separation between the "Drive X:" label and the unix path its mapped to. Basically I'd recommend reading the GNOME HIG: http://developer.gnome.org/projects/gup/hig/ it's a very informative read. Obviously we have to use Win32 UI conventions at least at first, but there's a lot of generically good advice there. Well worth reading for anybody who is going to work on winecfg. thanks -mike

4 4

Re: Create DLL stub files in c:\windows\system
by Hans Leidekker Sept. 7, 2004

Sept. 7, 2004

On Saturday 4 September 2004 14:25, Mike Hearn wrote: > Make apps that search for the DLL files directly happy by creating empty > files for each shipped library There are applications (eDonkey is one of them IIRC) that call LoadLibray() themselves on a number of DLLs. Could be that they do their own linking as part of some anti-debugging technique, I don't know, but it's perfectly legal for application to do that anyway. For these apps having empty DLL files will not be enough. I actually was able to fool the app by putting MinGW cross compiled Wine DLLs in the system directory until it needed kernel32.dll, which doesn't compile. I had to resort to a native win2k kernel32.dll to get it past this but this may still be a good alternative to your empty DLL files. -Hans

8 17

Re: windos: fix EXTENDED COUNTRY INFORMATION
by Vincent Béron Sept. 7, 2004

Sept. 7, 2004

Le mar 07/09/2004 à 06:10, Markus Amsler a écrit : [snip] > *** wine/dlls/winedos/int21.c Tue Aug 24 17:45:23 2004 > --- wine-20040615/dlls/winedos/int21.c Fri Aug 6 11:57:04 2004 > *************** > *** 2116,2123 **** > static void INT21_ExtendedCountryInformation( CONTEXT86 *context ) > { > BYTE *dataptr = CTX_SEG_OFF_TO_LIN( context, context->SegEs, context->Edi ); > ! BYTE buffsize = CX_reg (context); > ! > TRACE( "GET EXTENDED COUNTRY INFORMATION, subfunction %02x\n", > AL_reg(context) ); Please send your patches in diff unified (diff -u) format. Vincent

1 0