Re: New program: getsffile
On 5/5/05, Jakob Eriksson [EMAIL PROTECTED] wrote: Maybe I'm being thick, but why do you need to change winrash for that? winrash has the ability to upgrade itself from sf. We could also host the winetest versions there, however the real problem is uploading to sf, so I'm not sure how important that part is. -Brian
Re: Regression in Half life
Am Freitag, 6. Mai 2005 04:28 schrieb Tom Wickline: On 5/5/05, Stefan Dösinger [EMAIL PROTECTED] wrote: Hello, These two patches cause a regression in Half-Life (Version 1.1.1.0): (1)http://www.winehq.org/hypermail/wine-cvs/2005/04/0307.html (2)http://www.winehq.org/hypermail/wine-cvs/2005/04/0308.html Half-life reports ChoosePixelFormat failed, followed by The Selected OpenGL mode is not supported by your card when starting the engine. Wine prints the following error: err:opengl:X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0) Reversing the above 2 patches fixes the problem. Reversing patch 1 only causes a crash, if I reverse only patch 2 the problem still exists. Cheers, Stefan snip fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:mmtime:timeEndPeriod Stub; we set our timer resolution at minimum If you change your BPP from 16 to 24 in your X config it should work. I am already running with 24bpp. From my xorg.cfg: Section Screen Identifier Screen0 Device Card0 MonitorMonitor0 DefaultDepth 24 SubSection Display Depth 1 EndSubSection SubSection Display Depth 4 EndSubSection SubSection Display Depth 8 Modes1024x768 800x600 640x480 1400x1050 1280x1024 1280x960 EndSubSection SubSection Display Depth 15 Modes1400x1050 1280x1024 1280x960 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes1400x1050 1280x1024 1280x960 1024x768 800x600 640x480 EndSubSection SubSection Display #Virtual 3200 2400 Depth 24 Modes1400x1050 1280x1024 1280x960 1024x768 800x600 640x480 EndSubSection EndSection
Re: Cannot compile man pages outside source directory
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 - 1.71
+++ dlls/Makedll.rules.in 6 May 2005 07:35:03 -
@@ -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 - 1.21
+++ tools/c2man.pl 6 May 2005 07:35:06 -
@@ -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 21`;
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 = $_; }
Re: unix filenames in notepad
--- James Hawkins [EMAIL PROTECTED] wrote: On 5/6/05, William Poetra Yoga H [EMAIL PROTECTED] 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
Re: Winelib's role in converting Windows applications
Ira Krakow wrote: As many of you know, Brian and I are writing a book on Wine and Winelib for Prentice Hall. Brian's doing the Wine part; I'm doing the Winelib part. At Wineconf, I had a number of conversations about Winelib's role in converting Windows apps. The consensus seems to be that the most efficient conversion path is for much of the Windows app to stay in Visual C++ (or whatever) and that only the modules that specifically require native Linux calls should be recompiled, via MinGW/Dev-C++ on the Windows side, and Winemaker on the Linux side, into Winelib objects. This is true, the only good reason to still recompile everything as Winelib stuff is if you need to run your programs on an other CPU architecture like PPC or SPARC. But for that you need to have the whole source for your application because binary DLLs wont work. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Google Web Accelerator
Matthew Mastracci a écrit :
It seems to die after a few minutes of browsing with what appears to be
an async IO error. The strange thing is that the error code looks like
a memory location rather than a winsock error:
fixme:winsock:NtStatusToWSAError Status code 77ce16c0 converted to DOS
error code 77ce16c0
fixme:winsock:WS2_async_send status: c120
[EMAIL PROTECTED] temp]$ cd /tmp/wine/dlls/winsock
this should fix it
Index: socket.c
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/winsock/socket.c,v
retrieving revision 1.178
diff -u -u -r1.178 socket.c
--- socket.c5 May 2005 09:49:43 - 1.178
+++ socket.c6 May 2005 08:26:48 -
@@ -1032,8 +1032,9 @@
if ( status ) iosb-u.Status = status;
if ( iosb-u.Status != STATUS_PENDING )
{
+status = iosb-u.Status;
(apc)( wsa, iosb, iosb-u.Status );
-return iosb-u.Status;
+return status;
}
NtCurrentTeb()-num_async_io++;
return STATUS_SUCCESS;
--
Eric Pouech
Re: resizing?
Maarten Lankhorst wrote: 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 :-\ ) This shouldn't be needed. A filter should any resizing, but I don't remember there being a resize filter in DirectShow. Rob
Re: [revisited] [OLE #31] Dynamically Allocate the MTA
Dustin Navea wrote:
Rob Shearman wrote:
The problem was a heap overrun in quartz. The bug was fixed. I
haven't seen any more reports of this problem with cvs Wine.
Ok, thanks. He is having to use the jan copy to regression test.
Could you provide me a link to the cvs patch that fixed it so he can
download it and apply it to the jan copy, since he is doing a
regression test? That way he can have a proper test.
Mike Hearn [EMAIL PROTECTED]
Fix heap corruption in quartz server registration, add
some whitespace, break out of loop if out of memory
--- dlls/quartz/regsvr.c (revision 109)
+++ dlls/quartz/regsvr.c (local)
@@ -577,7 +577,6 @@ static HRESULT register_filters(struct r
IFilterMapper2* pFM2 = NULL;
CoInitialize(NULL);
-
hr = CoCreateInstance(CLSID_FilterMapper2, NULL, CLSCTX_INPROC_SERVER, IID_IFilterMapper2, (LPVOID*)pFM2);
if (SUCCEEDED(hr)) {
@@ -585,6 +584,7 @@ static HRESULT register_filters(struct r
REGFILTER2 rf2;
REGFILTERPINS2* prfp2;
int i;
+
for (i = 0; list-pins[i].flags != 0x; i++) ;
rf2.dwVersion = 2;
rf2.dwMerit = list-merit;
@@ -598,6 +598,7 @@ static HRESULT register_filters(struct r
REGPINTYPES* lpMediatype;
CLSID* lpClsid;
int j, nbmt;
+
for (nbmt = 0; list-pins[i].mediatypes[nbmt].majortype; nbmt++) ;
/* Allocate a single buffer for regpintypes struct and clsids */
lpMediatype = (REGPINTYPES*) CoTaskMemAlloc(nbmt*(sizeof(REGPINTYPES) + 2*sizeof(CLSID)));
@@ -627,10 +628,17 @@ static HRESULT register_filters(struct r
prfp2[i].clsPinCategory = NULL;
}
+ if (FAILED(hr)) {
+ ERR(failed to register with hresult 0x%lx\n, hr);
+ break;
+ }
+
hr = IFilterMapper2_RegisterFilter(pFM2, list-clsid, list-name, NULL,
list-category, NULL, rf2);
- while (i--)
+ while (i) {
CoTaskMemFree((REGPINTYPES*)prfp2[i-1].lpMediaType);
+ i--;
+ }
CoTaskMemFree(prfp2);
}
}
Re: resizing?
Robert Shearman wrote: Maarten Lankhorst wrote: 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 :-\ ) This shouldn't be needed. A filter should any resizing, but I don't remember there being a resize filter in DirectShow. Rob As far as I can tell, there is no resize filter, I checked graphedit and couldn't find one in the filter list even with native quartz, so I'm still interested in software resizing, I could just do clipping or filling with nulls, but there should be a better way, if I can't find it though I'll use clip/zero fill, my webcam doesn't need it but it would be nice for others...
wineconf videos on Wiki
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
Re: Wine Wiki Status
On Fri, 06 May 2005 00:45:05 -0400, Dimitrie O. Paun wrote: However, this episode forced me to at least require that you sign up before you can edit a page. This is probably a good idea anyway, I hope people agree. The slashdotting has passed, I doubt it'll be a problem again. I should have known better than to directly link to it from the story. D'oh! thanks -mike
Re: Wine Wiki Status
On Fri, May 06, 2005 at 12:12:01PM +0100, Mike Hearn wrote: The slashdotting has passed, I doubt it'll be a problem again. I should have known better than to directly link to it from the story. D'oh! Don't worry, it wasn't a big deal, I think it was OK to post to ./ And hey, it was a good server test, we survived just fine! :) I wanted to require that you login to edit anyway, it was so easy to forget that I even forgot a few times. Do people want to go back to the old way, and allow even not logged in people edit? -- Dimi.
Re: unix filenames in notepad
On Fri, May 06, 2005 at 02:12:22AM -0500, James Hawkins wrote: 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. 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. -- Dimi.
Re: unix filenames in notepad
--- Dimitrie O. Paun [EMAIL PROTECTED] 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
Re: Wine Wiki Status
Dimitrie O. Paun wrote: On Fri, May 06, 2005 at 12:12:01PM +0100, Mike Hearn wrote: The slashdotting has passed, I doubt it'll be a problem again. I should have known better than to directly link to it from the story. D'oh! Don't worry, it wasn't a big deal, I think it was OK to post to ./ And hey, it was a good server test, we survived just fine! :) I wanted to require that you login to edit anyway, it was so easy to forget that I even forgot a few times. Do people want to go back to the old way, and allow even not logged in people edit? I would vote against it. To login is not hard and that way you know whom to blame^Hthank for the change ;) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Wine Wiki Status
Dimitrie O. Paun wrote: On Fri, May 06, 2005 at 12:12:01PM +0100, Mike Hearn wrote: I wanted to require that you login to edit anyway, it was so easy to forget that I even forgot a few times. Do people want to go back to the old way, and allow even not logged in people edit? New to the list, and with not much weight on my words, but still... I gather a required log in would be the way to go. Why? Well, imagine your basic net troll stumbling on wine wiki. Hey! I can edit these! Cool. Let's just take all of those out, yeah, and add to the Project Ideas some cool projects like CoLd FUsiON! Yeah! Get my point? Regards, Jani Kärkkäinen
Re: unix filenames in notepad
James Hawkins wrote: On 5/5/05, Troy Rollo [EMAIL PROTECTED] wrote: Precisely. WINE is not just for running apps compiled for Windows - it's also for making the Windows API available under UNIX. For this second application, users need to (at a minimum) be seeing UNIX paths (and not Windows paths at all) in the dialog. It is also reasonable in this context for the application to expect to use APIs with UNIX paths without having to convert them. wine wasn't designed to accept unix paths in the apis directly or to display them in open file dialogs, and that's why we have virtual drives. Whether or not wine was originally designed for this, winelib as it exists right now is great for making a unix-native version of a windows program. The commercial porting library I have experience with behaves exactly this way -- Windows API functions took and returned native unix paths, and everything displayed to the user looked like a normal unix path. We found this to be a very natural way for a porting library to behave. I'm not saying that this should be the only way winelib should behave, or even that it should be the default way. It seems like several of us have already made our own hacks to get winelib to work this way -- it would be a shame not to at least make unix paths an option. In our application, we would often take a filename that came from a windows API function, (say, a Save File dialog), and do something like construct a std::ofstream() using that path. Since the standard library wasn't compiled against wine, it gets confused by the windows paths, and creates a file named 'z:\tmp\foo.txt' in the current directory, instead of '/tmp/foo.txt' like I want it to. Yes, we could've figured out how to compile all of our third-party libraries against wine and it would've worked, but that can be a *lot* of work and you still don't end up with an application that looks at home on unix. I'm leaning toward the separate entry point solution (the various approaches were canvassed here a couple of weeks ago) since it avoids problems with Microsoft adding new flags of their own later that use the same values as WINE specific flags. This just adds complexity to an already complex beast. Keep it simple. So far, the separate entry point solution sounds like the best one to me also, at least for selecting what the API functions expect return. I'm not sure about the best way to select whether unix paths are displayed to the user or not. Since that could also benefit windows-native applications, that preference might be better off stored in the registry or elsewhere. Eric
Re: Re: Regression in Half life
Hi, snip Uh, no, this doesn't help :-( Half-life supports only 16bpp(well, I can set it to other values with regedit, but it seems to have no effect), fglrx supports 24bpp only. No problem here. I switched to the Xorg radeon driver which has 16 bpp support(the 2nd column shows 16 now), and made sure that hl runs with 16bpp, but the error still occurs. Yes it don't work, because you speak about frame buffer (named Color buffer on traces) when you speak about 16bpp. I spoke about depth buffer snip - Depth : 32 Is half-Life still trying to get 32bpp? Yes, but not 32bpp for frame buffer only for depth buffer (usually Z-buffer) But even if it worked this way, this wouldn't be a good solution for ATI users, because playing newer games with the radeon driver is horrible. (e.g. Jedi Academy, gl-117, even tuxracer makes problems). Removing the failing check from Wine's opengl code doesn't help, it causes a hard crash later. Yes because game expect 32bpp for Depth buffer and if game try to read directly into this buffer you'll have some problems Regards, Raphael
Re: Cannot compile man pages outside source directory
OK, now the script works correctly. But I think we have to test it some more,
so... any volunteers?
William Poetra Yoga Hadisoeseno
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.htmlIndex: 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 - 1.71
+++ dlls/Makedll.rules.in 6 May 2005 13:44:11 -
@@ -61,13 +61,13 @@ $(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)
+ $(C2MAN) -o $(TOPOBJDIR)/documentation/html -R$(TOPSRCDIR) -D$(SRCDIR)
$(INCLUDES) -Th $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16)
doc-sgml: $(C_SRCS)
- $(C2MAN) -o $(TOPOBJDIR)/documentation/api-guide -R$(TOPSRCDIR)
$(INCLUDES) -Ts $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16)
+ $(C2MAN) -o $(TOPOBJDIR)/documentation/api-guide -R$(TOPSRCDIR)
-D$(SRCDIR) $(INCLUDES) -Ts $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS)
$(C_SRCS16)
.PHONY: man doc-html doc-sgml
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 - 1.21
+++ tools/c2man.pl 6 May 2005 13:44:13 -
@@ -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)
@@ -120,7 +121,7 @@ sub process_spec_file($)
# We allow opening to fail just to cater for the peculiarities of
# the Wine build system. This doesn't hurt, in any case
- open(SPEC_FILE, $spec_name) || return;
+ open(SPEC_FILE, $spec_name) || open(SPEC_FILE,
$opt_source_dir/$spec_name) || return;
while(SPEC_FILE)
{
@@ -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];
@@ -2115,6 +2116,9 @@ sub usage()
Options:\n,
-Th : Output HTML instead of a man page\n,
-Ts : Output SGML (Docbook source) instead of a man page\n,
+ -D dir : Source directory, to find source files if they are not
found in the\n,
+current directory. Default is \,$opt_source_dir,\\n,
+ -R dir : Root of build directory, default is
\,$opt_wine_root_dir,\\n,
-o dir : Create output in dir, default is
\,$opt_output_directory,\\n,
-s sect: Set manual section to sect, default is
,$opt_manual_section,\n,
-e : Output \FIXME\ documentation from empty comments.\n,
@@ -2156,6 +2160,10 @@ while(defined($_ = shift @ARGV))
}
last;
};
+ s/^D// do {
+ if ($_ ne ) { $opt_source_dir = $_; }
+ last;
+ };
s/^R// do { if ($_ =~ /^\//) { $opt_wine_root_dir = $_; }
else { $opt_wine_root_dir = `cd $pwd/$_ pwd`; }
$opt_wine_root_dir =~ s/\n//;
@@ -2181,8 +2189,9 @@ if ($opt_verbose 3)
{
print Output dir:'.$opt_output_directory.'\n;
print Section :'.$opt_manual_section.'\n;
- print Format :'.$opt_output_format.'\n;
- print Root:'.$opt_wine_root_dir.'\n;
+ print Format:'.$opt_output_format.'\n;
+ print Source dir:'.$opt_source_dir.'\n;
+ print Root :'.$opt_wine_root_dir.'\n;
print Spec files:'@opt_spec_file_list'\n;
print Includes :'@opt_header_file_list'\n;
print Sources :'@opt_source_file_list'\n;
Re: LockDIBSection problem
Rein Klazes [EMAIL PROTECTED] writes: I managed to fixed it in two ways: 1. put a X11DRV_CoerceDIBSection( physDevDst, DIB_Status_InSync, FALSE ); at the end of X11DRV_BitBlt. This probably defeats the whole purpose of these protections so: 2. Add a IsBadReadPtr( buffer, bytesToWrite) in the top of WriteFile to force an exception and everything works. Would that be an acceptable fix? We don't want that at the top of WriteFile, but it could be OK to add special handling of the INVALID_USER_BUFFER error, with a big FIXME comment... -- Alexandre Julliard [EMAIL PROTECTED]
Re: shell32/brsfolder: returned pidl has to be cloned
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 EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgpOgeJklI774.pgp Description: PGP signature
Re: Revisiting exceptions
Mike Hearn [EMAIL PROTECTED] writes: Hi Alexandre, I got bored and took a stab at doing proper SEH macros using some GCC extensions I found. These are rather rough, unfinished definitions, and they aren't tested at all but do they look OK? They clearly won't work as is, but if your question is whether it's possible to use attribute((cleanup)), then yes you could probably use that to make the current macros more compatible. Obviously that would be only as an option for Winelib apps since it's not portable. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Debugging remotely from Visual studio
Eric Pouech wrote:
- kernel send a trap signal
- wine's ntdll catches it, and queue the information as a debug event in
the wineserver
- the debugger (msvcmon in your case) get notified of the trap while
waiting for a debug event
I understand.
I made a log of what happens when I single step with the debugger:
I see the debugger waking up
001b: *wakeup* signaled=258 cookie=0x2f9ce4
then, a little further it get the exception status
001b: get_exception_status() = 0
{status=65538,context={flags=00010007,...,eflags=00210346,...}}
and then the same thread has a lot of lines in the log with the same message
001b: *signal* signal=5
until the message
001b:warn:seh:setup_exception exception outside of stack limits in
thread 001b eip 002b448d esp 019b12ec stack 0x19b-0x1ab
It clearly looks like a recursive call, or an infinite loop.
Any idea of what can trigger such a behaviour ?
Another question that could be related is the status of the trace flag
in EFlags (0x100). It looks like wine clears it in some of its code
(raise_trap_exception and the handler for SIGTRAP in signal_i386.c).
Shouldn't it be the debugger responsibilty ?
Thanks
David Hemmo
PS: I hope I am clear enough. Don't hesitate to contact me if anything
is missing, or not clear.
Re: Cannot compile man pages outside source directory
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
Just a detail but you probably want to use -C instead of -D for that
option, it's what the other tools like makedep or winebuild use for
that purpose.
OK, it's -C now. By the way, I think the checks when assigning $opt_source_dir
are a bit simpler (maybe too simple?) than those for other command line
options...
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 - 1.71
+++ dlls/Makedll.rules.in 6 May 2005 15:12:52 -
@@ -61,13 +61,13 @@ $(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)
-C$(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)
+ $(C2MAN) -o $(TOPOBJDIR)/documentation/html -R$(TOPSRCDIR) -C$(SRCDIR)
$(INCLUDES) -Th $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16)
doc-sgml: $(C_SRCS)
- $(C2MAN) -o $(TOPOBJDIR)/documentation/api-guide -R$(TOPSRCDIR)
$(INCLUDES) -Ts $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16)
+ $(C2MAN) -o $(TOPOBJDIR)/documentation/api-guide -R$(TOPSRCDIR)
-C$(SRCDIR) $(INCLUDES) -Ts $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS)
$(C_SRCS16)
.PHONY: man doc-html doc-sgml
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 - 1.21
+++ tools/c2man.pl 6 May 2005 15:12:56 -
@@ -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)
@@ -120,7 +121,10 @@ sub process_spec_file($)
# We allow opening to fail just to cater for the peculiarities of
# the Wine build system. This doesn't hurt, in any case
- open(SPEC_FILE, $spec_name) || return;
+ open(SPEC_FILE, $spec_name)
+ || (($opt_source_dir ne )
+ open(SPEC_FILE, $opt_source_dir/$spec_name))
+ || return;
while(SPEC_FILE)
{
@@ -236,7 +240,10 @@ 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)
+ || (($opt_source_dir ne )
+ 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];
@@ -2115,6 +2122,9 @@ sub usage()
Options:\n,
-Th : Output HTML instead of a man page\n,
-Ts : Output SGML (Docbook source) instead of a man page\n,
+ -C dir : Source directory, to find source files if they are not
found in the\n,
+current directory. Default is \,$opt_source_dir,\\n,
+ -R dir : Root of build directory, default is
\,$opt_wine_root_dir,\\n,
-o dir : Create output in dir, default is
\,$opt_output_directory,\\n,
-s sect: Set manual section to sect, default is
,$opt_manual_section,\n,
-e : Output \FIXME\ documentation from empty comments.\n,
@@ -2156,6 +2166,10 @@ while(defined($_ = shift @ARGV))
}
last;
};
+ s/^C// do {
+ if ($_ ne ) { $opt_source_dir = $_; }
+ last;
+ };
s/^R// do { if ($_ =~ /^\//) { $opt_wine_root_dir = $_; }
else { $opt_wine_root_dir = `cd $pwd/$_ pwd`; }
$opt_wine_root_dir =~ s/\n//;
@@ -2181,8 +2195,9 @@ if ($opt_verbose 3)
{
print Output dir:'.$opt_output_directory.'\n;
print Section :'.$opt_manual_section.'\n;
- print Format :'.$opt_output_format.'\n;
- print Root:'.$opt_wine_root_dir.'\n;
+ print Format:'.$opt_output_format.'\n;
Re: Wine Wiki Status
Can you post the Balmer image someplace else on the wiki for us to see? Can you email it me? :-) Dimitrie O. Paun wrote: A few things: 1. We've been attacked Wed by one or two idiots from Slashdot. They kept replacing the content of the front page with some silly Balmer images :) Not a big deal, since MoinMoin makes it a snap to revert to an older version. However, this episode forced me to at least require that you sign up before you can edit a page. This is probably a good idea anyway, I hope people agree. 2. I've placed the modifications to the code on the Wine CVS repository at SourceForge in the 'wiki' module. Please feel free to check it out and send in patches (sending them to [EMAIL PROTECTED] with a subject prefix of 'Wiki:' is fine, or directly to me if you prefer). 3. Mike is right, the namespacing stuff if not a good idea. I'll try to get rid of it, I'm going to try to rename the page, but first I have to enable the feature. If not, I'll just simply recreate them. As always, you comments, suggestions and complaints are most welcome.
Re: unix filenames in notepad
Hello, William Poetra Yoga H wrote: 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. Well, as a user I still like to have Unix paths in the dialog box if I buy a Linux application (as I user I don't care whether it uses internally wine/winelib or Gtk or Qt). I don't want to convert /home/user/a very long path/FOO/my.file into z:\home\user\a very long\path\FOO\my.file instead of simply pasting it into the open-file dialog. (I actually would expect that /FOO/ and /foo/ are distingushed and that a filename like My\funny\file works, ok no one uses '\' for filenames, but having both /PDF/ and /pdf/ happend actually to me. ;) But this is from a pure user point of view. Tobias, who has a Corel Draw for Linux which doesn't want to run anymore.
Re: Commercial support
Tom Wickline wrote: On 5/5/05, Jakob Eriksson [EMAIL PROTECTED] wrote: So, Are you saying I'm a Nazi for putting what you would consider a high price tag on a listing? All I'm saying is the referral by No. It was Andreas Mohr who first made the reference to the Third Reich. I just pointed out that we now have made it to the Godwin point... Well if you want to consider me as a Nazi for standing up and saying that a listing is worth more than what you consider as being fair then I guess ill have to be called such names. No... the Godwin reference is used on Usenet to cool a discussion before it goes into flaming mode. So if I offended you, or Andreas, or anyone else I'm deeply sorry. To go back to the original discussion, I agree that there should be _something_ holding back the free loaders. Not sure exactly what, so I'm monitoring the Commercial support thread to see what the consensus ends up as. regards, Jakob
Re: Re[3]: Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
On Thu, 2005-05-05 at 23:39 +, Jules Richardson wrote: If the problem's likely to be in x11drv then I can do some poking around tomorrow; a diff between the source for 20041201 and 20050111 might give some clues as to what's happening... Hmm, well dlls/x11drv/winpos.c and window.c certainly look like possible candidates for the cause of this redraw problem; it seems like a lot of changes went in there between 20041201 and 20050111 related to redraw / region handling according to the changelog. (and of course winpos.c is what Vitaliy's patch from yesterday relates to) It's almost certainly beyond me to try and fix the problem though; I don't understand how Wine works under the covers, how all the files fit together and what each does etc. - I'm happy to test any ideas / patches that anyone might be able to come up with though. cheers Jules
Re[5]: Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
You know, it could be one more place then. Native does RedrawWindow when focus changes. But not always. As soon as I figure out when we need to redraw and when we don't, I'll send you a patch to try. Friday, May 6, 2005, 9:25:45 AM, you wrote: On Thu, 2005-05-05 at 23:39 +, Jules Richardson wrote: If the problem's likely to be in x11drv then I can do some poking around tomorrow; a diff between the source for 20041201 and 20050111 might give some clues as to what's happening... Hmm, well dlls/x11drv/winpos.c and window.c certainly look like possible candidates for the cause of this redraw problem; it seems like a lot of changes went in there between 20041201 and 20050111 related to redraw / region handling according to the changelog. (and of course winpos.c is what Vitaliy's patch from yesterday relates to) It's almost certainly beyond me to try and fix the problem though; I don't understand how Wine works under the covers, how all the files fit together and what each does etc. - I'm happy to test any ideas / patches that anyone might be able to come up with though. cheers Jules
Re: [DSOUND] move initialization (revised patch)
Robert Reif wrote:
Move initialization to IDirectSound_Initialize.
Fix error paths to handle a failed IDirectSound_Initialize.
Add tests for IDirectSound_Initialize.
This patch fixes wine to fail the same way windows does
when run with a defective device driver.
This revised patch fixes a problem when trying to initialize an
initialized object when creating the object more than once.
Index: dlls/dsound/dsound.c
===
RCS file: /home/wine/wine/dlls/dsound/dsound.c,v
retrieving revision 1.31
diff -u -p -r1.31 dsound.c
--- dlls/dsound/dsound.c15 Mar 2005 15:40:36 - 1.31
+++ dlls/dsound/dsound.c6 May 2005 16:02:54 -
@@ -684,11 +684,107 @@ static HRESULT WINAPI IDirectSoundImpl_I
LPCGUID lpcGuid)
{
IDirectSoundImpl *This = (IDirectSoundImpl *)iface;
+HRESULT hr = DS_OK;
TRACE((%p,%s)\n,This,debugstr_guid(lpcGuid));
-This-initialized = TRUE;
+if (This-initialized == TRUE) {
+WARN(already initialized\n);
+return DSERR_ALREADYINITIALIZED;
+}
-return DS_OK;
+/* If the driver requests being opened through MMSYSTEM
+ * (which is recommended by the DDK), it is supposed to happen
+ * before the DirectSound interface is opened */
+if (This-drvdesc.dwFlags DSDDESC_DOMMSYSTEMOPEN)
+{
+DWORD flags = CALLBACK_FUNCTION;
+
+/* disable direct sound if requested */
+if (ds_hw_accel != DS_HW_ACCEL_EMULATION)
+flags |= WAVE_DIRECTSOUND;
+
+hr = mmErr(waveOutOpen((This-hwo),
+This-drvdesc.dnDevNode, This-pwfx,
+(DWORD)DSOUND_callback, (DWORD)This,
+flags));
+if (hr != DS_OK) {
+WARN(waveOutOpen failed\n);
+return hr;
+}
+}
+
+if (This-driver) {
+hr = IDsDriver_Open(This-driver);
+if (hr != DS_OK) {
+WARN(IDsDriver_Open failed\n);
+return hr;
+}
+
+/* the driver is now open, so it's now allowed to call GetCaps */
+hr = IDsDriver_GetCaps(This-driver,(This-drvcaps));
+if (hr != DS_OK) {
+WARN(IDsDriver_GetCaps failed\n);
+return hr;
+}
+} else {
+WAVEOUTCAPSA woc;
+hr = mmErr(waveOutGetDevCapsA(This-drvdesc.dnDevNode, woc,
sizeof(woc)));
+if (hr != DS_OK) {
+WARN(waveOutGetDevCaps failed\n);
+return hr;
+}
+ZeroMemory(This-drvcaps, sizeof(This-drvcaps));
+if ((woc.dwFormats WAVE_FORMAT_1M08) ||
+(woc.dwFormats WAVE_FORMAT_2M08) ||
+(woc.dwFormats WAVE_FORMAT_4M08) ||
+(woc.dwFormats WAVE_FORMAT_48M08) ||
+(woc.dwFormats WAVE_FORMAT_96M08)) {
+This-drvcaps.dwFlags |= DSCAPS_PRIMARY8BIT;
+This-drvcaps.dwFlags |= DSCAPS_PRIMARYMONO;
+}
+if ((woc.dwFormats WAVE_FORMAT_1M16) ||
+(woc.dwFormats WAVE_FORMAT_2M16) ||
+(woc.dwFormats WAVE_FORMAT_4M16) ||
+(woc.dwFormats WAVE_FORMAT_48M16) ||
+(woc.dwFormats WAVE_FORMAT_96M16)) {
+This-drvcaps.dwFlags |= DSCAPS_PRIMARY16BIT;
+This-drvcaps.dwFlags |= DSCAPS_PRIMARYMONO;
+}
+if ((woc.dwFormats WAVE_FORMAT_1S08) ||
+(woc.dwFormats WAVE_FORMAT_2S08) ||
+(woc.dwFormats WAVE_FORMAT_4S08) ||
+(woc.dwFormats WAVE_FORMAT_48S08) ||
+(woc.dwFormats WAVE_FORMAT_96S08)) {
+This-drvcaps.dwFlags |= DSCAPS_PRIMARY8BIT;
+This-drvcaps.dwFlags |= DSCAPS_PRIMARYSTEREO;
+}
+if ((woc.dwFormats WAVE_FORMAT_1S16) ||
+(woc.dwFormats WAVE_FORMAT_2S16) ||
+(woc.dwFormats WAVE_FORMAT_4S16) ||
+(woc.dwFormats WAVE_FORMAT_48S16) ||
+(woc.dwFormats WAVE_FORMAT_96S16)) {
+This-drvcaps.dwFlags |= DSCAPS_PRIMARY16BIT;
+This-drvcaps.dwFlags |= DSCAPS_PRIMARYSTEREO;
+}
+if (ds_emuldriver)
+This-drvcaps.dwFlags |= DSCAPS_EMULDRIVER;
+This-drvcaps.dwMinSecondarySampleRate = DSBFREQUENCY_MIN;
+This-drvcaps.dwMaxSecondarySampleRate = DSBFREQUENCY_MAX;
+This-drvcaps.dwPrimaryBuffers = 1;
+}
+
+hr = DSOUND_PrimaryCreate((IDirectSoundImpl*)This);
+if (hr == DS_OK) {
+This-initialized = TRUE;
+DSOUND_renderer = (IDirectSoundImpl*)This;
+timeBeginPeriod(DS_TIME_RES);
+DSOUND_renderer-timerID = timeSetEvent(DS_TIME_DEL, DS_TIME_RES,
DSOUND_timer,
+(DWORD)DSOUND_renderer, TIME_PERIODIC | TIME_CALLBACK_FUNCTION);
+} else {
+WARN(DSOUND_PrimaryCreate failed\n);
+}
+
+return hr;
}
static HRESULT WINAPI IDirectSoundImpl_VerifyCertification(
@@ -841,11 +937,11 @@ HRESULT WINAPI IDirectSoundImpl_Create(
return DSERR_OUTOFMEMORY;
Re: Revisiting exceptions
On Fri, 2005-05-06 at 16:23 +0200, Alexandre Julliard wrote: They clearly won't work as is, but if your question is whether it's possible to use attribute((cleanup)), then yes you could probably use that to make the current macros more compatible. Obviously that would be only as an option for Winelib apps since it's not portable. Sure, that's what I was asking. I wanted to see if we could make break/continue/return work inside TRY macros, which this technique seems to give. As we already decided it'd need compiler support it's no big deal that it's not portable (between compilers). At least it probably works on an unmodified GCC. So now if somebody wants to go ahead and improve our SEH macros using this technique, please, be my guest ... thanks -mike
test.winehq.org broken
Hello, looks like adding the dll name to the output of the tests broke the script that creates the pages on test.winehq.org. Now all test are listed as failed output from winetest-200504301000-paul-mingw.exe crypt: 37 tests executed, 0 marked as todo, 0 failures. output from winetest-200505051000-paul-mingw.exe advapi32/crypt: 37 tests executed, 0 marked as todo, 0 failures. Can someone please fix the script building the summary page. Thanks Stefan
Re: test.winehq.org broken
On 5/6/05, Stefan Leichter [EMAIL PROTECTED] wrote: Hello, looks like adding the dll name to the output of the tests broke the script that creates the pages on test.winehq.org. Now all test are listed as failed output from winetest-200504301000-paul-mingw.exe crypt: 37 tests executed, 0 marked as todo, 0 failures. output from winetest-200505051000-paul-mingw.exe advapi32/crypt: 37 tests executed, 0 marked as todo, 0 failures. Can someone please fix the script building the summary page. It looks like the tests still passed. Where are you seeing failures? -- James Hawkins
Re: test.winehq.org broken
Am Freitag, 6. Mai 2005 21:54 schrieb James Hawkins: On 5/6/05, Stefan Leichter [EMAIL PROTECTED] wrote: Hello, looks like adding the dll name to the output of the tests broke the script that creates the pages on test.winehq.org. Now all test are listed as failed output from winetest-200504301000-paul-mingw.exe crypt: 37 tests executed, 0 marked as todo, 0 failures. output from winetest-200505051000-paul-mingw.exe advapi32/crypt: 37 tests executed, 0 marked as todo, 0 failures. Can someone please fix the script building the summary page. It looks like the tests still passed. Where are you seeing failures? Ok, maybe i was a bit unclear http://test.winehq.org/data/200505051000/ the summary page litst all tests as failed. Bye Stefan
Re: Commercial support
Jakob Eriksson wrote: To go back to the original discussion, I agree that there should be _something_ holding back the free loaders. Not sure exactly what, so I'm monitoring the "Commercial support" thread to see what the consensus ends up as. Sponsoring Wine, is maybe the right way to get some publicity for a wine-supporting-entity and for Wine to get some funds in. This also will not affect the reputation of Wine and is not a recommendation of Wine itself, of any such entity. Advertisements is the other alternative, which exists already on the website (CrossOver?)... Look, if you setup a commercial support list, you have to stand to itI still think it's a problematic objectit's not about money, but reputation and maybe even legal complications And another point: I saw on this list the numbers going around, like $2000 and $1 for being listed. I thought in the beginning, its a joke, but some of you took this seriouslyWell, to make for you some simple calculations: Having 20 % set aside for advertisement efforts of an overall marketing budget of, lets say 10 % of sales, than you need to have this "listing on winehq" lead to $ 500,000 worth of sales I think that's far away from reality, friends! regards, Jakob -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost at www.mediahost.org Skype: startcom Phone: +1.213.341.0390 Import StartCom Public CA smime.p7s Description: S/MIME Cryptographic Signature
Re: Re[5]: Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
On Fri, 2005-05-06 at 09:50 -0600, Vitaliy Margolen wrote: You know, it could be one more place then. Native does RedrawWindow when focus changes. But not always. As soon as I figure out when we need to redraw and when we don't, I'll send you a patch to try. Ok :) I've been playing around with the x11drv code a bit here (trying to add old code from 20041201 into 20050111) but with limited success as quite a bit changed in that area at that time it seems. Shame there's no obvious way of finding out what triggers the problem (i.e. why the drawing window in PSP doesn't work but other types of windows do) as that might allow you to recreate it there... (there was a downloadable trial version of PSP 7 on the web before, but since Corel bought out JASC all the old downloads have gone...) cheers Jules
Re: Readers' choices: 2004 Desktop Linux survey results in!
Le ven 06/05/2005 à 01:10, Tom Wickline a écrit : Hello All, Here is the results: http://www.desktoplinux.com/articles/AT2127420238.html Wine 34 % Crossover 16.3 % VMWare 13.7 % Win4Lin 6.9 % Other (please email us) 1 % None -- I don't run Windows apps under Linux 27.9 % Transgaming should be worried, Cedega doesn't make it out of the Other category. Vincent
Re: Wine Wiki Status
Le ven 06/05/2005 à 08:42, Jani Kärkkäinen a écrit : Dimitrie O. Paun wrote: On Fri, May 06, 2005 at 12:12:01PM +0100, Mike Hearn wrote: I wanted to require that you login to edit anyway, it was so easy to forget that I even forgot a few times. Do people want to go back to the old way, and allow even not logged in people edit? New to the list, and with not much weight on my words, but still... I gather a required log in would be the way to go. Why? Well, imagine your basic net troll stumbling on wine wiki. Hey! I can edit these! Cool. Let's just take all of those out, yeah, and add to the Project Ideas some cool projects like CoLd FUsiON! Yeah! I'm not much worried about take all of those out, it's easy to spot and put back the previous revision. What's more insidious is if some small things are changed (wrong facts, allusions, even typos added), those can take longer to spot and then you have to merge the original page and the correct modifications which took place after the problematic user came in. Vincent
Re: Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
I could send you a piece of it (psp7) or even better, upload it to one of your serversI have also 8.1 if you are interested... Tell me what to do Jules Richardson wrote: On Fri, 2005-05-06 at 09:50 -0600, Vitaliy Margolen wrote: You know, it could be one more place then. Native does RedrawWindow when focus changes. But not always. As soon as I figure out when we need to redraw and when we don't, I'll send you a patch to try. Ok :) I've been playing around with the x11drv code a bit here (trying to add "old" code from 20041201 into 20050111) but with limited success as quite a bit changed in that area at that time it seems. Shame there's no obvious way of finding out what triggers the problem (i.e. why the drawing window in PSP doesn't work but other types of windows do) as that might allow you to recreate it there... (there was a downloadable trial version of PSP 7 on the web before, but since Corel bought out JASC all the old downloads have gone...) cheers Jules -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost at www.mediahost.org Skype: startcom Phone: +1.213.341.0390 Import StartCom Public CA smime.p7s Description: S/MIME Cryptographic Signature
WineConf todo list
I'm trying to gather a list of stuff we said needed to be done at WineConf. Of course the initial list is going to be horribly incomplete but I'm sure others will contribute the missing pieces. * Wine Wiki This seems to be done already. It's available there: http://wiki.winehq.org/ * Add a list of companies providing Wine services and support This discussion/flameware is in full swing. * Putting the videos online Done. Maybe some retouching / cleanup to do if we find someone knowledgeable and willing. * Moving the Wine doc to SourceForge The documentation, i.e. the SGML files in documentation/, uses completely different tools from the rest of Wine. Also Alexandre does not want to deal with its translations. So move the SGML documentation to its own CVS repository, winedoc, which we could host on SourceForge. The English version would go in the en subdirectory so we can easily add translations. * Check in the French translation and corresponding infrastructure. The translation will go in the fr subdirectory of the winedoc CVS repository. At the same time the infrastructure for adding other translations should be put in place. * Make an easy to use cxtest script. The idea is to have a script which could be put in a crontab so it can be run entirely automatically and which would: - checkout / update and recompile CXTest - checkout / update and recompile the latest Wine - run regression tests using Wine's Winelib applications - maybe download some free applications and run tests to make sure they install and start up Jozef Stefanka is planning to work on this. * Get rid of the configuration file Well that's the 0.9 todo list. Maybe it's best to keep it separate from this list. * Find a way to document the registry I had a discussion with Alexandre and lamented that, now that we're going to move things out of the configuration, we won't be able to put comments describing what each setting does. However we already have the problem with all of the Windows settings. Furthermore he noted that it's hard to find where a given setting is used in the Wine code (because the registry path is encoded as a Unicode string?). And the problem is compounded by the lack of proper documentation for registry settings in MSDN. So the idea is to create a way to document each registry setting in the source code so it can be extracted with a tool similar to c2man.pl (or with a hacked c2man.pl). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Re: WineConf todo list
Le ven 06/05/2005 à 21:23, Francois Gouget a écrit : I'm trying to gather a list of stuff we said needed to be done at WineConf. Of course the initial list is going to be horribly incomplete but I'm sure others will contribute the missing pieces. [snip] * Add a list of companies providing Wine services and support This discussion/flameware is in full swing. Spelling fix: flamewar ;) [snip] * Moving the Wine doc to SourceForge The documentation, i.e. the SGML files in documentation/, uses completely different tools from the rest of Wine. Also Alexandre does not want to deal with its translations. So move the SGML documentation to its own CVS repository, winedoc, which we could host on SourceForge. The English version would go in the en subdirectory so we can easily add translations. I guess the compiled docs hosted on winehq would include the translations as well? If they're not part of the source tarball anymore, when will the docs on winehq will be updated? After each commit to winedoc? At the same time of Wine releases? * Check in the French translation and corresponding infrastructure. The translation will go in the fr subdirectory of the winedoc CVS repository. At the same time the infrastructure for adding other translations should be put in place. [snip] * Find a way to document the registry I had a discussion with Alexandre and lamented that, now that we're going to move things out of the configuration, we won't be able to put comments describing what each setting does. However we already have the problem with all of the Windows settings. Furthermore he noted that it's hard to find where a given setting is used in the Wine code (because the registry path is encoded as a Unicode string?). And the problem is compounded by the lack of proper documentation for registry settings in MSDN. So the idea is to create a way to document each registry setting in the source code so it can be extracted with a tool similar to c2man.pl (or with a hacked c2man.pl). How about having a Explanation or Comment key along with the effective key? wine.inf could fill those in on the first run... If users remove the comment, they're in the same boat as with the config. Of course, that's orthogonal to having proper documentation in comments in the code using such a key. Note that a method for correctly grepping Wine's unicode strings would be invaluable, not only for registry entries. Vincent
re: Winelib's role in converting Windows applications
Ira Krakow ([EMAIL PROTECTED]) wrote: At Wineconf, I had a number of conversations about Winelib's role in converting Windows apps. The consensus seems to be that the most efficient conversion path is for much of the Windows app to stay in Visual C++ (or whatever) and that only the modules that specifically require native Linux calls should be recompiled, via MinGW/Dev-C++ on the Windows side, and Winemaker on the Linux side, into Winelib objects. For example, if the application requires PAM authentication, or a Linux-based help system, these modules would be separated out and encapsulated as Winelib objects. I was thinking of using PAM authentication as a good example, since it works for any authentication scheme that the application requires. There are two other reasons to use winelib: 1) if your code uses SEH (structured exception handling), you have a problem. This technique is patented by Borland, see http://www.google.com/search?q=patent+5628016 or maybe by Sun, see http://www.google.com/search?q=patent+6247169 so the official gnu gcc can't support it. You can apply an unoffical patch (see http://reactos.csh-consult.dk/index.php?page=gccseh, or you may be able to use winelib plus some clever macros (see http://www.winehq.org/hypermail/wine-devel/2005/05/0186.html) 2) if you want to reach non-x86 platforms (e.g. MacOSX/PPC, Solaris/Sparc) winelib is the only way to go until projects like Darwine integrate a CPU emulator. - Dan
Incorrect locale used in wine 20050310 (Debian testing)
Hello, I think I have found a bug in the locale system used by wine. I get (incorrectly) English dialog text, with Japanese on the buttons. For example: === Set Optimal Settings? - Your computer has changed since the last time you ran. Re-configure for new hardware? [(Y)] [(N)] === I use English locale, with only Japanese input supported as an option. This is the only program which appears with Japanese text. Everything else is in English. The buttons should not be in Japanese. I am not on this list, so please include my email address in any replies. $ locale LANG=en_GB.UTF-8 LC_CTYPE=ja_JP.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=en_GB.UTF-8 LC_ADDRESS=en_GB.UTF-8 LC_TELEPHONE=en_GB.UTF-8 LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=en_GB.UTF-8 LC_ALL= Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Re: test.winehq.org broken
On Friday 06 May 2005 21:14, Stefan Leichter wrote: http://test.winehq.org/data/200505051000/ the summary page litst all tests as failed. OK, me bad; sorry. The cross-building and WRT shared a bit more common code than I thought, specifically a Local-Patches directory. Tomorrows build will have things back to normal again. Cheers, Paul. pgp3fj6xyeObl.pgp Description: PGP signature
Game sound problem with wine 20050310 (Debian testing)
Hello, I have been trying to get audio working in sync with the game I am playing (Activision Call of Duty) I get this error: err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error) err:wave:DSDB_MapBuffer Use: HardwareAcceleration = Emulation in the [dsound] section of your config If I use the suggestion i get 1sec lag on in-game sounds. Someone #winehq gave me some tips. I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please? [dsound] ;Drivers = wineoss.drv ; default for most common configurations ;Drivers = winearts.drv ; for KDE Drivers = winealsa.drv ; for ALSA users ;; HEL only: Number of waveOut fragments ahead to mix in new buffers. HELmargin = 5 ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;HELqueue = 5 ;; Max number of fragments to prebuffer ;SndQueueMax = 28 ;; Min number of fragments to prebuffer ;SndQueueMin = 12 ;; Forces emulation mode (using wave api) HardwareAcceleration = Emulation ;; Sets default playback device (0 - number of devices - 1) ;DefaultPlayback = 0; use first device (/dev/dsp) ;DefaultPlayback = 1; use second device (/dev/dsp1) ;DefaultPlayback = 2; use third device (/dev/dsp2) ;; Sets default capture device (0 - number of devices - 1) ;DefaultCapture = 0 ; use first device (/dev/dsp) ;DefaultCapture = 1 ; use second device (/dev/dsp1) ;DefaultCapture = 2 ; use third device (/dev/dsp2) Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh Emulation bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise) I wonder if this is a known problem (bug)? Is there a work around? Or a fix please? I am not on this list, so please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Wine - WineHQ - codeweavers
Hi all, I saw at the www.winehq.org/ the banner (http://www.winehq.org/images/bannerads/cw-ad02.gif) that ponts to the www.codeweavers.com/ page. That banner has a little penguin opening a bottle of wine and after, the penguin appears very drunk, does any one knows who did that banner? I wanna the picture of the drunk penguin to set as mine wallpaper, but I wanna a big one. Any one can help me? Sorry if that mesage is not exatly a devel question. Thanks, Derzu Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br
