May 2005 - Wine-devel - list.winehq.org

Re: Cannot compile man pages outside source directory
by William Poetra Yoga H 06 May '05

06 May '05

I've modified the c2man.pl script, now 'make manpages' doesn't exit with an error, but no file is written to documentation/man3w. What's wrong? The diff is attached. William Poetra Yoga Hadisoeseno __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ Index: dlls/Makedll.rules.in =================================================================== RCS file: /home/wine/wine/dlls/Makedll.rules.in,v retrieving revision 1.71 diff -u -p -r1.71 Makedll.rules.in --- dlls/Makedll.rules.in 8 Mar 2005 16:55:26 -0000 1.71 +++ dlls/Makedll.rules.in 6 May 2005 07:35:03 -0000 @@ -61,7 +61,7 @@ $(MAINSPEC).c: $(MAINSPEC) $(RC_SRCS:.rc # Rules for auto documentation man: $(C_SRCS) - $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) + $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -D$(SRCDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) doc-html: $(C_SRCS) $(C2MAN) -o $(TOPOBJDIR)/documentation/html -R$(TOPSRCDIR) $(INCLUDES) -Th $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) Index: tools/c2man.pl =================================================================== RCS file: /home/wine/wine/tools/c2man.pl,v retrieving revision 1.21 diff -u -p -r1.21 c2man.pl --- tools/c2man.pl 7 Jan 2005 17:17:23 -0000 1.21 +++ tools/c2man.pl 6 May 2005 07:35:06 -0000 @@ -42,6 +42,7 @@ my $FLAG_64PAIR = 64; # The 64 bit v # Options my $opt_output_directory = "man3w"; # All default options are for nroff (man pages) my $opt_manual_section = "3w"; +my $opt_source_dir = ""; my $opt_wine_root_dir = ""; my $opt_output_format = ""; # '' = nroff, 'h' = html, 's' = sgml my $opt_output_empty = 0; # Non-zero = Create 'empty' comments (for every implemented function) @@ -236,7 +237,7 @@ sub process_source_file($) { print "Processing ".$source_file."\n"; } - open(SOURCE_FILE,"<$source_file") || die "couldn't open ".$source_file."\n"; + open(SOURCE_FILE,"<$source_file") || open(SOURCE_FILE,"<$opt_source_dir$source_file") || die "couldn't open ".$source_file."\n"; # Add this source file to the list of source files $source_files{$source_file} = [$source_details]; @@ -2154,6 +2155,10 @@ while(defined($_ = shift @ARGV)) my $have_headers = `ls $include >/dev/null 2>&1`; if ($? >> 8 == 0) { @opt_header_file_list = (@opt_header_file_list, $include); } } + last; + }; + s/^D// && do { + if ($_ ne "") { $opt_source_dir = $_."/"; } last; }; s/^R// && do { if ($_ =~ /^\//) { $opt_wine_root_dir = $_; }

2 2

Re: shell32/brsfolder: returned pidl has to be cloned
by Michael Stefaniuc 06 May '05

06 May '05

On Fri, May 06, 2005 at 03:29:06PM +0200, Michael Jung wrote: > info->pidlRet points directly to a pidl stored in the treeview-item, which > will be free'd when the dialog is closed. Thus we have to clone the pidl > before. MSDN says that the caller of SHBrowseForFolder is responsible for > free'ing the returned pidl. > > Changelog: > Return a cloned PIDL by SHBrowseForFolder to avoid heap corruption And the patch? ;) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: unix filenames in notepad
by Michael Lin 06 May '05

06 May '05

Hi Michael, > Oops, as you see I'm undecided ;) (Anyway, this probably should be GNU ;) > However, in the final version I would like this to appear not at all in the > shell namespace, anyway. I think it would be nice if the '/' appears beside > the wine drive letters under 'My Computer'. I have been extending your work to integrate shfldr_unixfs more with open file dialog. I am modifying open file dialog to accept typed in unix path and through validation checks as well I have also fixed a bug in shfldr_unixfs and extend IPersistFolder to IPersistFolder2. I know you are working on this area as well, so maybe we should coordinate our effort so that there is no duplicate work. I know there will be issues of Windows APIs won't accept unix file path. But at this point, I just want to extend open file dialog optionally accept and return a unix file path. The flag to turn unix path on or off can be in the registry, or simply a extended flag that was passed in to OPENFILENAME struct. Michael Lin

10 13

Re: unix filenames in notepad
by William Poetra Yoga H 06 May '05

06 May '05

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > James, if an application informs us somehow (TBD) that they > can handle Unix paths, there's no reason to force the silly > drive letters on Unix users. Ideally we would even hide the > drive letter combo box in the file dialogs. > Well, maybe I could comment... I think the z: driver letter convention is ok, because: 1. Wine should provide the Windows API on top of Unix, and although extensions are OK, adding unix path handling capability is somehow "incorrect" IMO 2. Unix users using Windows software usually come from Windows 3. Windows apps ported using Winelib are usually desktop applications, and don't touch the root; they usually operate on files in the home directory. So we don't need to add unix path handling here. 4. There's already a z: drive that points to /, and it makes Wine simpler (yes, in design). Ever wondered why Microsoft software are buggy? P.S. Actually the BSD users are already quite familiar with drive letters ;) William Poetra Yoga Hadisoeseno __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

1 0

Re: unix filenames in notepad
by William Poetra Yoga H 06 May '05

06 May '05

