Re: wine's fullscreen code has no effect on metacity
Elijah Newren [EMAIL PROTECTED] wrote: Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them. Wine asks a WM to switch off the fullscreen state as a result of app's request to change its window size to something less than a screen resolution. So, the fix would be to change Metacity to not restore window's size if it's no more the same as it was before entering the full screen state. Also I notice that IE when returning from fullscreen state doesn't restore its caption back, while under KDE it does. Let me know whether it's a known/fixed bug, or if further investigation is needed. -- Dmitry.
Re: user[2/2]: Preserve LastError.
Vitaliy Margolen [EMAIL PROTECTED] writes: Anything wrong with this patch? Test case clearly shows that we should preserve the LastError. In general, saving/restoring last error is discouraged, the function should be fixed to not change it at all. Do you have an app that depends on this? -- Alexandre Julliard [EMAIL PROTECTED]
Re: [FreeBSD] locating wine at 0x20000000
On Monday 31 July 2006 18:15, Tijl Coosemans wrote: On Monday 31 July 2006 16:22, Alexandre Julliard wrote: Tijl Coosemans [EMAIL PROTECTED] writes: So I was thinking of moving Wine to 0x2000. That would be the easiest solution by far, but, are there any potential problems with that? Yes, that's too low, apps can expect that address to be free. If you can't change the 512Mb thing then you should use something around 0x5000, but really the 0x7000 range would be preferable. I can lower the 512Mb with setrlimit and RLIMIT_DATA, but that would have to happen inside the preloader (using a direct syscall I suppose), which currently isn't used on FreeBSD and probably doesn't even work. So I'll add that to my todo list and use something in the 0x5000 range for now. It turns out I don't need the preloader for that... Currently I lower RLIMIT_DATA to 0x1800 (384Mb) in wine-glibc and locate wine-pthread at 0x6400. Is this an acceptable location? There has to be enough room after wine-pthread + data segment for every lib and dlopen'ed object. Moreover, the data segment can't be too small because it's the malloc heap and the limit is inherited by the wineserver process. So this is a bit of a balancing act.
DirectX can't change Screen depth
Hello, I'm maintaining a game named Blip Blop (http://appdb.winehq.org/appview.php?iAppId=3470), and I have some problems with color depth. If the X server is configured in 16 bits colors, it works well, but if it's in 24 or 32 bits, the app display in black and white, and I've got the following message : fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 Looking at the source, it seems that changing resolution is not implemented, and that doesn't surprise me as it doesn't seem to be a good idea to change X depth to please a wine app (especially if we're emulating a desktop). But shouldn't the 16 bits output be converted by wine to 24/32 bits to be displayed. Is it a problem with the way the game is coded (maybe it should check return code to fall back to another depth) ? Regards, -- Colin Pitrat (Bull Services Telco) Bull, Architect of an Open World (TM) Tél : +33 (0) 1 30 80 72 93 www.bull.com
Re: Tijl Coosemans : ntdll: Add FreeBSD default serial port device.
On Mon, Aug 07, 2006 at 07:13:04AM -0500, Alexandre Julliard wrote: Module: wine Branch: refs/heads/master Commit: e548d4083177125559f752d902907187cea60474 URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=e548d4083177125559f752d902907187cea60474 Author: Tijl Coosemans [EMAIL PROTECTED] Date: Sat Aug 5 23:12:22 2006 +0200 ntdll: Add FreeBSD default serial port device. --- dlls/ntdll/directory.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c index 47d018a..84624a8 100644 --- a/dlls/ntdll/directory.c +++ b/dlls/ntdll/directory.c @@ -175,6 +175,13 @@ #ifdef linux strcpy( ret, /dev/ttyS0 ); ret[strlen(ret) - 1] = '0' + num - 1; } +#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) +ret = RtlAllocateHeap( GetProcessHeap(), 0, sizeof(/dev/cuad0) ); Surely you mean strlen()+1. sizeof(hallo) might just be sizeof(char*) Ciao, Marcus
Re: wineconsole: command line option output / default user backend
Ekkehard Morgenstern [EMAIL PROTECTED] writes: This small patch provides command line option output, a --help option and a default user backend (--backend=user is default) to wineconsole. Your mailer wrapped the patch, please resend it. Also please send separate changes as separate patches, and try to follow the coding conventions of the surrounding code. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DirectX can't change Screen depth
On 8/7/06, Colin Pitrat [EMAIL PROTECTED] wrote: colors, it works well, but if it's in 24 or 32 bits, the app display in black and white, and I've got the following message : fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 I've seen this in lots of games but the colours are always ok -- maybe it is specific to that game? n0dalus.
Re: riched20: modify ME_CharFromPoint to work properly with password controls
Oops! Good Call, Phil.
Attached is an updated patch.
--Matt
On 8/7/06, Phil Krylov [EMAIL PROTECTED] wrote:
Hi Matt,
On 07/08/06, Matt Finnicum [EMAIL PROTECTED] wrote:
This patch modifies ME_CharFromPoint to work properly with password
controls (the patch i sent in / got committed a couple days ago).
Should not the temp string be freed afterwards?
-- Ph.
From 880850b5980515549833854c81e8d445cba758cb Mon Sep 17 00:00:00 2001
From: Matthew Finnicum [EMAIL PROTECTED]
Date: Mon, 7 Aug 2006 10:12:44 -0400
Subject: [PATCH] riched20: modify ME_CharFromPoint to work properly with
password controls
---
dlls/riched20/run.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/dlls/riched20/run.c b/dlls/riched20/run.c
index d74d68f..f9b1ef6 100644
--- a/dlls/riched20/run.c
+++ b/dlls/riched20/run.c
@@ -512,8 +512,20 @@ int ME_CharFromPoint(ME_TextEditor *edit
}
hDC = GetDC(editor-hWnd);
hOldFont = ME_SelectStyleFont(editor, hDC, run-style);
- GetTextExtentExPointW(hDC, run-strText-szData, run-strText-nLen,
-cx, fit, NULL, sz);
+
+ if (editor-cPasswordMask)
+ {
+ME_String *strMasked =
ME_MakeStringR(editor-cPasswordMask,ME_StrVLen(run-strText));
+GetTextExtentExPointW(hDC, strMasked-szData, run-strText-nLen,
+ cx, fit, NULL, sz);
+ME_DestroyString(strMasked);
+ }
+ else
+ {
+GetTextExtentExPointW(hDC, run-strText-szData, run-strText-nLen,
+ cx, fit, NULL, sz);
+ }
+
ME_UnselectStyleFont(editor, hDC, run-style, hOldFont);
ReleaseDC(editor-hWnd, hDC);
return fit;
--
1.4.1.1
Re: Tijl Coosemans : ntdll: Add FreeBSD default serial port device.
On Monday 07 August 2006 14:26, Marcus Meissner wrote: On Mon, Aug 07, 2006 at 07:13:04AM -0500, Alexandre Julliard wrote: Module: wine Branch: refs/heads/master Commit: e548d4083177125559f752d902907187cea60474 URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=e548d4083177125559f752d902907187cea60474 Author: Tijl Coosemans [EMAIL PROTECTED] Date: Sat Aug 5 23:12:22 2006 +0200 ntdll: Add FreeBSD default serial port device. --- dlls/ntdll/directory.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c index 47d018a..84624a8 100644 --- a/dlls/ntdll/directory.c +++ b/dlls/ntdll/directory.c @@ -175,6 +175,13 @@ #ifdef linux strcpy( ret, /dev/ttyS0 ); ret[strlen(ret) - 1] = '0' + num - 1; } +#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) +ret = RtlAllocateHeap( GetProcessHeap(), 0, sizeof(/dev/cuad0) ); Surely you mean strlen()+1. sizeof(hallo) might just be sizeof(char*) strlen would certainly be safer, but I think sizeof sees the string as an array here, not a pointer. In any case, I simply copy-pasted the #ifdef linux, so that would have to change as well.
Re: riched20: new selection invalidation logic
Monday, August 7, 2006, 9:27:16 AM, Krzysztof Foltman wrote: ChangeLog: * New, clean, simple selection repaint logic - should fix all outstanding refresh issues (and bug#5882) Krzysztof I think this patch takes number of asserts per line to the highest level I've ever seen. Could you explain why you adding asserts everywhere (only 11 in this patch alone!!!)? Instead of using proper error handling? For the past year or more that was the main source of user problems. And if you could how many installers have been broken with this technique, you will probably account for 90% of all the installers that otherwise would work on Wine. Have you even tried your code on purposely broken rtf? How does it handle it? Vitaliy Margolen
Re: riched20: new selection invalidation logic
Vitaliy Margolen wrote: I think this patch takes number of asserts per line to the highest level I've ever seen. Could you explain why you adding asserts everywhere (only 11 in this patch alone!!!)? Instead of using proper error handling? Well, that's the good question. The thing is, those conditions should never happen, and if they do happen, then something is really wrong somewhere with the code and a crash may happen anyway. I think it's better to get an assertion failure early than a random crash when it's too late to diagnose anything. And one can always comment the asserts out. But there are valid reasons why those asserts should be avoided. It's just about short term vs long term benefits. Maybe an option to disable those asserts would be a good idea so that people who just need to get the job done aren't messed with - but then we don't get half the bug reports we get now. As for the enormous (or even insane) amount of asserts - there's no such thing ;) Those asserts are pretty paranoid-level - chances of any of them happening is really, really low - and that's totally different to my previous repaint patch which had one assertion I predicted may be risky (which proved something is wrong with repaint, so it kinda served the purpose). The good solution would be a decent regression test, but it seems to be pretty difficult and/or tedious (simulating real-life conditions for testing repainting is hard because of relative timing/order of window messages). For the past year or more that was the main source of user problems. And if you could how many installers have been broken with this technique, you will probably account for 90% of all the installers that otherwise would work on Wine. Have you even tried your code on purposely broken rtf? How does it handle it? Those asserts are relatively independent on text input, and more on user interaction with the editor, which, as I already said, is hard to simulate and test (that's why I'm kind of shifting responsibility to end users: I may do as much monkey tests as you want, still I may get into some ruts of usage pattern). Anyway, the issue is not easy to solve, so I'd be grateful for any ideas that may help in solving this important issue. Krzysztof
Re: riched20: new selection invalidation logic
On 8/7/06, Krzysztof Foltman [EMAIL PROTECTED] wrote: +#define static That deserves a comment, at the very least! I don't think such a define should be allowed. Can you recode without this? I like the number of asserts. It's hard to get this stuff right, and the asserts will help make sure the code is correct. - Dan
Re: user[2/2]: Preserve LastError.
Monday, August 7, 2006, 3:52:51 AM, Alexandre Julliard wrote: Vitaliy Margolen [EMAIL PROTECTED] writes: Anything wrong with this patch? Test case clearly shows that we should preserve the LastError. In general, saving/restoring last error is discouraged, the function should be fixed to not change it at all. Do you have an app that Sure but we call TlsGetValue() which does set LastError. So unless we can avoid that call (which I doubt) we have to do something extra to preserve the LastError. depends on this? No I don't have any games directly. But I had few tests testing several things in screen related areas and wasn't getting correct LastError. Also, looking at the fact that x11drv doesn't set LastError at all we should preserve it as much as possible. I haven't seen that many places in user32 that take care of preserving LastError either. Vitaliy.
Constifying Undocumented Code?
Where we emulate undocumented code, is it acceptable to constify the formal arguments, where appropriate? Thanks, -- Andy.
Re: Time to commit remote ops for VirtualAllocEx, CreateRemoteThread
On Sat, 05 Aug 2006 10:32:15 +0200, Alexandre Julliard wrote: Still, doing that stuff in APCs is a step in the right direction, you just need to make sure you can safely run these APCs from the SIGUSR1 handler. How is the thread to interrupt to be selected? I really am not seeing what's wrong with a service thread here, it seems the safest and simplest way forward. We can easily put it into stealth mode by disabling the attach/detach notifications. thanks -mike
Re: Constifying Undocumented Code?
On 8/7/06, Andrew Talbot [EMAIL PROTECTED] wrote: Where we emulate undocumented code, is it acceptable to constify the formal arguments, where appropriate? Can you give us examples of code in question? -- James Hawkins
Re: RFC: XEmbed Systray Patches
On Sun, 06 Aug 2006 20:10:19 -0700, James Liggett wrote: so I suspect that this has something to do with stack problem More likely it's a speed issue - logging slows the code down a lot which could fix a race condition. X is sort of susceptible to this kind of thing it seems.
Re: wintrust: Only return ERROR_SUCCESS in WinVerifyTrust
On Sun, 2006-08-06 at 11:43 +0200, Molle Bestefich wrote: Dan Kegel wrote: Not to be harsh, but: Hehe ;-). I know, I was just poking, hoping to get an explanation for why James' particular app might be more beneficial than Process Explorer. (yes, I like Process Explorer, I use it for debugging from time to time.) The optimal thing of course would be to have everything working... Hi, as I was the one introducing it, I thought I had a second look. I just came back from a short holiday did a 'git pull' tested it with the 'ERROR_SUCCESS in every case' and Process Explorer didn't crash !!! I did some (positive) regression testing and found that patch: 13163349521e50e7039e188a22b6a814dcfcfc37 is first bad commit commit 13163349521e50e7039e188a22b6a814dcfcfc37 Author: Alexandre Julliard [EMAIL PROTECTED] Date: Fri Jul 21 11:53:24 2006 +0200 ntdll: Add a few more free list entries to the heap. is actually responsible for making things work with ERROR_SUCCESS as the default. Can anybody (Alexandre?) explain why? Cheers, Paul.
Re: Constifying Undocumented Code?
James Hawkins wrote: Can you give us examples of code in question? In shlwapi/ordinal.c, FDSA_InsertItem(), I would like to change the third parameter's declaration from void * to const void *. -- Andy.
Re: user[2/2]: Preserve LastError.
Vitaliy Margolen [EMAIL PROTECTED] writes: Sure but we call TlsGetValue() which does set LastError. So unless we can avoid that call (which I doubt) we have to do something extra to preserve the LastError. If an app depends on it, yes. No I don't have any games directly. But I had few tests testing several things in screen related areas and wasn't getting correct LastError. Also, looking at the fact that x11drv doesn't set LastError at all we should preserve it as much as possible. I haven't seen that many places in user32 that take care of preserving LastError either. The thing that matters is setting the proper error codes on errors. Setting or not setting last error on success very rarely matters, and both on Windows and Wine it will usually simply be a side-effect of the functions being called internally. If we wanted to replicate the exact Windows behavior we'd essentially need to manipulate last error in every single code path, and that would be a real nightmare; so we should only do it if there's a demonstrated need. -- Alexandre Julliard [EMAIL PROTECTED]
Re: HAL and Copy Protection
On Sun, Aug 06, 2006 at 02:32:23PM -0700, Jesse Allen wrote: On 8/6/06, Marcus Meissner [EMAIL PROTECTED] wrote: On Tue, Aug 01, 2006 at 11:25:12AM -0700, Jesse Allen wrote: Does anyone have HAL and SecuRom copy protection working? I'm starting to get support questions with people using HAL and I'm not sure how to help them. I need information now that HAL support is in Wine on whether SecuRom works with it and how to get it to work as I don't have HAL. HAL as in the Freedesktop.org HAL or the Windows HAL? Freedesktop's HAL. HAL should be of no importance here, there will be no visible difference to static CDROM configuration. Otherwise, no clue. Ciao, Marcus
Re: wintrust: Always return ERROR_SUCCESS in WinVerifyTrust [RESEND]
On Mon, 2006-08-07 at 11:11 -0700, James Hawkins wrote: Hi, Accoring to recent comments by Paul Vriens, Process Explorer now accepts ERROR_SUCCESS from WinVerifyTrust, and several installers require ERROR_SUCCESS in order to continue, so everyone is happy. Fixes bugs 5573 and 3619. http://bugs.winehq.org/show_bug.cgi?id=5573 http://bugs.winehq.org/show_bug.cgi?id=3619 Changelog: * Always return ERROR_SUCCESS in WinVerifyTrust. dlls/wintrust/wintrust_main.c | 18 +- 1 files changed, 5 insertions(+), 13 deletions(-) When I run process explorer without tracing/debugging everything is fine. As soon as I add +wintrust,+heap it fails again. There is most likely some heap corruption somewhere (couldn't be more vague). Alexandre's patch to add more free list entries only masked the problem, as far as I can see from the results. Cheers and sorry for the misleading remarks, Paul.
Re: wineconsole: command line option output / default user backend
Alexandre Julliard wrote: Ekkehard Morgenstern [EMAIL PROTECTED] writes: This small patch provides command line option output, a --help option and a default user backend (--backend=user is default) to wineconsole. Your mailer wrapped the patch, please resend it. Also please send separate changes as separate patches, and try to follow the coding conventions of the surrounding code. also changing the default to user is a bad idea... especially for users wanting to run a text only win32 app from a linux console without X started A+
Re: HAL and Copy Protection
On 8/7/06, Marcus Meissner [EMAIL PROTECTED] wrote: HAL should be of no importance here, there will be no visible difference to static CDROM configuration. Otherwise, no clue. Ciao, Marcus I'm going to try setting up ubuntu with HAL on a spare machine and see what it does. I use slack and I don't want to change what I got already. It will take some time to download and hook up the machine, so that's why I asked here first. Jesse
Re: wintrust: Always return ERROR_SUCCESS in WinVerifyTrust [RESEND]
On 8/7/06, Paul Vriens [EMAIL PROTECTED] wrote: When I run process explorer without tracing/debugging everything is fine. As soon as I add +wintrust,+heap it fails again. There is most likely some heap corruption somewhere (couldn't be more vague). Alexandre's patch to add more free list entries only masked the problem, as far as I can see from the results. Cheers and sorry for the misleading remarks, Can you explain your comment, Process Explorer expects a correct implementation concerning WinVerifyTrust? When it calls WinVerifyTrust and we return ERROR_SUCCESS, what does it do with that information that causes the application to fail? Even if we took the time to implement WinVerifyTrust, we would still return ERROR_SUCCESS and the situation wouldn't be any different. In the meantime, several installers are hanging up because of this. -- James Hawkins
Re: wintrust: Always return ERROR_SUCCESS in WinVerifyTrust [RESEND]
On Mon, 2006-08-07 at 11:44 -0700, James Hawkins wrote: On 8/7/06, Paul Vriens [EMAIL PROTECTED] wrote: When I run process explorer without tracing/debugging everything is fine. As soon as I add +wintrust,+heap it fails again. There is most likely some heap corruption somewhere (couldn't be more vague). Alexandre's patch to add more free list entries only masked the problem, as far as I can see from the results. Cheers and sorry for the misleading remarks, Can you explain your comment, Process Explorer expects a correct implementation concerning WinVerifyTrust? When it calls WinVerifyTrust and we return ERROR_SUCCESS, what does it do with that information that causes the application to fail? Even if we took the time to implement WinVerifyTrust, we would still return ERROR_SUCCESS and the situation wouldn't be any different. In the meantime, several installers are hanging up because of this. It just turned out (and that makes sense of course) that when returning a real error Process Explorer uses a different code path. The calls PE uses are: CryptCATAdminAcquireContext (stubbed) CryptCATAdminCalcHashFromFileHandle (stubbed) CryptCATAdminReleaseContext (stubbed) and then WinVerifyTrust (stubbed as well). Before Alexandre's patch it always failed when returning ERROR_SUCCESS, now it only fails when extra debugging is added. I have no clue (yet) where the heap corruption comes from. I can live btw with a default of ERROR_SUCCESS as that will work (100% ?) when run as an ordinary user. There is however something fishy going on. Cheers, Paul.
Re: HAL and Copy Protection
On 8/7/06, Marcus Meissner [EMAIL PROTECTED] wrote: HAL should be of no importance here, there will be no visible difference to static CDROM configuration. Otherwise, no clue. Ciao, Marcus I just remembered that these new distros with HAL also have GCC 4.xx. I remember that it has been traced to be a cause of a problem with copy protection before when using wine compiled with it. You could be right that HAL has nothing to do it. I will check it all out when I get that version of GCC running too. Jesse
Re: dinput [Get|Set]CursorPos conandrum
Vitaliy Margolen [EMAIL PROTECTED] writes: Current dinput has lots of problems with lots of games for number of different reasons (and I'm talking about just mouse). To fix some(all) of them we need to move managing of mouse warping to x11drv - only it has enough information about what programs doing to the cursor. And to make it work all we really need is to make GetCursorPos returned cached cursor position and not the latest from X. GetCursorPos really needs to query X, because there's no guarantee that the app is processing X events, and even if we hack around that we won't receive events from other processes anyway. Now it probably doesn't need to update cursor_pos asynchronously, we could wait for the X events to do that; but I'm not sure if that would help with your problem. -- Alexandre Julliard [EMAIL PROTECTED]
Re: RFC: XEmbed Systray Patches
On Mon, 2006-08-07 at 18:02 +0100, Mike Hearn wrote: On Sun, 06 Aug 2006 20:10:19 -0700, James Liggett wrote: so I suspect that this has something to do with stack problem More likely it's a speed issue - logging slows the code down a lot which could fix a race condition. X is sort of susceptible to this kind of thing it seems. Interesting thought...I knew that logging could slow down code, but I didn't think it could slow it down so much that it actually allowed the icon to dock. When I last tried working with these, I don't recall the trace working to solve this problem (I could be wrong though) Nonetheless, these patches seem to work better than the last ones, but I don't really understand why that is.
Re: RFC: XEmbed Systray Patches
On Mon, 2006-08-07 at 18:02 +0100, Mike Hearn wrote: On Sun, 06 Aug 2006 20:10:19 -0700, James Liggett wrote: so I suspect that this has something to do with stack problem More likely it's a speed issue - logging slows the code down a lot which could fix a race condition. X is sort of susceptible to this kind of thing it seems. Turns out you're right, Mike. If I add a small (2 ms) sleep after the dock event is sent, things work perfectly. :) But, this really strikes me as a hack that doesn't stand a chance of getting into Wine. Is there a better way to slow down the execution of this code. Thanks.
Wide-string Functions: Double Casting
Although I accept that my opinion may not be universally shared :-), I
believe that it is better to turn -Wcast-qual on permanently and
double-cast the appropriate return values of the relevant wide-string
functions (strchrW(), strrchrW(), strpbrkW(), memchrW() and memrchrW())
than to leave it normally turned off: that way, the developers can avoid
violations as they go, and give the janitors a break ;-). These functions
are ubiquitous and widely understood, and they account for the vast
majority of cast-qual warnings.
Because, as I understand it, we are aiming for C89 compatibility, and to try
to maximise portability, I am proposing to use size_t, rather than
uintptr_t (which is a C99 type): it seems like the next-best thing. So I
would like to submit a patch that, for example, changes strchrW() to:
extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch )
{
WCHAR *ret = NULL;
do { if (*str == ch) ret = (WCHAR *)(size_t)str; } while (*str++);
return ret;
}
What do people think? Should I just send in the patch and see what criticism
it engenders? Does anyone have a system on which this would fail or
generate other warnings in place of the cast-qual one?
Needless to say, I hope to be tackling the cast-qual janitorial task, soon;
hence, my sudden interest in this.
Thanks,
-- Andy.
Re: Wide-string Functions: Double Casting
Andrew Talbot wrote: [...] So I would like to submit a patch that, for example, changes strchrW() to: extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch ) [...] Yes, that was a typo: it should say changes strrchrW() -- Andy.
Re: Wide-string Functions: Double Casting
On Mon, Aug 07, 2006 at 09:54:20PM +0100, Andrew Talbot wrote:
would like to submit a patch that, for example, changes strchrW() to:
extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch )
{
WCHAR *ret = NULL;
do { if (*str == ch) ret = (WCHAR *)(size_t)str; } while (*str++);
return ret;
}
why not just have:
extern inline void *__deconst(const void *v)
{
return (char *)0 + ((const char *)v - (const char *)0));
}
Then the code above could be:
extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch )
{
do { if (*str == ch) return __deconst(str); } while (*str++);
return 0;
}
David
--
David Laight: [EMAIL PROTECTED]
Re: Wide-string Functions: Double Casting
David Laight wrote:
On Mon, Aug 07, 2006 at 09:54:20PM +0100, Andrew Talbot wrote:
would like to submit a patch that, for example, changes strchrW() to:
extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch )
{
WCHAR *ret = NULL;
do { if (*str == ch) ret = (WCHAR *)(size_t)str; } while (*str++);
return ret;
}
why not just have:
extern inline void *__deconst(const void *v)
{
return (char *)0 + ((const char *)v - (const char *)0));
}
Then the code above could be:
extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch )
{
do { if (*str == ch) return __deconst(str); } while (*str++);
return 0;
}
David
That's interesting. IMHO, it's a bit more complex and obscure, but seems to
ensure portability. I shall be interested to know what others think.
Thanks,
-- Andy.
Re: wined3d: stub out remaining renderstates
Am Dienstag 08 August 2006 00:06 schrieb Jan Zerebecki: If this patch is rejected from inclusion, please tell me why, as i would have to ask anyway. It looks like you forgot d3d7 render states like TEXTUREMAPBLEND. This state isn't really important for this patch, I will send an implementation for it tomorrow, but other d3d7 render states are perhaps needed. pgpQRjL0gepL6.pgp Description: PGP signature
Re: winebrowser and multi-word commands
Hello,
Ok, so I realized that winebrowser is an actual program, not a script.
I fixed the bug, but I'm sending the patch here first so somebody can
look over it because I've never written more than a couple lines of C
before.
This patch allows commands with up to 4 arguments, such as kfmclient
exec to be used for winebrowser:
diff --git a/programs/winebrowser/main.c b/programs/winebrowser/main.c
index 690f931..600d06b 100644
--- a/programs/winebrowser/main.c
+++ b/programs/winebrowser/main.c
@@ -51,20 +51,39 @@ typedef LPSTR (*wine_get_unix_file_name_
/* try to launch an app from a comma separated string of app names */
static int launch_app( char *candidates, const char *argv1 )
{
-char *app;
-const char *argv_new[3];
+char *app, *appname;
+const char *argv_new[6];
+int i1 = 0, i2 = 0, i3 = 0, len = 0;
app = strtok( candidates, , );
while (app)
{
-argv_new[0] = app;
-argv_new[1] = argv1;
-argv_new[2] = NULL;
+i2 = 0;
+i3 = 0;
+len = strlen(app);
+appname = (char *)malloc(len);
+for(i1 = 0; i1 len i3 4; i1++)
+{
+appname[i1] = app[i1];
+if (app[i1] == ' ')
+{
+app[i1] = '\0';
+argv_new[i3] = app + i2;
+i3++;
+i2 = i1 + 1;
+}
+}
+
+appname[i1] = '\0';
+argv_new[i3] = app+i2;
+argv_new[i3+1] = argv1;
+argv_new[i3+2] = NULL;
-fprintf( stderr, Considering: %s\n, app );
+fprintf( stderr, Considering: %s\n, appname );
fprintf( stderr, argv[1]: %s\n, argv1 );
spawnvp( _P_OVERLAY, app, argv_new ); /* only returns on error */
+free(appname);
app = strtok( NULL, , ); /* grab the next app */
}
fprintf( stderr, winebrowser: could not find a suitable app to run\n );
On 8/2/06, Yuriy [EMAIL PROTECTED] wrote:
Hi,
I noticed that winebrowser doesn't work with browsers/commands that
are more than one word. For example, the command to run konqueror
with the webbrowsing profile on kubuntu is:
kfmclient openProfile webbrowsing [url]
Setting that to be the first attempted webbrowser in the registry:
[HKEY_USERS\S-1-5-4\Software\Wine\WineBrowser]
Browsers=kfmclient openProfile
webbrowsing,konqueror,firefox,mozilla,netscape,galeon,opera,dillo
and running:
winebrowser http://www.winehq.org
yields this:
Considering: kfmclient openProfile webbrowsing
argv[1]: http://www.winehq.org
Considering: firefox
argv[1]: http://www.winehq.org
then it opens up with firefox.
Is this a bug? Would it just be a matter of modifying the winebrowser
script to fix?
~Yuriy
Re: HAL and Copy Protection
Ok, I just verified that HAL works perfectly fine for what we want. In fact, it does make thing easier for people as you don't have to mess with those device symlinks :) I don't suspect anything wrong with GCC 4.xx now, as I think the ubuntu package is compiled with 4.0.3. I think the report on that may have been a very early version 4 or a buggy distro. However, since I encountered no trouble, I don't know what's wrong with at least with one person's ubuntu... Jesse
