Re: Removed as super maintainer
So do we have to reapply now, or can you just readd me as supermaintainer to half-life sound selector? My email I use on there is the same as this one. On 12/13/06, Chris Morgan <[EMAIL PROTECTED]> wrote: We can modify the cleanup script to output a list of people being removed as maintainers so we can rule that out as a culprit. I'm open to other suggestions about logging operations or storing deleted entries but flagging them as "deleted" and adding a date field if appropriate to track the last time the row was modified, etc. Chris On 12/13/06, Alexander Nicolaysen Sørnes <[EMAIL PROTECTED]> wrote: > Onsdag 13 desember 2006 19:14, skrev Chris Morgan: > > If you didn't receive an email about how you haven't logged in in a > > while then it isn't likely that the appdb cleanup system removed your > > super maintainership. Could this possibly be related to the super > > maintainer changes you put in recently? Like if you process a > > submitted application does it remove your super maintainer status for > > some other apps? > > > > We unfortunately don't log events on the appdb. If we did we could log > > all kinds of stuff and go back and figure out when your entry was > > removed. > > > > Chris > > I couldn't find anything suspicious in my changes, and everything was OK when > I was logged in yesterday. I applied as super maintainer for an app and > approved one in the queue, but that did not remove me. It seems like all the > removals (not just mine) happened between today and yesterday. > > > Regards, > > Alexander N. Sørnes > > > > > > On 12/13/06, Alexander Nicolaysen Sørnes <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > > > It seems like I have been removed from all the applications I was > > > previously a super maintainer of. All my non-super maintainerships seem > > > to be unaffected. Does anyone know the reason? Is it related to the > > > recent server problems? > > > > > > > > > Regards, > > > > > > Alexander N. Sørnes > > > AppDB Administrator > -- Tired of being hammered by spyware, or want to browse the internet in a whole new way? Download Firefox and enjoy a much better internet experience. http://getfirefox.com/
Re: Removed as super maintainer
Chris Morgan wrote: Have you recently submitted any new applications or versions? Have you logged in to appdb within the last few months? Chris On 12/13/06, Aaron Slunt <[EMAIL PROTECTED]> wrote: Alexander Nicolaysen Sørnes wrote: > Hello, > > It seems like I have been removed from all the applications I was previously a > super maintainer of. All my non-super maintainerships seem to be unaffected. > Does anyone know the reason? Is it related to the recent server problems? > > > Regards, > > Alexander N. Sørnes > AppDB Administrator > > > > I just noticed the same thing, I was removed from Half-Life Sound Selector without any notification No not recently, I've had real life to deal with. But seeing as how HLSS hasn't been updated for years, I don't see any new versions of it coming out or whatever. I have logged in within the last few months, most definitely.
Re: Removed as super maintainer
Alexander Nicolaysen Sørnes wrote: Hello, It seems like I have been removed from all the applications I was previously a super maintainer of. All my non-super maintainerships seem to be unaffected. Does anyone know the reason? Is it related to the recent server problems? Regards, Alexander N. Sørnes AppDB Administrator I just noticed the same thing, I was removed from Half-Life Sound Selector without any notification
Re: Firefox-1.5.x on Wine slow on javascript-heavy pages
On my family computer, which runs windows xp, js is incredibly slow on firefox with pages such as gmail. as well. 550mhz P3. I wouldn't think it's necessarily a wine issue moreso than a hardware issue, or the fact that javascript can be cpu intensive. On 12/3/06, Dan Kegel <[EMAIL PROTECTED]> wrote: I've been using Firefox-1.5.x again on wine (using the winehq packages for Ubuntu) on my dual 650MHz system as my main browser again for the last few months. It's working quite well... except that javascript-heavy pages/apps like gmail are a tad sluggish at accepting keyboard input. For some reason, yahoo.com's main page is also sluggish; they must do something fancy. Both are fine with native firefox on this system. I'm sure this won't affect anyone with a modern system, but it is kind of sad that my trusty old dual CPU system isn't up to daily tasks anymore. Sniff... ah, well, I see Fry's has amd64 4000 motherboard/cpu combos for $189, guess it's time to upgrade. At some point it'd be nice to look into why Firefox's javascript is slow under Wine, though. - Dan -- Tired of being hammered by spyware, or want to browse the internet in a whole new way? Download Firefox and enjoy a much better internet experience. http://getfirefox.com/
Re: Bug in MapAndLoad function
Aaron Slunt wrote:
Adam Connell wrote:
Greetings,
While investigating why a game (Kasparov's Chessmate) didn't work,
I think I found a bug in the implementation of imagehlp.dll in the
the MapAndLoad function located in dlls/imagehlp/access.c lines
165-167. The function looks like it tries to open an uninitialized
string szFileName instead of the passed file name "pszImageName".
I think there has been a bug filed already (Bug 6099 Alien Shooter
needs imagehlp.dll override) and I think this explains it.
Wine version 0.9.25
/***
*MapAndLoad (IMAGEHLP.@)
*/
BOOL WINAPI MapAndLoad(
LPSTR pszImageName, LPSTR pszDllPath, PLOADED_IMAGE pLoadedImage,
BOOL bDotDll, BOOL bReadOnly)
{
CHAR szFileName[MAX_PATH];
HANDLE hFile = NULL;
HANDLE hFileMapping = NULL;
HMODULE hModule = NULL;
PIMAGE_NT_HEADERS pNtHeader = NULL;
TRACE("(%s, %s, %p, %d, %d)\n", pszImageName, pszDllPath,
pLoadedImage,
bDotDll, bReadOnly);
/* PathCombine(&szFileName, pszDllPath, pszImageName); */
/* PathRenameExtension(&szFileName, bDotDll?:"dll":"exe"); */
/* FIXME: Check if the file already loaded (use
IMAGEHLP_pFirstLoadedImage) */
if(!(hFile = CreateFileA(
szFileName, GENERIC_READ, 1, /* FIXME: FILE_SHARE_READ not
defined */
NULL, OPEN_EXISTING, 0, NULL)))
{
SetLastError(ERROR_FILE_NOT_FOUND);
goto Error;
}
Cheers,
Adam
Please file a bug in bugzilla regarding this. wine-devel is not the
place to file bug reports, much more can get done in bugzilla.
http://bugs.winehq.org
Thank you.
And yes I saw a bug was already filed about it, I meant if you think it
might've been a different issue to file a separate report. But if you
think it's the same bug, then the best you can do is post about it in
bugzilla, since wine-devel is not a place to report bugs.
Thank you.
Re: Bug in MapAndLoad function
Adam Connell wrote:
Greetings,
While investigating why a game (Kasparov's Chessmate) didn't work,
I think I found a bug in the implementation of imagehlp.dll in the
the MapAndLoad function located in dlls/imagehlp/access.c lines
165-167. The function looks like it tries to open an uninitialized
string szFileName instead of the passed file name "pszImageName".
I think there has been a bug filed already (Bug 6099 Alien Shooter
needs imagehlp.dll override) and I think this explains it.
Wine version 0.9.25
/***
* MapAndLoad (IMAGEHLP.@)
*/
BOOL WINAPI MapAndLoad(
LPSTR pszImageName, LPSTR pszDllPath, PLOADED_IMAGE pLoadedImage,
BOOL bDotDll, BOOL bReadOnly)
{
CHAR szFileName[MAX_PATH];
HANDLE hFile = NULL;
HANDLE hFileMapping = NULL;
HMODULE hModule = NULL;
PIMAGE_NT_HEADERS pNtHeader = NULL;
TRACE("(%s, %s, %p, %d, %d)\n", pszImageName, pszDllPath,
pLoadedImage,
bDotDll, bReadOnly);
/* PathCombine(&szFileName, pszDllPath, pszImageName); */
/* PathRenameExtension(&szFileName, bDotDll?:"dll":"exe"); */
/* FIXME: Check if the file already loaded (use
IMAGEHLP_pFirstLoadedImage) */
if(!(hFile = CreateFileA(
szFileName, GENERIC_READ, 1, /* FIXME: FILE_SHARE_READ not defined
*/
NULL, OPEN_EXISTING, 0, NULL)))
{
SetLastError(ERROR_FILE_NOT_FOUND);
goto Error;
}
Cheers,
Adam
Please file a bug in bugzilla regarding this. wine-devel is not the
place to file bug reports, much more can get done in bugzilla.
http://bugs.winehq.org
Thank you.
Re: Wine 0.9.25 full of regressions!
On 11/12/06, Joseph Garvin <[EMAIL PROTECTED]> wrote: Aaron Slunt wrote:>> Wine is still beta software, it has never been officially released,>> therefore you have to expect these sorts of things.I think that misses the point. Users expect software to improve between releases, not totally break. It's pretty obvious that there is no onechecking to make sure common apps work before rolling the releasetarballs. Granted, sometimes it's necessary for parts of wine to betotally restructured in order to do things correctly and avoiding regressions in this case is unavoidable, but as far as I'm aware fromlurking on wine-patches there weren't any great restructurings of howOpenGL worked in 0.9.25. To be honest it doesn't feel like there has been a significant move towards preventing regressions since 0.9.0,which I thought was the point of that release, although I may misunderstand.Why would it be so difficult to have someone to pick a couple of common apps, like winzip, word, and warcraft3, and make sure they stillfunction before every release?I don't see the point in this. It's not officially released software, so why put resources in to test apps on non-official software? If something breaks in the latest release, go back to the one before that that was working, and file a bug in bugzilla about the regressions.If there isn't a problem, then properly testing beta software will just waste time. If there is a problem, then bugzilla is just as effective as testing. -- Tired of being hammered by spyware, or want to browse the internet in a whole new way? Download Firefox and enjoy a much better internet experience.http://getfirefox.com/
Re: Wine 0.9.25 full of regressions!
Mirek wrote: Hi, i just instaled wine 0.9.25 (i had 0.9.24) and it is full of regressions, why is this possible, why is not there someone who can test wine before it came out to new release? 1. 3DMark 2003 - cant open setigns menu 2. 3DMark 2003 - with GLSL, almost all working test are broken (bad graphic) 3. 3DMark 2003 - with ARB is about 25% slower 4. HL2 Episode One - Some characters are black 5. NFS: MW - with ARB it is slower 6. W3 - cannot run, because of Opengl init 7. W3 FT - same as W3 8. nVidiaSDK - opengl demos in nVidia are not working anymore 9. nVidiaSDK - some Direct3D demos are broken more than in release 0.9.24 9. Prey - not working This is pretty big list, almost half of my apps are not working, or working worst than before, it is sad. Mirek Slugen Wine is still beta software, it has never been officially released, therefore you have to expect these sorts of things.
Re: Re[2]: Linux with Wine is faster than windowsXP?
On 11/5/06, ErV <[EMAIL PROTECTED]> wrote: Dmitry<[EMAIL PROTECTED]> wrote:> Calculating PI is not a representative OS performance test at all, since> it doesn't involve actual OS facilities and mostly uses CPU math power > only.Well, I'm not talking about a performance. Since calculating PI is apure CPU-related task, results must be same or linearly dependand. As I understand, WINEdoes not modify program, just loads it and resolve references to dlls to correct equivalents. But calculation times surely aren'tlinearly dependant nor equal. Why?Victor "ErV" Eremin.You forget, there are different processes between different OSs that are running, which affects cpu load... -- Tired of being hammered by spyware, or want to browse the internet in a whole new way? Download Firefox and enjoy a much better internet experience.http://getfirefox.com/
Re: Hey what about the GL View ports problem.
Philip V. Neves wrote: > I'm starting to see that unless we whine and complain in Bugzilla that > nothing gets done on this issue. So I'm comming on to the wine > developers group to complain. This is a bug that is long and > contentious. Its preventing a large number of perfectly good apps to > be used. Wonder when if ever you people plan on working on it. I mean > really no wonder the people testing are annoyed. > *Roderick* Colenbrander is currently doing a lot of work on opengl. Perhaps you could ask him? And if anyone turns this into a flame war...immaturity goes down hill.
Requesting testing for the hotkey implementation
I'm attaching the patch, first started by Robert Reif, then finished off
by Vincent Povirk, and cleaned up by myself to apply to the current GIT
tree.
I'm asking devs/users to please test this patch out. It implements
Register/UnregisterHotkey in wine. I have yet to come across any issues
with it. The primary concern for this patch would be to see what
happens when two separate programs, or two instances of the same
program, try to register a hotkey that is already in use.
Please let me know how this turns out. It would be really great to
finally have this in wine, but testing needs to happen first.
Thanks.
--
Index: dlls/user/driver.c
===
RCS file: /home/wine/wine/dlls/user/driver.c,v
retrieving revision 1.4
diff -u -r1.4 driver.c
--- dlls/user/driver.c3 Apr 2006 19:46:56 -1.4
+++ dlls/user/driver.c7 May 2006 20:15:34 -
@@ -76,6 +76,8 @@
GET_USER_FUNC(ActivateKeyboardLayout);
GET_USER_FUNC(Beep);
+GET_USER_FUNC(RegisterHotKey);
+GET_USER_FUNC(UnregisterHotKey);
GET_USER_FUNC(GetAsyncKeyState);
GET_USER_FUNC(GetKeyNameText);
GET_USER_FUNC(GetKeyboardLayout);
@@ -216,6 +218,16 @@
return -1;
}
+static BOOL nulldrv_RegisterHotKey(HWND hwnd,INT id,UINT modifiers,UINT vk)
+{
+return FALSE;
+}
+
+static BOOL nulldrv_UnregisterHotKey(HWND hwnd,INT id)
+{
+return FALSE;
+}
+
static void nulldrv_SetCursor( struct tagCURSORICONINFO *info )
{
}
@@ -421,6 +433,8 @@
nulldrv_ToUnicodeEx,
nulldrv_UnloadKeyboardLayout,
nulldrv_VkKeyScanEx,
+nulldrv_RegisterHotKey,
+nulldrv_UnregisterHotKey,
/* mouse functions */
nulldrv_SetCursor,
nulldrv_GetCursorPos,
@@ -538,6 +552,16 @@
return load_driver()->pVkKeyScanEx( ch, layout );
}
+static BOOL loaderdrv_RegisterHotKey(HWND hwnd,INT id,UINT
modifiers,UINT vk)
+{
+return load_driver()->pRegisterHotKey( hwnd, id, modifiers, vk );
+}
+
+static BOOL loaderdrv_UnregisterHotKey(HWND hwnd,INT id)
+{
+return load_driver()->pUnregisterHotKey( hwnd, id );
+}
+
static void loaderdrv_SetCursor( struct tagCURSORICONINFO *info )
{
load_driver()->pSetCursor( info );
@@ -737,6 +761,8 @@
loaderdrv_ToUnicodeEx,
loaderdrv_UnloadKeyboardLayout,
loaderdrv_VkKeyScanEx,
+loaderdrv_RegisterHotKey,
+loaderdrv_UnregisterHotKey,
/* mouse functions */
loaderdrv_SetCursor,
loaderdrv_GetCursorPos,
Index: dlls/user/input.c
===
RCS file: /home/wine/wine/dlls/user/input.c,v
retrieving revision 1.10
diff -u -r1.10 input.c
--- dlls/user/input.c27 Mar 2006 20:51:17 -1.10
+++ dlls/user/input.c7 May 2006 20:15:35 -
@@ -653,8 +653,10 @@
*/
BOOL WINAPI RegisterHotKey(HWND hwnd,INT id,UINT modifiers,UINT vk)
{
-FIXME_(keyboard)("(%p,%d,0x%08x,%d): stub\n",hwnd,id,modifiers,vk);
-return TRUE;
+TRACE_(keyboard)("(%p,0x%x,0x%08x,0x%08x)\n",hwnd,id,modifiers,vk);
+if (USER_Driver->pRegisterHotKey)
+return USER_Driver->pRegisterHotKey( hwnd, id, modifiers, vk );
+return FALSE;
}
/***
@@ -662,8 +664,10 @@
*/
BOOL WINAPI UnregisterHotKey(HWND hwnd,INT id)
{
-FIXME_(keyboard)("(%p,%d): stub\n",hwnd,id);
-return TRUE;
+TRACE_(keyboard)("(%p,%d)\n",hwnd,id);
+if (USER_Driver->pUnregisterHotKey)
+return USER_Driver->pUnregisterHotKey( hwnd, id );
+return FALSE;
}
/***
Index: dlls/user/user_private.h
===
RCS file: /home/wine/wine/dlls/user/user_private.h,v
retrieving revision 1.20
diff -u -r1.20 user_private.h
--- dlls/user/user_private.h10 Aug 2005 09:56:23 -1.20
+++ dlls/user/user_private.h7 May 2006 20:15:35 -
@@ -114,6 +114,8 @@
INT(*pToUnicodeEx)(UINT, UINT, LPBYTE, LPWSTR, int, UINT, HKL);
BOOL (*pUnloadKeyboardLayout)(HKL);
SHORT (*pVkKeyScanEx)(WCHAR, HKL);
+BOOL (*pRegisterHotKey)(HWND, INT, UINT, UINT);
+BOOL (*pUnregisterHotKey)(HWND, INT);
/* mouse functions */
void (*pSetCursor)(struct tagCURSORICONINFO *);
BOOL (*pGetCursorPos)(LPPOINT);
Index: dlls/x11drv/keyboard.c
===
RCS file: /home/wine/wine/dlls/x11drv/keyboard.c,v
retrieving revision 1.90
diff -u -r1.90 keyboard.c
--- dlls/x11drv/keyboard.c20 Apr 2006 09:41:15 -1.90
+++ dlls/x11drv/keyboard.c7 May 2006 20:15:38 -
@@ -89,7 +89,7 @@
static int min_keycode, max_keycode, keysyms_per_keycode;
static WORD keyc2vkey[256], keyc2scan[256];
-static int NumLockMask, AltGrMask; /* mask in the XKeyEvent state */
+static int NumLockMask, ScrollLockMask, AnyLockMask, AltGrMask,
Met
Re: opengl32: Correctly size and position opengl child windows
Ulrich Czekalla wrote:
This patch override glViewport and glScissor to correctly position and size
opengl child windows.
I've only tested this patch with Google Earth and Google Sketchup so I'd
like to get some feedback to see if this solves the problem for your
application.
Roderick: I realize you're currently reworking opengl32 so let me know if
this conflicts with what you are doing.
Thanks,
/Ulrich
---
dlls/opengl32/make_opengl | 15 +++
dlls/opengl32/opengl_ext.h|5 ++
dlls/opengl32/opengl_norm.c | 10 ++---
dlls/opengl32/wgl.c | 78 +
dlls/winex11.drv/opengl.c | 72 --
dlls/winex11.drv/winex11.drv.spec |1
6 files changed, 172 insertions(+), 9 deletions(-)
6b6a26ef714827017c5ae438b2f843766d711cb2
diff --git a/dlls/opengl32/make_opengl b/dlls/opengl32/make_opengl
index 837b8d9..bfb0191 100755
--- a/dlls/opengl32/make_opengl
+++ b/dlls/opengl32/make_opengl
@@ -266,6 +266,21 @@ sub GenerateThunk($)
if ( $func_ref->[0] eq "glGetIntegerv" ) {
$wine_func_ref_name = "internal_glGetIntegerv";
}
+if ( $func_ref->[0] eq "glEnable" ) {
+ $wine_func_ref_name = "internal_glEnable";
+}
+if ( $func_ref->[0] eq "glIsEnable" ) {
+ $wine_func_ref_name = "internal_glIsEnable";
+}
+if ( $func_ref->[0] eq "glDisable" ) {
+ $wine_func_ref_name = "internal_glDisable";
+}
+if ( $func_ref->[0] eq "glScissorr" ) {
+ $wine_func_ref_name = "internal_glScissorr";
+}
+if ( $func_ref->[0] eq "glViewport" ) {
+ $wine_func_ref_name = "internal_glViewport";
+}
$ret = "$ret$prefix$wine_func_ref_name( $call_arg);\n";
if ($thread_safe) {
$ret = "$ret LEAVE_GL();\n";
diff --git a/dlls/opengl32/opengl_ext.h b/dlls/opengl32/opengl_ext.h
index a7fe233..b7263df 100644
--- a/dlls/opengl32/opengl_ext.h
+++ b/dlls/opengl32/opengl_ext.h
@@ -75,5 +75,10 @@ extern const int extension_registry_size
const GLubyte* internal_glGetString(GLenum name);
void internal_glGetIntegerv(GLenum pname, GLint* params);
+void internal_glDisable(GLenum cap);
+void internal_glEnable(GLenum cap);
+GLboolean internal_glIsEnabled(GLenum cap);
+void internal_glScissor(GLint x, GLint y, GLsizei width, GLsizei height);
+void internal_glViewport(GLint x, GLint y, GLsizei width, GLsizei height);
#endif /* __DLLS_OPENGL32_OPENGL_EXT_H */
diff --git a/dlls/opengl32/opengl_norm.c b/dlls/opengl32/opengl_norm.c
index 8374a86..047770f 100644
--- a/dlls/opengl32/opengl_norm.c
+++ b/dlls/opengl32/opengl_norm.c
@@ -815,7 +815,7 @@ void WINAPI wine_glDepthRange( GLclampd
void WINAPI wine_glDisable( GLenum cap ) {
TRACE("(%d)\n", cap );
ENTER_GL();
- glDisable( cap );
+ internal_glDisable( cap );
LEAVE_GL();
}
@@ -915,7 +915,7 @@ void WINAPI wine_glEdgeFlagv( GLboolean*
void WINAPI wine_glEnable( GLenum cap ) {
TRACE("(%d)\n", cap );
ENTER_GL();
- glEnable( cap );
+ internal_glEnable( cap );
LEAVE_GL();
}
@@ -1772,7 +1772,7 @@ GLboolean WINAPI wine_glIsEnabled( GLenu
GLboolean ret_value;
TRACE("(%d)\n", cap );
ENTER_GL();
- ret_value = glIsEnabled( cap );
+ ret_value = internal_glIsEnabled( cap );
LEAVE_GL();
return ret_value;
}
@@ -2889,7 +2889,7 @@ void WINAPI wine_glScalef( GLfloat x, GL
void WINAPI wine_glScissor( GLint x, GLint y, GLsizei width, GLsizei height ) {
TRACE("(%d, %d, %d, %d)\n", x, y, width, height );
ENTER_GL();
- glScissor( x, y, width, height );
+ internal_glScissor( x, y, width, height );
LEAVE_GL();
}
@@ -3759,6 +3759,6 @@ void WINAPI wine_glVertexPointer( GLint
void WINAPI wine_glViewport( GLint x, GLint y, GLsizei width, GLsizei height ) {
TRACE("(%d, %d, %d, %d)\n", x, y, width, height );
ENTER_GL();
- glViewport( x, y, width, height );
+ internal_glViewport( x, y, width, height );
LEAVE_GL();
}
diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c
index 1c3973c..76785d7 100644
--- a/dlls/opengl32/wgl.c
+++ b/dlls/opengl32/wgl.c
@@ -84,6 +84,7 @@ static Display *default_display; /* dis
static HMODULE opengl32_handle;
static void* (*p_glXGetProcAddressARB)(const GLubyte *);
+static void (*p_SyncCurrentDrawable)();
static char internal_gl_disabled_extensions[512];
static char* internal_gl_extensions = NULL;
@@ -95,6 +96,9 @@ typedef struct wine_glcontext {
GLXFBConfig fb_conf;
GLXContext ctx;
BOOL do_escape;
+ RECT viewport;
+ RECT scissor;
+ BOOL scissor_enabled;
struct wine_glcontext *next;
struct wine_glcontext *prev;
} Wine_GLContext;
@@ -124,6 +128,7 @@ inline static Display *get_display( HDC
return display;
}
+
/***
* wglCreateLayerContext (OPENGL32.@)
*/
@@ -563,6 +568,72 @@ BOOL WINAPI wglUseFontOutlinesW(HDC hdc,
return wglUseFontOutlines_common(hdc, first, count, listBase, deviati
Re: Copy protection
Jesse Allen wrote: Guys, Wine programs can write to the MBR already with correct permissions... http://bugs.winehq.org/show_bug.cgi?id=4672 I hope nobody needs to explain why that's a very bad idea...
Re: my dsound/winealsa hacks
Tomas Carnecky wrote: .. another small update, now tries to create the buffer size as close as possible to what the app requested. The whole patch is available at the same URL, I also created a patch of only ./dlls/winmm/winealsa/audio.c to make it easier to read the patch, the patch is here: http://dbservice.com/ftpdir/tom/alsa-audio.patch tom This sounds beautiful under counter-strike and counter-strike:source. Now if only microphones worked in those games...(never did anyways, lol)
Re: RegisterHotKey/UnregisterHotKey implementation...success?
Vincent Povirk wrote: I believe you misunderstood my problem. If the same program tries to register the same hotkey twice, it will fail. However, if another X program (or another wine program) has already registered a key and you try to register it, this will cause an X error. Which is fine, but I don't think I ever got around to properly handling the X error. On 9/19/06, Aaron Slunt <[EMAIL PROTECTED]> wrote: http://www.winehq.com/pipermail/wine-devel/2006-May/047460.html The above link I looked at, and I saw this person was apparently crashing with the patch when trying to register a hotkey twice (that's how I interpreted it). Anyways, I looked at the patch, and cleaned it up so it applies to the current git tree. Anyways, it seems that I simply cannot reproduce the crash he was talking about. I binded F1 in HLSS (Half-Life Sound Selector), and opened another copy of HLSS. It simply would not allow me to register the key again. So I closed the second copy of HLSS and opened Ventrilo. I attempted to bind F1, and again it simply would not allow it. And let me make this clear, not once did I crash with this patch. HLSS works (fundamentally, not perfectly) when using it with Counter-strike (the hotkey works, there are window management problems though which have nothing to do with this) and I just never crashed with it. I'm attaching the patch for others to test if they could, and to see if a crash can be reproduced. But to me it looks like the work Robert Reif and Vincent Povirk is a huge success. As I had said...I might not have been clear on it. I tried both instances you just said, and not once did have any problems.
RegisterHotKey/UnregisterHotKey implementation...success?
http://www.winehq.com/pipermail/wine-devel/2006-May/047460.html The above link I looked at, and I saw this person was apparently crashing with the patch when trying to register a hotkey twice (that's how I interpreted it). Anyways, I looked at the patch, and cleaned it up so it applies to the current git tree. Anyways, it seems that I simply cannot reproduce the crash he was talking about. I binded F1 in HLSS (Half-Life Sound Selector), and opened another copy of HLSS. It simply would not allow me to register the key again. So I closed the second copy of HLSS and opened Ventrilo. I attempted to bind F1, and again it simply would not allow it. And let me make this clear, not once did I crash with this patch. HLSS works (fundamentally, not perfectly) when using it with Counter-strike (the hotkey works, there are window management problems though which have nothing to do with this) and I just never crashed with it. I'm attaching the patch for others to test if they could, and to see if a crash can be reproduced. But to me it looks like the work Robert Reif and Vincent Povirk is a huge success.* * 0003-modified-dlls-user-driver.c.txt Description: application/crossover-txt
Something's wrong with my GIT tree
http://pastebin.ca/176787 I've had this for several days, and git fetch tells me everything's up to date. Is this a known issue? How do I get rid of this? ./configure --x-libraries=/emul/linux/x86/usr/lib/ LDFLAGS="-L/emul/linux/x86/usr/lib -L/emul/linux/x86/lib" && make depend && make That configure has always worked for me, and it gets through make depend, it's just failing on make with that error message.
Re: ALSA implementation
Jan Zerebecki wrote: On Sun, Sep 17, 2006 at 05:26:12PM +0100, James Courtier-Dutton wrote: I am an ALSA developer, and at one point tried to fix the wine alsa support. I found the wine source code very difficult to read and understand. Windows seems to have so many different sound APIs, I did not really know where to start. Everything in wine that uses alsa is below dlls/winmm/winealsa/. I explained in a different mail to this thread what bugs are in winealsa. (Archive link to that mail is: http://www.winehq.org/pipermail/wine-devel/2006-September/050826.html ) I suspect that either wine will have to change a lot, or ALSA will have to change a lot before they work nicely together. As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. We just need someone to code this change. It seems I just found out how to fix the other winealsa problem I mentioned in that mail, I'm currently testing if it works. Jan Jan, could you please clarify what you mean by an fd-based method? Thanks.
Re: Low-level coding
Saulius Krasuckas wrote:
* On Sun, 10 Sep 2006, Aaron Slunt wrote:
I was interested in starting to play with wine and maybe even build a
few functions for it...but then I realized that it's low-level coding,
something I'm not familiar with (higher level is more of my expertise).
Correct me if I'm wrong, I could be looking at the wrong files :S.
You are welcome! :)
Can you refer to exact file names your were looking at?
Does anyone have any good places to go to to learn about low-level
coding, and afterwards coding for wine specifically?
For me Wine embraces libs for quite wide spectra of functions and not so
few ioctls:
$ grep -rI "ioctl[^a-zA-Z0-9]*(" dlls/ | wc -l
276
$ grep -rIc "ioctl[^a-zA-Z0-9]*(" dlls/ | grep -v :0
dlls/avicap32/avicap32_main.c:4
dlls/dinput/joystick_linux.c:10
dlls/dinput/joystick_linuxinput.c:7
dlls/dinput/effect_linuxinput.c:2
dlls/iphlpapi/ifenum.c:9
dlls/kernel/comm.c:4
dlls/kernel/sync.c:1
dlls/kernel/oldconfig.c:1
dlls/ntdll/cdrom.c:57
dlls/ntdll/directory.c:7
dlls/ntdll/file.c:1
dlls/ntdll/serial.c:10
dlls/ntdll/tape.c:11
dlls/qcap/v4l.c:17
dlls/winedos/int13.c:1
dlls/winedos/ppdev.c:8
dlls/winmm/joystick/joystick.c:4
dlls/winmm/wineaudioio/audio.c:6
dlls/winmm/wineoss/audio.c:61
dlls/winmm/wineoss/dscapture.c:11
dlls/winmm/wineoss/dsrender.c:15
dlls/winmm/wineoss/midi.c:5
dlls/winmm/wineoss/mixer.c:17
dlls/winmm/wineoss/mmaux.c:3
dlls/wnaspi32/aspi.c:2
dlls/ws2_32/socket.c:2
As for me, low level coding is writing a device driver for linux kernel
:-] and using it from the Wine code.
But there is also a bunch of hardware platform specific issues also, like
advanced signal handling which may be needed for example to make remote
process operations work [1] or to implement ntoskrnl and make safedisc
work [2].
All that stuff needs knowledge of glibc programming at least, I guess.
So maybe you should read recent libc.pdf if you are interested into this
area?
Also, some guys are working on DCOM/OLE stuff [3] which seems to be quite
low level for me sometimes (wire-protocol compatibility).
Going further (upper?) most of Wine code tries to use WinAPI, which I
doubt should be considered as low-level. To get into basic Wine coding it
may be usefull to review Janitorial Projects [4] and maybe to hang on one
of it? :)
Without naming exact Wine component or functionality you are interested in
I doubt someone will answer you more specifically :-P
[1] http://wiki.winehq.org/RemoteProcessOperations
[2] http://wiki.winehq.org/VitaliyMargolen
[3] http://wiki.winehq.org/RobShearman
[4] http://wiki.winehq.org/JanitorialProjects
Thanks all for the replies. I took note to the JanitorialProjects page,
and found the DllCanUnloadNow project.
I wrote a patch for the dinput.c one, to start with getting familiar
with wine's code, and it compiles fine, but I have no way (at least know
of a way) of testing if the implementation actually works or not. It
looks like it should, and it compiles, but I don't know for sure how to
test it out...I've skimmed through the wiki, but I need some human help
as well :(
And I guess I really meant "lower-level" coding, C looks scary as I'm
not familiar with it and it looks more complex than other languages like
Java, but the same syntax makes it a lot easier :O
Thanks for the support, makes things much easier :)
Low-level coding
Hi,I was interested in starting to play with wine and maybe even build a few functions for it...but then I realized that it's low-level coding, something I'm not familiar with (higher level is more of my expertise). Correct me if I'm wrong, I could be looking at the wrong files :S. Does anyone have any good places to go to to learn about low-level coding, and afterwards coding for wine specifically? Thanks.-- Tired of being hammered by spyware, or want to browse the internet in a whole new way? Download Firefox and enjoy a much better internet experience. http://getfirefox.com/
ALSA implementation
Hi, I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well. My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly? Thanks.