--- Troy Rollo <wine(a)troy.rollo.name> wrote: > On Fri, 6 May 2005 09:10, James Hawkins wrote: > > wine wasn't designed to accept unix paths in the apis directly or to > > display them in open file dialogs, > > Linux wasn't designed to run Windows applications either - these things are > subject to change. > Yes, and Windows applications wasn't designed to 'see' Unix paths, whether developed on Windows (like WinZip) or on Linux (winemine). > > This just adds complexity to an already complex beast. Keep it simple. > > If it's too complex for *you* then nobody's asking *you* to implement it. > It's > needed for some uses of WINE, and we have at least one corporate developer > and one individual developer who are willing to implement it. This pretty > much guarantees something will be implemented whether it's beyond your > capabilities or not. The only real question is what is the best *way* to > implement it. > Uh... it's getting hotter here... "... one corporate developer ..." hm... ;) *If* we're at the very least worried about not having an existing z: drive (like with winecfg), I suggest we make z: a default drive for / (or is it already implemented??) So if there's already an existing z: symlink in ~/.wine/dosdevices, we use that, otherwise imply z: -> / William Poetra Yoga Hadisoeseno Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

3 2

wineconf videos on Wiki
by Andreas Mohr 06 May '05

06 May '05

Hi all, I set up a page with various video and presentation sites at http://wiki.winehq.org/WineConf Feel free to add further stuff there! Andreas

1 0

resizing?
by Maarten Lankhorst 06 May '05

06 May '05

static void Resize(CaptureBox * capBox, LPBYTE output, LPBYTE input) { if (!capBox->swresize) { int depth = capBox->bitDepth / 8; int inoffset = 0, outoffset = (capBox->height-1) * capBox->width * depth; int ow = capBox->width * depth; while (outoffset >= 0) { int x; outoffset -= ow; for (x = 0; x < ow; x++) output[outoffset + x] = input[inoffset + x]; inoffset += ow; } } else { FIXME("Software scaling not supported, I got no clue how and no-one wants to help so adding gray instead...\n"); memset(output, 128, capBox->outputwidth * capBox->outputheight * capBox->bitDepth / 8); } } I want to copy from a raw bitmap stream which is (capBox->width) x (capBox->height) (24 bits) to (capBox->outputwidth) x (capBox->outputheight) (also 24 bits), if you can argue about HAVE_V4L2 this should be easy :) I *really* need this fixed, any info is greatly appreciated.. gluScaleImage seemed ideal, but a qcap linking to glu32 would never make it to the wine source.. so a more windows-compliant(TM) solution(R) is required, since I'm a disaster in win32 programming best would be instant code of which i only need to change variable names or something (yet ironically enough i know too much of com, directshow & devenum already :-\ ) THANKS!! Maarten

2 2

wineconf video downloads
by Ivan Leo Puoti 06 May '05

06 May '05

Videos will appear here http://wineconf.geldorp.nl/ enjoy. Ivan.

10 15

[revisited] [OLE #31] Dynamically Allocate the MTA
by Dustin Navea 06 May '05

06 May '05

>Vincent Béron wrote: > >>Le mar 11/01/2005 à 14:03, Robert Shearman a écrit : >> >> >>>Changelog: >>>- Make MTA dynamically allocated so that proxies and other resources are >>>freed at the proper time. >>>- Changed/removed some incorrect comments regarding apartments. >>>---- >>> >>> >>> >> >>This patch broke wineprefixcreate invocation for me. >> >>What happens is I get a: >>X Error of failed request: BadWindow (invalid Window parameter) >> Major opcode of failed request: 18 (X_ChangeProperty) >> Resource id in failed request: 0x77e61740 >> Serial number of failed request: 107 >> Current serial number in output stream: 114 >>error while wineprefixcreate runs "wine rundll32.exe >>setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf". >> >>The error do go away if one of avifil32.dll or devenum.dll is commented >>out in [RegisterDllsSection] in wine.inf. >> >>My personal guess is that one (or both) of those dlls do something which >>they should not, and we end up with using freed or unallocated memory. >> >> > >I don't see the problem on my machine. Do the tests in dlls/ole32/tests >work for you? >Is it possible to capture a +ole log for the wineprefixcreate >invocation? >I'll do a review of the code paths that patch touches anyway, but I >don't see how it could affect things - devenum does not use MTAs and >avifil32 does not use COM. > >Rob Apparently this is affecting more than 1 user (see bug 2398). Was the cause (and a proper fix) ever found for this problem other than commenting out the necessary line? The reporter of that bug was going to do a regression test, and the Jan release was the last official release that worked, so of course this problem affected him until he found that mail. I assume so since we havent gotten any more reports of this, but I want to make sure, and find out when the problem was fixed. Dustin

4 4

Re: unix filenames in notepad
by William Poetra Yoga H 06 May '05

06 May '05

--- James Hawkins <truiken(a)gmail.com> wrote: > On 5/6/05, William Poetra Yoga H <williampoetra(a)yahoo.com> wrote: > > > > *If* we're at the very least worried about not having an existing z: drive > > (like with winecfg), I suggest we make z: a default drive for / (or is it > > already implemented??) So if there's already an existing z: symlink in > > ~/.wine/dosdevices, we use that, otherwise imply z: -> / > > > > That's the beauty of it! wineprefixcreate sets z: to point to / > automatically. Of course the user can always change what z: points > to, but / is the default location. > What I mean is, z: -> / is implied in the source. So even without a z: symlink, the z: drive will appear and contains the files in /. This is an extension by itself, but I think it's better than enabling users to input unix paths in dialog boxes. William Poetra Yoga Hadisoeseno __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1