Re: ScrollDC fixes.
On 07 Mar 2005 19:44:07 +0100, you wrote:
+for( i = 0; i rdata-rdh.nCount; i++, rect += step) {
+DPtoLP(hdc, (LPPOINT)rect, 2);
+TRACE(Bit blitting %s to %ld,%ld\n,
wine_dbgstr_rect(rect),
+rect-left + dx, rect-top + dy);
+BitBlt( hdc, rect-left + dx, rect-top + dy,
+rect-right - rect-left, rect-bottom
-rect-top,
+hdc, rect-left, rect-top, SRCCOPY);
+}
You really shouldn't need to scroll the region rectangle by
rectangle. Selecting the proper clip region and then copying the whole
area should have the same effect.
Hmm, this is about pixels that are copied from the outside of the
visible region to the inside (that area will be invalidated and
repainted if called through ScrollWindowEx, but with noticeable
flickering and there might be direct uses of ScrollDC with worse
effects).
Since the visible region did not work, I did not try adding an extra
clip region. Indeed, adding: SelectClipRgn( hdc, visrgn); does not
help at all.
Can the real bug perhaps be in BitBlt?
{
XEvent event;
-XWindowEvent( gdi_display, physDev-drawable,
~0, event );
-if (event.type == NoExpose) break;
+if( !XCheckWindowEvent( gdi_display,
physDev-drawable, ~0, event ))
+break;
+if (event.type == NoExpose) continue;
You can't use XCheckWindowEvent, you need to wait for the events that
haven't arrived yet.
That is what the XFlush() is for, and it seems to work quite nicely
(after BitBlitting regions of over 50 separate rectangles). Without it,
it is a mess indeed.
Rein.
Re: New uninstaller
Le jeudi 03 mars 2005 21:51 +0900, Mike McCormack a crit : Hi Jonathan, You'll have more success getting this applied if you send each step as a seperate patch. I suggest starting by sending a single patch that converts the uninstaller to use a dialog instead of a window, adds a dialog resource in English and does nothing else. Ok, once everything works I'll try to split it up as much as I can. Once that patch is accepted, move onto the other tasks you have listed above. One step at a time makes the patch easier to review, and reduces the chance that a single line mistake will stop your entire patch from going in. Additionally, there's no need to change the name of main.c to uninstaller.c, that will just make it harder to see what has changed between versions. I thought it would be more homogeneous as taskmanager, winecfg where using program_name.c files and that most of this file was rewritten by the way. But I renamed it back in my latest test patch. Thanks for your comments ! signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: New uninstaller
Jonathan Ernst wrote: Additionally, there's no need to change the name of main.c to uninstaller.c, that will just make it harder to see what has changed between versions. I thought it would be more homogeneous as taskmanager, winecfg where using program_name.c files and that most of this file was rewritten by the way. But I renamed it back in my latest test patch. It would look nicer if it was called uninstaller.c, but renaming files in CVS should be avoided as much as possible. It makes patch management (doing diffs and reverting patches) difficult. Mike
Re: documentation for SERVER_START_REQ
Mike Hearn wrote:
One thing I don't understand is why
we put the request in two do...while(0) loops. Won't they just run
once anyway?
It's a portability thing, basically just declaring a new scope, you can
ignore it - do {} while (0) runs the body of the block once.
It's to make sure that code written with SERVER_START_REQ ends with
SERVER_END_REQ, and that the block ends with a semi-colon.
Mike
Re: ScrollDC fixes.
Rein Klazes [EMAIL PROTECTED] writes: Hmm, this is about pixels that are copied from the outside of the visible region to the inside (that area will be invalidated and repainted if called through ScrollWindowEx, but with noticeable flickering and there might be direct uses of ScrollDC with worse effects). Since the visible region did not work, I did not try adding an extra clip region. Indeed, adding: SelectClipRgn( hdc, visrgn); does not help at all. Can the real bug perhaps be in BitBlt? I doubt that, I don't see how copying the single rectangle of the bounding box of the region would be different from copying every individual rectangle. That is what the XFlush() is for, and it seems to work quite nicely (after BitBlitting regions of over 50 separate rectangles). Without it, it is a mess indeed. The XFlush is just hiding the bug, try it on a low latency link and you'll see. You'd need an XSync but that would just cause an extra round trip for no good reason. -- Alexandre Julliard [EMAIL PROTECTED]
Re: ScrollDC fixes.
On Tue, 08 Mar 2005 09:53:07 +0100, I wrote: Hmm, this is about pixels that are copied from the outside of the visible region to the inside (that area will be invalidated and repainted if called through ScrollWindowEx, but with noticeable flickering and there might be direct uses of ScrollDC with worse effects). Since the visible region did not work, I did not try adding an extra clip region. Indeed, adding: SelectClipRgn( hdc, visrgn); does not help at all. Can the real bug perhaps be in BitBlt? Don't mind, I see what you mean. I have to subtract the destination region of those pixels and then clip. Rein.
Re: New uninstaller
Jonathan Ernst [EMAIL PROTECTED] wrote:
I tried to fix every char-WCHAR I though was worth it; please have a
second look at it.
The problem now with unicode is that when I try to strstr my token with
the element of the list (entries[i].descr) it works only with the first
letter (before to use unicode it was working very well).
You can see the same problem (one letter .descr) when using the
unintaller with --list.
The second problem is that since I use unicode for the argvs, whatever
argv I give I get the --list branch.
Your main mistake is that you are trying to handle ASCII strings with old
APIs, you can't do that. Unicode requires a completely different set of APIs,
and win32 provides one.
+/*
+TELL ME: IS IT STILL NEEDED WITH UNICODE ???
len = WideCharToMultiByte(CP_UNIXCP, 0, entries[i].descr, -1, NULL,
0, NULL, NULL);
As I have said it already, you need to convert unicode strings to the encoding
of the underlying system before printing strings on console. CP_UNIXCP is
supposed
to do exactly that task.
+descr = HeapAlloc(GetProcessHeap(), 0, len);
+WideCharToMultiByte(CP_UNIXCP, 0, entries[i].descr, -1, descr, len,
NULL, NULL); */
+printf(%s|||%s\n, entries[i].key, entries[i].descr);
+/*HeapFree(GetProcessHeap(), 0, descr);*/
You have to HeapFree a HeapAlloc'ed memory block.
It's better to use W versions of APIs even if it's not strictly required.
+if (RegOpenKeyExA(HKEY_LOCAL_MACHINE, REGSTR_PATH_UNINSTALL, 0,
KEY_READ, hkeyUninst) != ERROR_SUCCESS)
RegOpenKeyExW in this case.
{
- MessageBox(0, Uninstall registry key not available (yet), nothing to do
!, appname, MB_OK);
- return 0;
+MessageBox(0, sRegistryKeyNotAvailable, sAppName, MB_OK);
MessageBoxW in this case.
if (!entries)
- entries = HeapAlloc(GetProcessHeap(), 0, sizeof(uninst_entry));
+entries = HeapAlloc(GetProcessHeap(), 0, sizeof(uninst_entry));
Quite strange formatting.
strcpy(key_app, REGSTR_PATH_UNINSTALL);
strcat(key_app, \\);
p = key_app+strlen(REGSTR_PATH_UNINSTALL)+1;
You shouldn't use string APIs supposed to handle ASCII strings. Use
lstrcpyW,lstrcatW
and lstrlenW in this and all other cases.
sizeOfSubKeyName = 255;
-for ( i=0;
- RegEnumKeyExA( hkeyUninst, i, subKeyName, sizeOfSubKeyName,
- NULL, NULL, NULL, NULL ) != ERROR_NO_MORE_ITEMS;
- ++i )
+for (i=0; RegEnumKeyExA( hkeyUninst, i, subKeyName, sizeOfSubKeyName,
NULL, NULL, NULL, NULL ) != ERROR_NO_MORE_ITEMS; ++i)
RegEnumKeyExW in this case.
+static const WCHAR DisplayNameW[] =
{'D','i','s','p','l','a','y','N','a','m','e',0};
+strcpy(p, subKeyName);
lstrcpyW
+RegOpenKeyExA(HKEY_LOCAL_MACHINE, key_app, 0, KEY_READ, hkeyApp);
RegOpenKeyExW
+res = CreateProcess(NULL, entries[i].command, NULL, NULL, FALSE, 0,
NULL, NULL, si, info);
CreateProcessW
+prevsel = SendMessage(hList, LB_GETCURSEL, 0, 0);
SendMessageW
and many,many,many others. Make sure to pass correct arguments to all the
changed APIs.
For better understanding of what is going on add the following as the very first
line in main.c:
#define __WINESRC__
--
Dmitry.
XML escaping problem in WWN 264
In WWN 264 there's the following: lt;rantgt; ... lt;/rantgt; But it does not get through in the HTML page because it's getting transformed into rant.../rant which the browser is correctly ignoring. We've had this problem before but I don't remember what the fix is... Do you? -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: [HELP] Quartz and FFMpeg question
On Sun, 6 Mar 2005, Christian Costa wrote: Hi, I'm working on a video wrapper around libavcodec from FFMpeg. Currently I can play rle, msvideo1 and mjpeg movies. But before submitting anything I must handle the dependency with libavcodec (and maybe libavformat in the future). AFAIK there is no stable API How do other projects that use libavcodec and ffmpeg deal with the binary compatibility issue? At least here (Debian) mplayer depends on the libavcodec package instead of copying the source (but it's a bit of a special case as they come from a third-party package repository). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Utilisateur (nom commun) : Mot utilis\xE9 par les informaticiens en lieu et place d'idiot.
Re: XML escaping problem in WWN 264
Francois Gouget wrote: In WWN 264 there's the following: lt;rantgt; ... lt;/rantgt; But it does not get through in the HTML page because it's getting transformed into rant.../rant which the browser is correctly ignoring. We've had this problem before but I don't remember what the fix is... Do you? You probably need to turn the into amp;, so you would get: amp;lt;rantamp;gt; Then again, it is probably right to do it in the XML -HTML converter, and not in the XML itself. I.e. - the XML-HTML converter needs to transform an inline into lt; again. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Let's fix Steam!
Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark. What's interesting, however, is that Steam works perfectly in Crossover 4.1 - since I don't think Steam is supported, this is not due to a special hack, and the failure in Steam therefore represents a serious regression in Wine. This, quite simply, will be a really cool app to get working again. Plus, we'll need it to try out Half Life 2 once you awesome Direct3D boys finish up your work :) So, where do we go about this? The installer demonstrating the error can be downloaded easily from http://www.steampowered.com/ - however, I'm not sure if it's plausible to run a regression analysis since there are no patches available against the direct crossover version of Wine. At this point, I'm not even sure which file has broken, although I do know that it's one we've had problems with in the past based off of IRC conversations. If anyone could follow up with more info, particularly about the specifics of the error, I'm sure we'd all appreciate it greatly. Thanks, Scott Ritchie
Wine in the press
Title: Ham and Wine go well together Link: http://software.newsforge.com/software/05/03/02/1449240.shtml?tid=130 By: Joe Barr snip Everything I read said this is what you want. But of course it isn't, because I don't run Windows. It was just about this time that the news about Microsoft blocking users running Wine from downloading updates and tools from their site began to spread. All the sudden I wondered -- if Wine is good enough to have Microsoft blocking it, could it run CwGet? /snip All I have to say is Thank You Microsoft for the press :-) Tom
Re: Wine in the press
Tom Wickline wrote: Title: Ham and Wine go well together Link: http://software.newsforge.com/software/05/03/02/1449240.shtml?tid=130 By: Joe Barr snip Everything I read said this is what you want. But of course it isn't, because I don't run Windows. It was just about this time that the news about Microsoft blocking users running Wine from downloading updates and tools from their site began to spread. All the sudden I wondered -- if Wine is good enough to have Microsoft blocking it, could it run CwGet? /snip All I have to say is Thank You Microsoft for the press :-) Tom Thanks for the heads-up, Tom; I posted a comment requesting that he add the app to the appdb, and consider becoming a maintainer. :-D Second time in two days I've posted somewhere about look at Wine *now*! issues: just yesterday, someone suggested I report my success with running the Neverwinter Nights Toolset under Wine to *Transgaming*(), which I had to correct (lol). There seems to be a fair amount of misinformation or outdated information/opinions about Wine in the general user mindset. The nice thing is, though if you read the comments on NF and in the thread on the Players Resource Consortium page where I mentioned running the NWN Toolset under Wine ( http://forums.netgamers.co.uk/showthread.php?t=4542 , if you're interested; issue was completely unrelated to Wine, in fact I couldn't have solved it without Wine), there are not a whole bunch of Wine? We don't need no stinkin' Wine!! posts like I used to see in the past whenever Wine was mentioned. Heck, it's nice even to see a short article saying I got an app to work under Wine on NF, like that's not only news, but OK to say. It hasn't always been. It's starting to look like Wine isn't a dirty word anymore. Which is stupendous to see happening just about the time Wine is getting pretty doggone good :-D . I suspect we're going to be seeing a lot more of these,Hey!! WINE actually works!! articles in the near future. I'm looking forward to it. Holly
Re: New uninstaller
Jonathan Ernst [EMAIL PROTECTED] wrote: I fixed/changed many things regarding unicode. It seems that now both outputing to the console and case insensitive find as you type feature (re-)work. I fixed most warnings, but there are still 4 lines that I couldn't fix (173, cast entries[numentries-1].command to LPBYTE as you do 3 lines earlier. 206, wrong STARTUPINFO declaration, you need a unicode one with W suffix. 215, you can't use sprintf to print to a WCHAR string, use win32 API wsprintfW instead. 429). Can someone help me ? slen = strlenW(String), plen = strlenW(Pattern); better use official API lstrlenW. /* find start of pattern in string */ while (toupper(*start) != toupper(*Pattern)) You can't use toupper with unicode strings. I can't suggest a win32 equivalent from the top of my head, you need to find out. pptr = (WCHAR *)Pattern; There is no need for a cast here. while (toupper(*sptr) == toupper(*pptr)) same as above. Last but not least, since these changes the uninstaller crashes (very) often. I have an unhandled exception when retrieving some apps from the uninstall key and I don't know what cause this: err:seh:EXC_DefaultHandling Unhandled exception code c005 flags 0 addr 0x77ecf5d4 Very likely a common error happening often in the process of unicodification: buffer overflow due to not a correct memory allocation, or a not correct initialization of a variable pointing to a buffer length (size of buffer in bytes vs. WCHARs). For better understanding of what is going on add the following as the very first line in main.c: #define __WINESRC__ When adding this line the compilation fails with this message: main.c:194: error: `STARTUPINFO' undeclared (first use in this function) Are some include(s) missing ? That's the point. I'd prefer that you could figure out that on your own. Hint: look at the headers, and you will see that all those STARTUPINFO, lstrcpy, RegOpenKey are not the real API names, but just macros depending whether UNICODE is defined or not. In Wine using API macros is deprecated, personally I'd prefer to not use them in programs/* either. Do you think I'm near the target ? Definitely very close. -- Dmitry.
Re: Wine in the press
Le mardi 08 mars 2005 08:42 -0500, Tom Wickline a crit : Title: Ham and Wine go well together Link: http://software.newsforge.com/software/05/03/02/1449240.shtml?tid=130 By: Joe Barr snip Everything I read said this is what you want. But of course it isn't, because I don't run Windows. It was just about this time that the news about Microsoft blocking users running Wine from downloading updates and tools from their site began to spread. All the sudden I wondered -- if Wine is good enough to have Microsoft blocking it, could it run CwGet? /snip All I have to say is Thank You Microsoft for the press :-) Tom Cool, I just added an entry for CwGet in the application database ;-) http://appdb.winehq.org/appview.php?appId=2087
Re: XML escaping problem in WWN 264
On Tue, 8 Mar 2005 10:38:22 +, Paul Millar [EMAIL PROTECTED] wrote: Would it not be just amp;lt;rantamp;gt; ? XML - HTML renders this to lt;rantgt;, which the browser will render as rant. No.. that didn't work. Good tip though. Newman - any ideas? Maybe lt;nbsp;rantnbsp;gt;? I think that would be acceptable if it worked. While we're on the the HTML topic, anyone want to take a quick stab at updating the stylesheet to properly render DLDTDD tags within quotes? Looks like we just need some indenting. Example: http://www.winehq.com/?issue=264#Wine%20Status -Brian
Re: Let's fix Steam!
Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark. It would be great if steam worked with wine. I did some testing some time ago, and Steam seemed to work except of this problem. I used cvscedega to work around the 27% Problem and after that I ran it with wine. It worked quite fine, registration, game registration, game setup and game start. I had MSIE installed and had to use a few native dlls(cryptography dlls and IE friends) but it seemed to work fine with wine. The next problem was not wine releated and is somewhat harder to fix. Steam turned out to be really download hungry. I just installed it and updated Half life and Steam had pushed 100 MB through my internet line. I've a download limit of 600 MB wich is really a small limit. One day I trashed my wine installation and didn't re-install steam afterwards. If I find some way to download these things at school I can help you with fixing steam! Stefan Dösinger
Re: Suggestion For Wine Loader
On poniedziaek 07 marzec 2005 06:04 am, Jason Couture wrote: er.. I Just meant to convert PE - ELF so that the programs could be run without wine. Just some *.dll.so files as depends... But that's what wine is all about. They would still use wine. A mere PE-ELF conversion doesn't make the program suddenly run without wine. The binary loader has the least impact AFAICT. Cheers, Kuba
Re: Let's fix Steam!
Am Dienstag, 8. März 2005 12:41 schrieb Scott Ritchie: Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark. Just an update to my mail sent 2 minutes ago: I downloaded steam, ran it with wine(cvs from 3/6/2005) and it WORKED without doing anything special. I should have tried before sending this mail. Wine just told me that it has to download the mozilla active X control and crashed because of a missing dll(MSVCR70.dll). I'll get this dll and do some more testing. Stefan
Re: [DPLAYX] fix bug 872
Raphael [EMAIL PROTECTED] writes: Hi, cf http://bugs.winehq.org/show_bug.cgi?id=872 Seems he have created events (hTemps) leaks no ? I'm not sure why that code uses global handles at all, since they get duplicated in the target process anyway; it seems to me you could simply get rid of the ConvertToGlobalHandle calls. If that doesn't work the code needs to be fixed, global handles are a Win9x abomination that should never be used. -- Alexandre Julliard [EMAIL PROTECTED]
Re:avicap32 patch
Hi That patch won't work. You forgot to include the changes in the headers in vfw.h I've sent you, e.g. #define WM_CAP_STARTWM_USER #define WM_CAP_UNICODE_START(WM_USER +100) #define WM_CAP_DRIVER_CONNECT (WM_CAP_START+ 10) #define WM_CAP_DRIVER_DISCONNECT(WM_CAP_START+ 11) etcera and the macros #define capDriverConnect(hwnd, index) SendMessage((hwnd), WM_CAP_DRIVER_CONNECT, (index, 0)) etcetera etcetera furthermore all the v4l stuff has to go into a seperate driver file i think, as wine is also supposed to run on non-Linux distributions. this line in avicap_main : window = CreateWindowExW etc. and the registering of the window contains a lot of crap; i just copied it from a site somewhere on the internet. It was just to get a handle to the window Somehow the dwstyle has to get passed on, and few other things. Futhermore: no need to link to -lpng -ljpeg and -lnetpbm; they're not needed anymore in the code i've sent you. Better think, get more info and be more carefull before you send in a patch i think. Anyway, i smashed together some code with which i can grab an image from my cam, and save it as a DIB (capFileSaveDIB). also i wrote something for cappreview, which looks as if it would be easy to get it running. if someone's interested i could send you the code. Now my question is: maybe one of the developers could just help/hint/write the Capcreatecapturewindow part (that seems to me a very little job), then anyone who wants could try to write a macro; just a thought of me, any thoughts from someone else? Regards Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: XML escaping problem in WWN 264
Would it not be just amp;lt;rantamp;gt; ? XML - HTML renders this to lt;rantgt;, which the browser will render as rant. HTH, Paul. On Tuesday 08 Mar 2005 10:26, Francois Gouget wrote: In WWN 264 there's the following: lt;rantgt; ... lt;/rantgt; But it does not get through in the HTML page because it's getting transformed into rant.../rant which the browser is correctly ignoring. We've had this problem before but I don't remember what the fix is... Do you? pgp7w9GdTKgxu.pgp Description: PGP signature
Re: Voodoo3, Banshee and D3D
Troy Rollo wrote: Given the age of the hardware I didn't plan to get into finding the correct fix, since the hack works for the time being to allow me to debug other problems and I haven't heard of anybody else complaining about D3D on Voodoo3 and Banshee cards. Oh, I would have complained, but I just upgraded to a geforce instead. :) --Adam
Re: New uninstaller
Le mardi 08 mars 2005 23:29 +0800, Dmitry Timoshkov a crit :
Jonathan Ernst [EMAIL PROTECTED] wrote:
[...]
Thanks, fixed.
You can't use toupper with unicode strings. I can't suggest a win32 equivalent
from the top of my head, you need to find out.
It seems that CharUpperW works well.
[...]
Last but not least, since these changes the uninstaller crashes (very)
often. I have an unhandled exception when retrieving some apps from the
uninstall key and I don't know what cause this:
err:seh:EXC_DefaultHandling Unhandled exception code c005 flags 0
addr 0x77ecf5d4
Very likely a common error happening often in the process of unicodification:
buffer overflow due to not a correct memory allocation, or a not correct
initialization of a variable pointing to a buffer length (size of buffer in
bytes vs. WCHARs).
Thanks for the hint. I found the allocation problem.
[...]
Fixed
Now everything works; thanks for your step by step help; I hope that
what I'me learning now will let me make more additions to Wine !
But:
It is even possible to uninstall more than one app at a time, but I wish
that when an uninstaller has finished to uninstall an application the
list is updated, but it's not. What's and where's a clean way to do it ?
Please find attached main.c's diff.
Jonathan
P.S. Do I really have to split this new uninstaller in different patches
as nearly everything changed ?
Index: main.c
===
RCS file: /home/wine/wine/programs/uninstaller/main.c,v
retrieving revision 1.19
diff -u -r1.19 main.c
--- main.c 9 Dec 2004 14:07:59 - 1.19
+++ main.c 8 Mar 2005 16:40:50 -
@@ -1,8 +1,9 @@
/*
- * QD Uninstaller (main.c)
+ * Uninstaller
*
* Copyright 2000 Andreas Mohr [EMAIL PROTECTED]
* Copyright 2004 Hannu Valtonen [EMAIL PROTECTED]
+ * Copyright 2005 Jonathan Ernst [EMAIL PROTECTED]
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -18,104 +19,94 @@
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
- * ToDo:
- * - add search box for locating entries quickly
*/
-
#include stdlib.h
#include stdio.h
#include string.h
-#include time.h
-#include windows.h
-#include main.h
+#include windows.h
+#include resource.h
#include regstr.h
+#include wine/unicode.h
#include wine/debug.h
-WINE_DEFAULT_DEBUG_CHANNEL(uninstaller);
-
-/* Work around a Wine bug which defines handles as UINT rather than LPVOID */
-#ifdef WINE_STRICT
-#define NULL_HANDLE NULL
-#else
-#define NULL_HANDLE 0
-#endif
-
-/* use multi-select listbox */
-#undef USE_MULTIPLESEL
-
-/* Delete uninstall registry key after execution.
- * This is probably a bad idea, because it's the
- * uninstall program that is supposed to do that.
- */
-#undef DEL_REG_KEY
-
-char appname[18];
-static char about_string[] =
-Wine Application Uninstaller (C) 2004 by Andreas Mohr [EMAIL PROTECTED] and Hannu Valtonen [EMAIL PROTECTED];
-static char program_description[] =
- Please select the application you wish to uninstall:;
+WINE_DEFAULT_DEBUG_CHANNEL(uninstaller);
typedef struct {
-char *key;
+WCHAR *key;
WCHAR *descr;
-char *command;
+WCHAR *command;
int active;
} uninst_entry;
+static uninst_entry *entries = NULL;
+static unsigned int numentries = 0;
+static int list_need_update = 1;
+static int oldsel = -1;
+static WCHAR *sFilter;
+static WCHAR sAppName[MAX_STRING_LEN];
+static WCHAR sAboutTitle[MAX_STRING_LEN];
+static WCHAR sAbout[MAX_STRING_LEN];
+static WCHAR sRegistryKeyNotAvailable[MAX_STRING_LEN];
+static WCHAR sUninstallFailed[MAX_STRING_LEN];
+
+static int FetchUninstallInformation(void);
+static void UninstallProgram(void);
+static void UpdateList(HWND hList);
+static int cmp_by_name(const void *a, const void *b);
+static WCHAR *stristr(const WCHAR *String, const WCHAR *Pattern);
+
+
+static const WCHAR BackSlashW[] = { '\\', 0 };
+static const WCHAR DisplayNameW[] = {'D','i','s','p','l','a','y','N','a','m','e',0};
+static const WCHAR PathUninistallW[] = {
+'S','o','f','t','w','a','r','e','\\',
+'M','i','c','r','o','s','o','f','t','\\',
+'W','i','n','d','o','w','s','\\',
+'C','u','r','r','e','n','t','V','e','r','s','i','o','n','\\',
+'U','n','i','n','s','t','a','l','l',0 };
+static const WCHAR UninstallCommandlineW[] = {'U','n','i','n','s','t','a','l','l','S','t','r','i','n','g',0};
-uninst_entry *entries = NULL;
-
-unsigned int numentries = 0;
-int list_need_update = 1;
-int oldsel = -1;
-
-struct {
-DWORD style;
-LPCSTR text;
-HWND hwnd;
-} button[] =
-{
-{ BS_PUSHBUTTON, Add/Remove, 0 },
-{ BS_PUSHBUTTON, About, 0 },
-{ BS_PUSHBUTTON, Exit, 0 }
-};
-
-#define NUM (sizeof(button)/sizeof(button[0]))
-
-int FetchUninstallInformation(void);
-void
Re: [PATCH] Add search functionality to WINE regedit
Jan Schiefer wrote:
It's already fully cleaned up and ready to go! I know other people hate
my coding style... :)
Awww, it's not hate, you just need to be careful about how the code is
laid out and what features you use. You'll need to fix this patch in a
few places so here are some comments:
It's usually a good idea to submit the backend *first* and then the
frontend, or better .. have them done all at once. Patches are supposed
to be standalone, not stuff that'll only start working later (in the
general case). For now I'd combine the two patches.
+GROUPBOXLook at,IDC_FIND_GROUPBOX, 5, 25, 194, 46, BS_GROUPBOX
+CHECKBOX Keys, IDC_CHECKBOX_KEYS, 10, 36, 60, 10
Try and keep alignment consistent, otherwise there's just extra visual
noise for no good reason!
+LRESULT CALLBACK findedit_proc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM
lParam) {
+if(uMsg != 193) { // if uMsg == 193, tmpLen is always 0!
+int tmpLen = SendMessage(hWnd, EM_LINELENGTH, 0, 0);
+if(tmpLen != searchStringLen) {
+if(tmpLen 0)EnableWindow(hFindButton, TRUE);
+else EnableWindow(hFindButton, FALSE);
+searchStringLen = tmpLen;
+}
+}
+return CallWindowProc ((WNDPROC) prevWndProcEdit, hWnd, uMsg, wParam, lParam);
+}
I'm afraid that unless my mail client is playing up that type of code
isn't acceptable. You need to use indenting! Also please try and space
stuff out, eg rather than: if(tmpLen 0)EnableWindow use if (tmpLen
0) EnableWindow();
+
+INT_PTR CALLBACK searchingdlg_proc(HWND hWnd, UINT uMsg, WPARAM wParam,LPARAM
lParam) {
+switch(uMsg) {
+case WM_INITDIALOG:
+ //SearchRegistryRecrusively(,HKEY_CLASSES_ROOT,TRUE);
No C++/C99 style comments unfortunately. Also please don't submit
patches that have code commented out for no obvious reason.
+break;
+ case WM_COMMAND:
+ switch(LOWORD(wParam)) {
+ case IDCANCEL:
+ HeapFree(GetProcessHeap(),0,searchString);
+EndDialog(hWnd, 0);
+return(TRUE);
+ break;
+ }
Indenting is good, but indenting consistently is even better!
+break;
+}
+
+return(FALSE);
+}
+
+INT_PTR CALLBACK finddlg_proc(HWND hWnd, UINT uMsg, WPARAM wParam,LPARAM lParam) {
+
+switch(uMsg) {
+case WM_INITDIALOG:
+hFindEdit = GetDlgItem(hWnd, IDC_FINDEDIT);
+ hFindButton = GetDlgItem(hWnd, IDOK);
+ prevWndProcEdit = SetWindowLongPtr (hFindEdit, GWLP_WNDPROC, (LONG_PTR) findedit_proc);
+ EnableWindow(hFindButton, FALSE);
+ CheckDlgButton( hWnd, IDC_CHECKBOX_KEYS, BST_CHECKED );
+CheckDlgButton( hWnd, IDC_CHECKBOX_VALUES, BST_CHECKED );
+ CheckDlgButton( hWnd, IDC_CHECKBOX_DATA, BST_CHECKED );
+return(TRUE);
I think you may be mixing tabs and spaces or something here. Also making
return look like a function is rather non-standard for C, use it as a
statement: return TRUE;
+ break;
+case WM_COMMAND:
+switch(LOWORD(wParam)) {
+ case IDOK:
+ searchString =
(LPTSTR)HeapAlloc(GetProcessHeap(),0,searchStringLen + 1);
+ GetWindowText(hFindEdit, searchString, searchStringLen + 1 );
+
+ searchForKeys = (IsDlgButtonChecked( hWnd, IDC_CHECKBOX_KEYS )
== BST_CHECKED);
+ searchForValues = (IsDlgButtonChecked( hWnd,
IDC_CHECKBOX_VALUES ) == BST_CHECKED);
+ searchForData = (IsDlgButtonChecked( hWnd, IDC_CHECKBOX_DATA )
== BST_CHECKED);
+ searchMatchWholeString = (IsDlgButtonChecked( hWnd,
IDC_CHECKBOX_MATCHSTRING ) == BST_CHECKED);
If you're going to fall through please put a comment like /* fall
through */ otherwise it looks an awful lot like a mistake.
thanks -mike
Re: [HELP] Quartz and FFMpeg question
Message du 08/03/05 12:05 De : Francois Gouget [EMAIL PROTECTED] A : Christian Costa [EMAIL PROTECTED] Copie agrave; : wined wine-devel@winehq.org Objet : Re: [HELP] Quartz and FFMpeg question On Sun, 6 Mar 2005, Christian Costa wrote: Hi, I'm working on a video wrapper around libavcodec from FFMpeg. Currently I can play rle, msvideo1 and mjpeg movies. But before submitting anything I must handle the dependency with libavcodec (and maybe libavformat in the future). AFAIK there is no stable API How do other projects that use libavcodec and ffmpeg deal with the binary compatibility issue? Mplayer and Gstreamer include ffmpeg sources. They are not in their CVS repository but a snapshot is added during the release process. Transcode only check for ffmpeg headers and static libraries. There are several other apps. I will take a look a them. At least here (Debian) mplayer depends on the libavcodec package instead of copying the source (but it's a bit of a special case as they come from a third-party package repository). This is surprising because libavcodec and libavformat are static libraries so once the binary is generated there is no more dependency. Christian
Re: Wine in the press
--On Tuesday, March 08, 2005 3:38 PM +0100 Holly Bostick [EMAIL PROTECTED] wrote: if you're interested; issue was completely unrelated to Wine, in fact I couldn't have solved it without Wine This aspect should be pushed more to Windows developers. Real Windows is a black box API, and WINE gives great visibility into what's really happening under the covers. Debugging under WINE can reveal info and insight not available under real Windows.
Re: [PATCH] Add search functionality to WINE regedit
--- Mike Hearn [EMAIL PROTECTED] wrote:
Jan Schiefer wrote:
It's already fully cleaned up and ready to go! I
know other people hate
my coding style... :)
Awww, it's not hate, you just need to be careful
about how the code is
laid out and what features you use. You'll need to
fix this patch in a
few places so here are some comments:
Also..
if(uMsg != 193) { // if uMsg == 193, tmpLen is
always 0!
no C++ style comments. try to use /* comment */
I use this a file containing
^[[:space:]]+#
//
/\*[^[:space:]]\w
\w[^[:space:]]\*/
if\(
)[[:alpha:]]
with
find -mtime -10 -iregex .*\.[c | h] -exec egrep
--file=filewithchecks {} -n \; -print
add -wError and -Werror-implicit-function-declaration
and -Wdeclaration-after-statement for gcc = 3.4 to
cflags in your Makefile.
I'll post a patch so that the whole of wine can be
built with -wError on gcc =3.3 soon,
for the brave use:
(long long) for shift errors 32 is greater than
programs/winehlp uses %x so the Makefile needs
-Wno-format-y2k in it's CFLAGS
and add
register int src char * in libs/port/memmove.c
Send instant messages to your online friends http://uk.messenger.yahoo.com
unixfs
Hello, Could you please tell me if you consider the unixfs shell namespace extension, which I've sent to wine-patches last week, a sensible way to go in order to access the unix filesystem from winecfg? I know that there is room for improvements, and I'm working on it. But if you think it is not the right thing to do, I will stop working on it and save some time for other stuff. Bye, -- Michael Jung [EMAIL PROTECTED]
Re: unixfs
Michael Jung [EMAIL PROTECTED] writes: Could you please tell me if you consider the unixfs shell namespace extension, which I've sent to wine-patches last week, a sensible way to go in order to access the unix filesystem from winecfg? I know that there is room for improvements, and I'm working on it. But if you think it is not the right thing to do, I will stop working on it and save some time for other stuff. I think the extension itself is perfectly reasonable. The thing I'm not sure about is creating a brand new dll for it, adding Wine-specific dlls should be avoided if possible. -- Alexandre Julliard [EMAIL PROTECTED]
Re: unixfs
On Tuesday 08 March 2005 20:12, Alexandre Julliard wrote:
I think the extension itself is perfectly reasonable. The thing I'm
not sure about is creating a brand new dll for it, adding
Wine-specific dlls should be avoided if possible.
This is from dlls/shell32/shellole.c:
/* this table contains all CLSID's of shell32 objects */
struct {
REFIID riid;
LPFNCREATEINSTANCE lpfnCI;
} InterfaceTable[] = {
{CLSID_ShellFSFolder, IFSFolder_Constructor},
{CLSID_MyComputer, ISF_MyComputer_Constructor},
{CLSID_ShellDesktop, ISF_Desktop_Constructor},
{CLSID_ShellLink, IShellLink_Constructor},
{CLSID_DragDropHelper, IDropTargetHelper_Constructor},
{CLSID_ControlPanel, IControlPanel_Constructor},
{CLSID_AutoComplete, IAutoComplete_Constructor},
{NULL,NULL}
};
Would you consider it more reasonable to implement unixfs as a part of
shell32? We would not have to alter the APIs exported by shell32 to do this.
Wine's shell32 would just recognize more CLSID's than the original one.
Bye,
--
Michael Jung
[EMAIL PROTECTED]
Re: Let's fix Steam!
Am Dienstag, 8. März 2005 12:41 schrieb Scott Ritchie: Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark. What's interesting, however, is that Steam works perfectly in Crossover 4.1 - since I don't think Steam is supported, this is not due to a special hack, and the failure in Steam therefore represents a serious regression in Wine. This, quite simply, will be a really cool app to get working again. Plus, we'll need it to try out Half Life 2 once you awesome Direct3D boys finish up your work :) So, where do we go about this? The installer demonstrating the error can be downloaded easily from http://www.steampowered.com/ - however, I'm not sure if it's plausible to run a regression analysis since there are no patches available against the direct crossover version of Wine. At this point, I'm not even sure which file has broken, although I do know that it's one we've had problems with in the past based off of IRC conversations. If anyone could follow up with more info, particularly about the specifics of the error, I'm sure we'd all appreciate it greatly. Well, another update on Steam: Steam runns indeed nice with wine. I don't know why it works all over the sudden, but it works ;-) These are the problems I found: *Microsoft Internet explorer needed: I didn't get the builtin shdocvw working. The automatical download of the Mozilla active X control didn't work. I downloaded it manually and installed it but it still didn't work Can someone give me a hint how I make the builtin shdocvw work? *No keyboard without Desktop mode. It seems like wine doesn't pass the Steam Windows to the Window Manager(KDE / KWM in my case). To make the keyboard working I have to use the Desktop mode. Managed = N doesn't work. *I can't move the Window in Managed mode. With Desktop and Managed = N it works. *Steam sometimes causes crashes if I cancel it with Strg+C. I didn't try to play any game because of the download limit problem mentioned in my previous mail. I'll report tomorrow on this. Cheers, Stefan
Re: More implementation of IRecordInfo
You have forgotten the patch :) On Tue, 2005-03-08 at 20:18 +0100, Jacek Caban wrote: This patch makes IRecordInfo almost complete. If anyone knows any application using it I could test on, please let me know. Changelog: More implementation of IRecordInfo
Re: WIDL - Sync to ReactOS 20050308
Steven Edwards wrote: No one really got back to me on how handles should be done in the dcom.idl so I am going assume this is correct. If this has gotten too big let me know and I can break it up in to smaller patches over the next week. Sorry Steven, I meant to investigate this before but I forgot. Index: dlls/ole32/dcom.idl === RCS file: /home/wine/wine/dlls/ole32/dcom.idl,v retrieving revision 1.1 diff -u -b -r1.1 dcom.idl --- dlls/ole32/dcom.idl 22 May 2003 03:36:26 - 1.1 +++ dlls/ole32/dcom.idl 8 Mar 2005 18:28:18 - @@ -217,6 +217,7 @@ cpp_quote(#if 0) [ + explicit_handle, uuid(99fcfec4-5260-101b-bbcb-00aa0021347a), pointer_default(unique) ] explicit_handle is an ACF attribute and not something that should normally be put in an IDL file. Furthermore, it is not necessary, as stated by MSDN: If the *[explicit_handle]* attribute is not used, the application can still specify that an operation have an explicit handle (binding or serialization) directing the call. I think there is an MIDL command-line option to allow ACF attributes in IDL files though. Rob
Sorce for Wine MIDI Mapper ?
Where would I find the source code for this module ? I want to look at it to see if I can discover why it fails to open when using Noteworthy Composer. -- Andrew [hackcoughsniffle] Internal Virus Database corrupt
Re: unixfs
Alexandre Julliard wrote: I think the extension itself is perfectly reasonable. The thing I'm not sure about is creating a brand new dll for it, adding Wine-specific dlls should be avoided if possible. I agree about dlls that cause un-standard linkage from using code to private dll. But this is a Control. the only linkage is through the registry, and is totally optional to any running/using code. It's like the Mozilla control or any other utility add in. Just from Winehq this time. Free Life Boaz
Gmail accounts
Sorry i know this seems like spam but it is an offer. Anyone who emails [EMAIL PROTECTED] will recieve a gmail invite until i run out of invites. later
Re: XML escaping problem in WWN 264
On Tue, 2005-03-08 at 08:43 -0700, Brian Vincent wrote: On Tue, 8 Mar 2005 10:38:22 +, Paul Millar [EMAIL PROTECTED] wrote: Would it not be just amp;lt;rantamp;gt; ? XML - HTML renders this to lt;rantgt;, which the browser will render as rant. No.. that didn't work. Good tip though. Newman - any ideas? Maybe lt;nbsp;rantnbsp;gt;? I think that would be acceptable if it worked. amp;lt;rantamp;gt; is the correct way to get through the parser. I have added some code to the parser that will pass through unknown html tags as plain text. In other words rant should get converted to lt;rantgt; automatically. The downside is that in this case the tags need to be properly nested in other tags. Otherwise, use the longer form. While we're on the the HTML topic, anyone want to take a quick stab at updating the stylesheet to properly render DLDTDD tags within quotes? Looks like we just need some indenting. Example: http://www.winehq.com/?issue=264#Wine%20Status This should indent properly now. Seems dl does not inherit the padding-left used by the indent class in the p tag. I coded a work around. Someone can fill me in if there is a better way to do this.
Re: WIDL - Sync to ReactOS 20050308
Steven Edwards [EMAIL PROTECTED] writes: No one really got back to me on how handles should be done in the dcom.idl so I am going assume this is correct. If this has gotten too big let me know and I can break it up in to smaller patches over the next week. Yes please, every separate change should be a separate patch. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [DPLAYX] fix bug 872
On Tuesday 08 March 2005 17:02, Alexandre Julliard wrote:
Raphael [EMAIL PROTECTED] writes:
Hi,
cf http://bugs.winehq.org/show_bug.cgi?id=872
Seems he have created events (hTemps) leaks no ?
I'm not sure why that code uses global handles at all, since they get
duplicated in the target process anyway; it seems to me you could
simply get rid of the ConvertToGlobalHandle calls. If that doesn't
work the code needs to be fixed, global handles are a Win9x
abomination that should never be used.
Ok, Better patch
Regards,
Raphael
Index: dplobby.c
===
RCS file: /home/wine/wine/dlls/dplayx/dplobby.c,v
retrieving revision 1.39
diff -u -r1.39 dplobby.c
--- dplobby.c 26 Jan 2005 21:09:05 - 1.39
+++ dplobby.c 8 Mar 2005 20:54:46 -
@@ -1156,22 +1156,18 @@
LPHANDLE lphRead )
{
/* These are the handles for the created process */
- HANDLE hAppStart, hAppDeath, hAppRead, hTemp;
+ HANDLE hAppStart = INVALID_HANDLE_VALUE;
+ HANDLE hAppDeath = INVALID_HANDLE_VALUE;
+ HANDLE hAppRead = INVALID_HANDLE_VALUE;
SECURITY_ATTRIBUTES s_attrib;
s_attrib.nLength = sizeof( s_attrib );
s_attrib.lpSecurityDescriptor = NULL;
s_attrib.bInheritHandle = TRUE;
- /* FIXME: Is there a handle leak here? */
- hTemp = CreateEventW( s_attrib, TRUE, FALSE, NULL );
- *lphStart = ConvertToGlobalHandle( hTemp );
-
- hTemp = CreateEventW( s_attrib, TRUE, FALSE, NULL );
- *lphDeath = ConvertToGlobalHandle( hTemp );
-
- hTemp = CreateEventW( s_attrib, TRUE, FALSE, NULL );
- *lphRead = ConvertToGlobalHandle( hTemp );
+ *lphStart = CreateEventW( s_attrib, TRUE, FALSE, NULL );
+ *lphDeath = CreateEventW( s_attrib, TRUE, FALSE, NULL );
+ *lphRead = CreateEventW( s_attrib, TRUE, FALSE, NULL );
if( ( !DuplicateHandle( GetCurrentProcess(), *lphStart,
hDestProcess, hAppStart,
@@ -1185,6 +1181,13 @@
)
{
/* FIXME: Handle leak... */
+if (INVALID_HANDLE_VALUE != *lphStart) { CloseHandle(*lphStart); *lphStart = INVALID_HANDLE_VALUE; }
+if (INVALID_HANDLE_VALUE != *lphDeath) { CloseHandle(*lphDeath); *lphDeath = INVALID_HANDLE_VALUE; }
+if (INVALID_HANDLE_VALUE != *lphRead) { CloseHandle(*lphRead); *lphRead = INVALID_HANDLE_VALUE; }
+if (INVALID_HANDLE_VALUE != hAppStart) CloseHandle(hAppStart);
+if (INVALID_HANDLE_VALUE != hAppDeath) CloseHandle(hAppDeath);
+if (INVALID_HANDLE_VALUE != hAppRead) CloseHandle(hAppRead);
+
ERR( Unable to dup handles\n );
return FALSE;
}
pgptcxHRw03FH.pgp
Description: PGP signature
Re: [winecfg] Audio device selection
On 07 Mar 2005 16:16:25 +0100, Alexandre Julliard [EMAIL PROTECTED] wrote: Paul van Schayck [EMAIL PROTECTED] writes: This is a resend. Patch was rejected probably because we don't want this kind of settings in winecfg. Let me explain myself closer. The patch allows the alsa audio device to be changed from audio tab. It will just use default otherwise. Which is just fine for most users. The main problem is that this option is completely obscure; what are you supposed to enter in there? It should be a drop down listing possible devices. ALSA formed device names like 'plug:dmix' or 'hw:1,1'. Agreed, obscure. I've tried getting the device name with DRV_QUERYDEVICEINTERFACE. That works. I will get things like wineoss: duplex returned (with wine set to alsa). Robert are you referring to this? Paul
Re: Wine in the press
On Wed, 9 Mar 2005 04:20, Kenneth Porter wrote: This aspect should be pushed more to Windows developers. Real Windows is a black box API, and WINE gives great visibility into what's really happening under the covers. Debugging under WINE can reveal info and insight not available under real Windows. I do this all the time. In fact I have a custom modified GDB (and Insight) that can read both Borland debug symbols. Being able to trace things through the WINE API often reveals things about the Windows API that you would be unlikely to figure out with real Windows. There's one hell of a lot of knowledge accumulated in the WINE code about aspects of Windows that are either not documented at all or are poorly documented. I often come across behaviour in WINE and think that's gotta be a bug based on the API docs, only to write test programs to see what happens under Windows and find Windows exhibits the same behaviour.
Re: [DPLAYX] fix bug 872
Raphael wrote:
+ *lphStart = CreateEventW( s_attrib, TRUE, FALSE, NULL );
+ *lphDeath = CreateEventW( s_attrib, TRUE, FALSE, NULL );
+ *lphRead = CreateEventW( s_attrib, TRUE, FALSE, NULL );
if( ( !DuplicateHandle( GetCurrentProcess(), *lphStart,
hDestProcess, hAppStart,
@@ -1185,6 +1181,13 @@
)
{
/* FIXME: Handle leak... */
+if (INVALID_HANDLE_VALUE != *lphStart) { CloseHandle(*lphStart); *lphStart = INVALID_HANDLE_VALUE; }
+if (INVALID_HANDLE_VALUE != *lphDeath) { CloseHandle(*lphDeath); *lphDeath = INVALID_HANDLE_VALUE; }
+if (INVALID_HANDLE_VALUE != *lphRead) { CloseHandle(*lphRead); *lphRead = INVALID_HANDLE_VALUE; }
+if (INVALID_HANDLE_VALUE != hAppStart) CloseHandle(hAppStart);
+if (INVALID_HANDLE_VALUE != hAppDeath) CloseHandle(hAppDeath);
+if (INVALID_HANDLE_VALUE != hAppRead) CloseHandle(hAppRead);
+
You can't close handles from another process.
ERR( Unable to dup handles\n );
return FALSE;
}
Rob
Re: Make running tests on a visible desktop a mandatory requirement
On Wed, Mar 09, 2005 at 12:03:01AM +0800, Dmitry Timoshkov wrote: Hello, it appears that new test for a visible desktop works fine, time to make running tests on a visible desktop a mandatory requirement. Will this not mean no winrash tests any more, only manual ones? I haven't got around to reprogram winrash yet, you know... -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News
Re: [PATCH] MapiSendMail() implementation
Mike Hearn wrote: On Mon, 2005-03-07 at 20:21 +0100, Michael Stefaniuc wrote: Gnome has the notion of default email client, i suspect KDE has it too. Unless you use Bonobo+Evolution (and maybe KMail+DCOP) though you can't match the abilities of MAPI, which lets you create arbitrary emails. Mozilla's command-line API also lets you create rich messages as well (attachments, to/from/subject, body). Perhaps a wine-mapi shell script might be required until freedesktop comes up with a proper mail sending spec? http://www.mozilla.org/docs/command-line-args.html Matt.
Re: Sorce for Wine MIDI Mapper ?
Hi, On Tue, Mar 08, 2005 at 07:54:47PM +, Andrew Neil Ramage wrote: Where would I find the source code for this module ? I want to look at it to see if I can discover why it fails to open when using Noteworthy Composer. [EMAIL PROTECTED]:/usr/local/src/wine$ find . -name *midi* ./dlls/winmm/midimap ./dlls/winmm/midimap/midimap.drv.spec ./dlls/winmm/midimap/midimap.c ./dlls/winmm/midimap/midimap.o ./dlls/winmm/midimap/midimap.drv.dbg.c ./dlls/winmm/midimap/midimap.drv.dbg.o ./dlls/winmm/midimap/midimap.drv.so ./dlls/winmm/mciseq/mcimidi.c ./dlls/winmm/mciseq/mcimidi.o ./dlls/winmm/winealsa/midi.c ./dlls/winmm/winealsa/midi.o ./dlls/winmm/wineoss/midi.c ./dlls/winmm/wineoss/midipatch.c ./dlls/winmm/wineoss/midi.o ./dlls/winmm/wineoss/midipatch.o ./dlls/midimap.drv.so ./multimedia/mcimidi.o ./multimedia/midi.o ./multimedia/midipatch.o dlls/winmm/midimap, I'd say ;-) So use WINEDEBUG=+relay,+msacm for debugging, since that's the debug channel that this module uses. Andreas Mohr
AppDB Can't delete version
Supermaintainers can't delete versions - it asks Are You Sure? but then gives a must be logged in error. If you could fix this I could clean up the winamp entry and get to work on finding the regression. Thanks, Scott Ritchie
Re: unixfs
On Tuesday 08 March 2005 20:12, Alexandre Julliard wrote: I think the extension itself is perfectly reasonable. The thing I'm not sure about is creating a brand new dll for it, adding Wine-specific dlls should be avoided if possible. I moved the unixfs stuff from a separate dll into shell32. Do you think this is reasonable? The patch still needs some polishing, so please don't apply yet. Greetings, -- Michael Jung [EMAIL PROTECTED] unixfs.diff.gz Description: GNU Zip compressed data
AppDB: Escaping / new-line problems
A lot of AppDB entries have broken escaping and some even seem to have only one line. That greatly reduces their readability. Not sure if this is because the formatting was lost over the years. Hopefully it can be fixed in one go for all entries. Otherwise we'll have a big AppDB janitorial cleanup task... Here are some examples: * Gepasi http://appdb.winehq.org/appview.php?appId=1509 Lots of backslashes, quotes are escaped. Appears to be all on one line. * StreetChaves http://appdb.winehq.org/appview.php?appId=1852 Quotes and single-quotes are escaped. All on one line * Neverwinter Nights http://appdb.winehq.org/appview.php?appId=870versionId=1191 Single-quotes are escaped. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
Re: [winecfg] Audio device selection
Paul van Schayck wrote: On 07 Mar 2005 16:16:25 +0100, Alexandre Julliard [EMAIL PROTECTED] wrote: Paul van Schayck [EMAIL PROTECTED] writes: This is a resend. Patch was rejected probably because we don't want this kind of settings in winecfg. Let me explain myself closer. The patch allows the alsa audio device to be changed from audio tab. It will just use default otherwise. Which is just fine for most users. The main problem is that this option is completely obscure; what are you supposed to enter in there? It should be a drop down listing possible devices. ALSA formed device names like 'plug:dmix' or 'hw:1,1'. Agreed, obscure. I've tried getting the device name with DRV_QUERYDEVICEINTERFACE. That works. I will get things like wineoss: duplex returned (with wine set to alsa). Robert are you referring to this? Paul If you look at it from a windows perspective, you would do a waveOutGetNumDevs and iterate over the devices doing a waveOutGetDevCaps to get the device name. One of those devices would be the preferred device and somehow windows sets that. You can do a waveOutMessage with DRVM_MAPPER_PREFERRED_GET to get that device. You can currently get the number of devices and iterate over them using the OSS driver. We don't have a way of specifying which is the preferred one. You can specify it in Direct Sound but that doesn't apply to the wave device. The ALSA driver is another issue. It only supports a single device and you have to specify it manually. You also have to specify how you want to open it using the device name plug:dmix or hw and also specify which sound card if there is more than one. This doesn't map well to the windows way of doing things. I'm not sure what the best solution for this is because they are really different problems. Throwing in the other drivers complicates matters even more. It would be nice to solve this problem in a driver independent way.
server/protocol.def documentation
Hi, I now understand the purpose of SERVER_START_REQ et al, but now I'm in server/protocol.def and I'm trying to add a protocol definition for load_key. load_key is implemented in server/registry.c, but is not in server/protocol.def so, if I'm correct, I can't make a call to load_key from ntdll yet. I am trying to add load_key to protocol.def, but I don't know the semantics of this file. Is there any documentation available for this topic, or does anyone have any information that could be added to the docs? -- James Hawkins
Re: New uninstaller
Jonathan Ernst [EMAIL PROTECTED] wrote:
Thanks for the hint. I found the allocation problem.
Here is another one:
+int len = GetWindowTextLengthW(GetDlgItem(hwnd,
IDC_FILTER));
+if(len 0)
+{
+sFilter = (WCHAR*)GlobalAlloc(GPTR, len + 1);
+GetDlgItemTextW(hwnd, IDC_FILTER, sFilter, len +
1);
And this one:
+/* Load MessageBox's strings */
+LoadStringW(hInst, IDS_APPNAME, sAppName, sizeof(sAppName));
+LoadStringW(hInst, IDS_ABOUTTITLE, sAboutTitle, sizeof(sAboutTitle));
+LoadStringW(hInst, IDS_ABOUT, sAbout, sizeof(sAbout));
+LoadStringW(hInst, IDS_REGISTRYKEYNOTAVAILABLE,
sRegistryKeyNotAvailable, sizeof(sRegistryKeyNotAvailable));
+LoadStringW(hInst, IDS_UNINSTALLFAILED, sUninstallFailed,
sizeof(sUninstallFailed));
LoadStringW takes number of WCHARs, not bytes.
Everything else seems to be good enough.
P.S. Do I really have to split this new uninstaller in different patches
as nearly everything changed ?
It's up to Alexandre to decide, just send your work to wine-patches.
--
Dmitry.
Re: Make running tests on a visible desktop a mandatory requirement
Jakov af Wallby [EMAIL PROTECTED] wrote: Will this not mean no winrash tests any more, only manual ones? I haven't got around to reprogram winrash yet, you know... I know nothing about winrash, but if it's possible to tell it to run the tests on a visible desktop then it would be great. -- Dmitry.
Re: AppDB Can't delete version
There seems to be several formatting issues on the way the DB interface serves things up. When I recently entered Dragon Naturally Speaking , part of the submission invooved typing info into an HTML template . Unfortunatly the template was served up as raw HTML code , I am very familiar with HTML but I am not going to twist my brain around trying to parse an nested table structure in my head to work out what to put where. Especially when this was not even formatted in a human readable form. This severly limitted the quality of the information I was able to enter. I imagine that there has been a system migration at some time and some bugs have not been ironed out. Regards. On Wed, 09 Mar 2005 00:36:31 +0100, Scott Ritchie [EMAIL PROTECTED] wrote: Supermaintainers can't delete versions - it asks Are You Sure? but then gives a must be logged in error. If you could fix this I could clean up the winamp entry and get to work on finding the regression. Thanks, Scott Ritchie -- Opera 7 mail on Linux
Re: New uninstaller
P.S. Do I really have to split this new uninstaller in different patches as nearly everything changed ? It's up to Alexandre to decide, just send your work to wine-patches. I would suggest that you do split it into seperate patches. If one of your patches causes a regression, it's easier to find the regression if the changes are small. Secondly, it's easier to review and verify small patches. Thirdly, since small patches are easier to check, they're easier to get accepted. How about creating three seperate patches that: 1. Change to use a dialog 2. Change to use unicode 3. internationalize the code This seems slower, but it will actually be faster, since you'll only need to perfect one patch at a time. Mike
Re: Menu protocol.
On Tue, 2005-03-08 at 21:02 +, Mike Hearn wrote: On Mon, 07 Mar 2005 14:36:03 -0800, George Farris wrote: Whats the protocol as far as adding a top level menu under Applications? I want to port a number of Ham radio apps over and put them in their own menu called.. wait for it.. Amateur Radio. Would this be frowned upon? The apps would be coming from universe. I think it'd be better to formalise a new category as an extension to the FDO .desktop spec, then adjust the upstream menu XML definition, assuming there is one (they always look the same on GNOME based distros so I expect there is). That way it's not Ubuntu specific. thanks -mike On this matter, do we want to create a Wine top-level entry in the Applications menu? We can start it as an Ubuntu-specific extension, include the appropriate .desktop files in the Ubuntu package (I'll write them myself), and then just send changes upstream? I envision the following process for a user after installing the Wine package: a new Wine menu entry will appear under Applications, and within that will be a Program Files subfolder with installed Windows apps and the included apps (like our notepad). Adjacent Program Files will be the GUI configuration tools - winecfg, the uninstaller, etc. Stuff could also be installed here that isn't Wine explicitly, like the Winetools package. Thoughts? -Scott Ritchie
Re: Make running tests on a visible desktop a mandatory requirement
On Wed, Mar 09, 2005 at 09:04:20AM +0800, Dmitry Timoshkov wrote: I know nothing about winrash, but if it's possible to tell it to run the tests on a visible desktop then it would be great. Not as far as we know. I still don't understand why you insist on killing winrash and automated testing along the way. Please fix winrash if it can be fixed, if not just find a way to sort/fiter/etc the tests better based on the visibility flag, don't prevent the ones that work from working. -- Dimi.
Re: server/protocol.def documentation
On Tue, Mar 08, 2005 at 06:38:01PM -0600, James Hawkins wrote: Hi, I now understand the purpose of SERVER_START_REQ et al, but now I'm in server/protocol.def and I'm trying to add a protocol definition for load_key. load_key is implemented in server/registry.c, but is not in server/protocol.def so, if I'm correct, I can't make a call to load_key from ntdll yet. I am trying to add load_key to protocol.def, but I don't know the semantics of this file. Is there any documentation available for this topic, or does anyone have any information that could be added to the docs? I think you should be looking at dlls/advapi32/registry.c::RegLoadKeyW() for a registry load key implementation. It is using the load_registry request. Ciao, Marcus
Re: server/protocol.def documentation
On Wed, 9 Mar 2005 07:34:16 +0100, Marcus Meissner [EMAIL PROTECTED] wrote: On Tue, Mar 08, 2005 at 06:38:01PM -0600, James Hawkins wrote: Hi, I now understand the purpose of SERVER_START_REQ et al, but now I'm in server/protocol.def and I'm trying to add a protocol definition for load_key. load_key is implemented in server/registry.c, but is not in server/protocol.def so, if I'm correct, I can't make a call to load_key from ntdll yet. I am trying to add load_key to protocol.def, but I don't know the semantics of this file. Is there any documentation available for this topic, or does anyone have any information that could be added to the docs? I think you should be looking at dlls/advapi32/registry.c::RegLoadKeyW() for a registry load key implementation. It is using the load_registry request. Ciao, Marcus I looked at RegLoadKeyW/A, but I don't know why load_registry was chosen over load_key. If the common opinion is that we use load_registry instead of load_key, I can do that (it would be easier anyway), but the plan is to implement NtLoadKey and have RegLoadKey call NtLoadKey. -- James Hawkins
Re: Make running tests on a visible desktop a mandatory requirement
On Wed, 2005-03-09 at 06:52, Dimitrie O. Paun wrote: On Wed, Mar 09, 2005 at 09:04:20AM +0800, Dmitry Timoshkov wrote: I know nothing about winrash, but if it's possible to tell it to run the tests on a visible desktop then it would be great. Not as far as we know. I still don't understand why you insist on killing winrash and automated testing along the way. Please fix winrash if it can be fixed, if not just find a way to sort/fiter/etc the tests better based on the visibility flag, don't prevent the ones that work from working. The patch is already committed so we have to see how many tests do come in now. Couldn't a quick-and-dirty one be to let winrash fill one of the RunOnce keys? That way we have a semi-automated testing environment, at least if the user logs in. Paul.
