Exception but not when running with +relay
Hi, I just tried the latest PE Explorer (http://www.heaventools.com/download-pe-explorer.htm). When I stopped the application I ran into an exception within NtSetInformationThread. If I however do a +relay I don't get into this exception. What does such a difference point to? -- Cheers, Paul.
Re: alsa->pulseaudio->alsa directsound hang
On 10/31/07, Maarten Lankhorst <[EMAIL PROTECTED]> wrote: > Hi Al, > > Al Tobey schreef: > > I spent some time this evening playing around with trying to get wine > > sound output to go through pulseaudio on my fc8/rawhide (x86_64) box. > > I tried wine 0.9.43 (built), 0.9.47 (fc8 rpm), and Crossover 6.2.0. > > I was testing with Steam/TF2, but found that the same issue comes up > > with a install of Winamp Lite using its default DirectSound output > > plugin.If I configure nothing and let wine grab the soundcard (I > > have an Audigy, so it allows multiple streams), it works fine.If I > > configure it to use pulseaudio through the alsa plugin, it hangs. > > > Why would you do 'alsa -> pulseaudio -> alsa'? I'm not surprised it > wouldn't work. It is more likely a problem with the audio system then > with wine, however if you do WINEDEBUG=+wave,+tid,+dsalsa you have a > chance of tracking it down yourself. I'm just trying it out as it seems to be the recommended way of mixing native alsa apps through pulseaudio. It works fine for all the other alsa apps I tried. I'll try the debug stuff out this weekend and see if I can track anything down. Thanks for providing the right flags to start with. It would be really neat to have all my audio piped through one mixer with all of PA's features. -Al
valgrind results online
I've posted results from running the entire conformance test suit under Valgrind at http://kegel.com/wine/valgrind/20071001/ There are 100 files there; one for each test that had warnings. (And one more file with everything concatenated together, http://kegel.com/wine/valgrind/20071001/vg-all.txt) A lot of the warnings are probably just problems in our conformance tests, not in Wine, and several of the warnings might be problems in Valgrind. But I wouldn't be surprised if there were several dozen real problems in Wine, so please take a look. (Juan has already submitted a bunch of cleanups for crypt32. I'll probably run these tests daily for a while and upload the results to a new directory for each day.) I've also updated the instructions on how to run tests under Valgrind, http://wiki.winehq.org/Wine_and_Valgrind and updated the Wine patch there to include a bunch more suppressions. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Dead code in dlls/ntdll/tape.c
Gerald Pfeifer wrote:
> We currently have the following code in tape.c:
>
> if (data->Offset.u.LowPart >= 0) {
> cmd.mt_op = MTFSF;
> cmd.mt_count = data->Offset.u.LowPart;
> }
> else {
> cmd.mt_op = MTBSF;
> cmd.mt_count = -data->Offset.u.LowPart;
> }
>
> data is of type TAPE_SET_POSITION*, which in turn is defined as
>
> typedef struct _TAPE_SET_POSITION {
> ULONG Method;
> ULONG Partition;
> LARGE_INTEGER Offset;
> BOOLEAN Immediate;
> } TAPE_SET_POSITION, *PTAPE_SET_POSITION;
>
> Offset is of type LARGE_INTEGER which is defined as
>
> struct {
> DWORDLowPart;
> LONG HighPart;
> } u;
>
> Note how LowPart is unsigned (DWORD) here, so indeed the comparisons
> for >= 0 is always going to evaluate to true.
>
> Hans, I believe you originally wrote that code. Do you remember what
> you where trying to do here?
>
> The patch below removes this dead code and is equivalent to what we
> currently have. I am not sure it is the desired way to fix what I
> describe above, though.
>
The LARGE_INTEGER type without #ifdefs for clarity:
typedef union _LARGE_INTEGER {
struct {
DWORDLowPart;
LONG HighPart;
} u;
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
The type is meant to be wrap a signed integer, but the compiler
legitimately flagged that it isn't in the way that it is being accessed
currently. Therefore, I believe the code should be changed to this:
> if (data->Offset.QuadPart >= 0) {
> cmd.mt_op = MTFSF;
> cmd.mt_count = (int)data->Offset.QuadPart;
> }
> else {
> cmd.mt_op = MTBSF;
> cmd.mt_count = -(int)data->Offset.QuadPart;
> }
--
Rob Shearman
Re: Dead code in dlls/ntdll/tape.c
On Thursday 01 November 2007 21:22:14 Gerald Pfeifer wrote:
> We currently have the following code in tape.c:
>
> if (data->Offset.u.LowPart >= 0) {
> cmd.mt_op = MTFSF;
> cmd.mt_count = data->Offset.u.LowPart;
> }
> else {
> cmd.mt_op = MTBSF;
> cmd.mt_count = -data->Offset.u.LowPart;
> }
> Offset is of type LARGE_INTEGER which is defined as
>
> struct {
> DWORDLowPart;
> LONG HighPart;
> } u;
>
> Note how LowPart is unsigned (DWORD) here, so indeed the comparisons
> for >= 0 is always going to evaluate to true.
Yes, the comparison should be against data->Offset.QuadPart (which you
left out of the definition of LARGE_INTEGER).
I'll work on a fix.
-Hans
Dead code in dlls/ntdll/tape.c
We currently have the following code in tape.c:
if (data->Offset.u.LowPart >= 0) {
cmd.mt_op = MTFSF;
cmd.mt_count = data->Offset.u.LowPart;
}
else {
cmd.mt_op = MTBSF;
cmd.mt_count = -data->Offset.u.LowPart;
}
data is of type TAPE_SET_POSITION*, which in turn is defined as
typedef struct _TAPE_SET_POSITION {
ULONG Method;
ULONG Partition;
LARGE_INTEGER Offset;
BOOLEAN Immediate;
} TAPE_SET_POSITION, *PTAPE_SET_POSITION;
Offset is of type LARGE_INTEGER which is defined as
struct {
DWORDLowPart;
LONG HighPart;
} u;
Note how LowPart is unsigned (DWORD) here, so indeed the comparisons
for >= 0 is always going to evaluate to true.
Hans, I believe you originally wrote that code. Do you remember what
you where trying to do here?
The patch below removes this dead code and is equivalent to what we
currently have. I am not sure it is the desired way to fix what I
describe above, though.
Gerald
Index: dlls/ntdll/tape.c
===
RCS file: /home/wine/wine/dlls/ntdll/tape.c,v
retrieving revision 1.16
diff -u -3 -p -r1.16 tape.c
--- dlls/ntdll/tape.c 26 Jun 2007 12:14:34 - 1.16
+++ dlls/ntdll/tape.c 1 Nov 2007 16:32:29 -
@@ -427,25 +427,13 @@ static NTSTATUS TAPE_SetPosition( int fd
break;
#endif
case TAPE_SPACE_FILEMARKS:
-if (data->Offset.u.LowPart >= 0) {
-cmd.mt_op = MTFSF;
-cmd.mt_count = data->Offset.u.LowPart;
-}
-else {
-cmd.mt_op = MTBSF;
-cmd.mt_count = -data->Offset.u.LowPart;
-}
+cmd.mt_op = MTFSF;
+cmd.mt_count = data->Offset.u.LowPart;
break;
#if defined(MTFSS) && defined(MTBSS)
case TAPE_SPACE_SETMARKS:
-if (data->Offset.u.LowPart >= 0) {
-cmd.mt_op = MTFSS;
-cmd.mt_count = data->Offset.u.LowPart;
-}
-else {
-cmd.mt_op = MTBSS;
-cmd.mt_count = -data->Offset.u.LowPart;
-}
+cmd.mt_op = MTFSS;
+cmd.mt_count = data->Offset.u.LowPart;
break;
#endif
case TAPE_LOGICAL_BLOCK:
Re: mshtml: Set IE version when installing wine gecko
Jacek Caban <[EMAIL PROTECTED]> writes: > But currently, if you use the new installing way (from hard drive), > Gecko installs during wineprefixcreate if user has it set up correctly. > It means that some users will have always set IE version, others won't. > It's definitely not what we want. We may consider reverting installing > Gecko from DllRegisterServer to make it at least the same for all. The idea would be that there should be an easy way to uninstall it, so if Gecko is installed the app will try to use that, and if it doesn't work we can tell users to uninstall Gecko and let the app install IE instead. Ultimately of course the goal is that they never need to do that. -- Alexandre Julliard [EMAIL PROTECTED]
Re: mshtml: Set IE version when installing wine gecko
On Thursday 01 November 2007 12:40:25 pm Jacek Caban wrote: > The real solution is to always set IE version. To do it we have to fix > apps that block it. The problem, apart from that I didn't have time to > make bug hunting on them yet, is that we don't really have a list of > such apps. Quicken is the main example, but who knows what are the > others? It would be great if we had it somewhere in bugzilla or wiki. Even if you fix all the apps that have a problem with Gecko, native IE still has rendering differences. And short of reimplementing it ourselves, some people will have a need for native IE (eg. web developers wanting to see what their site looks like in IE). There may even be some other behavioral differences that the majority of people won't care about or even not prefer, while others do.
Re: Wine Gecko packaging
Boaz Harrosh wrote: > Do you have a magic param to download the latest one available? > something like: winegecko.php?v=latest > No, we don't have, but it sounds like a good idea. It's easy to add. Jacek
Re: mshtml: Set IE version when installing wine gecko
Chris Robinson wrote: > Actually, Alexendre agreed to the patch *because* it sets the version when > Gecko is installed. This allows people to still install native IE if they > wish, and allows apps that need native IE to be able to have it, by > installing IE before Gecko. Alexendre wasn't willing to have the version > always set because some apps may need native IE, and because some people may > want native IE. > > However, setting the version when installing Gecko allows apps that need to > detect IE by its version, to be able to do so. > But currently, if you use the new installing way (from hard drive), Gecko installs during wineprefixcreate if user has it set up correctly. It means that some users will have always set IE version, others won't. It's definitely not what we want. We may consider reverting installing Gecko from DllRegisterServer to make it at least the same for all. The real solution is to always set IE version. To do it we have to fix apps that block it. The problem, apart from that I didn't have time to make bug hunting on them yet, is that we don't really have a list of such apps. Quicken is the main example, but who knows what are the others? It would be great if we had it somewhere in bugzilla or wiki. Jacek
Re: mshtml: Set IE version when installing wine gecko
On Thursday 01 November 2007 10:47:36 am Jacek Caban wrote: > Hi Chris, > > This patch is already committed, but, I'm afraid, it's wrong. Setting > these registries has nothing to do with installing Gecko. Setting them > in Gecko installer will only make supporting it harder. We don't want to > tell user to "run iexplore about:blank" to get an app working. Actually, Alexendre agreed to the patch *because* it sets the version when Gecko is installed. This allows people to still install native IE if they wish, and allows apps that need native IE to be able to have it, by installing IE before Gecko. Alexendre wasn't willing to have the version always set because some apps may need native IE, and because some people may want native IE. However, setting the version when installing Gecko allows apps that need to detect IE by its version, to be able to do so.
Re: iexplore proxy server
Luke Bratch wrote: > Hello > > Is there supposed to be a way to set a HTTP (or > otherwise) proxy server in Wine's iexplore at the > moment? > > I can't find any such documentation, but searching > around has found a lot of people suggesting that > setting these keys will help: > > [Software\\Microsoft\\Windows\\CurrentVersion\\Internet > Settings] > "ProxyEnable"=dword:0001 > "ProxyServer"="proxyserver:8080" > > Setting those didn't make any difference in iexplore, > but the attached patch which edits a file that the > Gecko installer creates, makes HTTP proxy support work > perfectly. > > Is this the correct/only way to do this? > > There are two ways. First is to set these Gecko settings at runtime, depending on IE settings. The right way would be to use wininet to handle http/https/ftp connections. It's something we have to do sooner or later and, while fixing other bugs, we are slowly getting to that state. This is one of many problems that will be solved by it. Jacek
Re: mshtml: Set IE version when installing wine gecko
Hi Chris, This patch is already committed, but, I'm afraid, it's wrong. Setting these registries has nothing to do with installing Gecko. Setting them in Gecko installer will only make supporting it harder. We don't want to tell user to "run iexplore about:blank" to get an app working. I will send a better patch that always sets them. Last time Alexandre didn't accept such a patch, because of apps that need native IE and install it only when this key is not found. It looks like it's time for such change. Thanks, Jacek
Re: Cleanup of riched20 tests - request for help on test_WM_PASTE
Alex Villacís Lasso escribió:
> I am currently trying to clean up the riched20 tests that are failing in
> WinXP. While doing this, I have encountered the following problem: on
> the function test_WM_PASTE() (at line 1959 of
> dlls/riched20/tests/editor.c in current git), the test is supposed to
> feed simulated keystrokes corresponding to Ctrl-C, Ctrl-V, and so on,
> supposedly to test copy and paste features via the keyboard. The problem
> is that the verification at line 1989 fails on WinXP, because the text
> on the control has not been modified - the control seems to disregard
> simulated WM_CHAR messages of the Ctrl- variety. The test at
> line 1977 succeeds accidentally, because the sequence of Ctrl-C, Ctrl-V,
> Ctrl-Z that is being tested is equivalent to not modifying the control
> text at all.
>
> A more through test would be to send WM_GETTEXT messages after each step
> to ensure that the text is actually being modified, but the bigger
> problem is how to make the control obey the keystrokes in the first
> place. If I place a message loop right before the DestroyWindow() call,
> I can send keystrokes manually and they work as expected. Only simulated
> WM_CHAR messages are being discarded.
>
> I have tried changing the SendMessage() calls into PostMessage() calls
> (since Visual Studio's Spy++ shows that WM_CHAR messages were posted,
> not sent), but to no avail. I have also tried placing message loops
> between messages, with no luck. I have even tried to simulate the
> WM_KEYDOWN and WM_KEYUP messages with parameters exactly as seen by
> Spy++, but this does not work either. So I am asking for help. What
> could be going wrong with this test? How can I feed the expected
> keystrokes so that the test works as expected? Has this test ever worked
> before? It fails in both WinXP (real machine) and inside a QEMU session
> running Win98.
>
> (All tests on WinXP were compiled with CygWin)
>
>
Any thoughts on this? Do I need to supply more information in order to
diagnose the problem?
--
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'
Re: Make test drill, next steps, call for help with Winetest
Francois Gouget wrote: > On Sat, 27 Oct 2007, Francois Gouget wrote: > In fact I've been able to verify that it works in real life since > winetest has not been updated since last monday :-( > Compilation problems? Yeah, I guess due to the new d3dx8 tests. Have a look at http://quisquiliae.physics.gla.ac.uk/crossbuild-logs/ for more details. -- Cheers, Paul.
Re: Make test drill, next steps, call for help with Winetest
On Sat, 27 Oct 2007, Francois Gouget wrote:
[...]
> There are other options to specify which version of winetest.exe to
> grab, to set the timeout on the tests execution, etc.
>
> Things still on the todo list:
> * the script also grabs the winetest.exe signature and attempts to
> verify it. But I don't know where to find the corresponding public key
> (651FD487) so I don't know if this really works.
Hmm, as pointed out by Detlef, there a link on Paul's home page pointing
to his public key and the required key is in there. Then it's just a
matter of telling gpg to use it which I have now done and the signature
checking code seems to work as intended.
> * the script gets the 'latest' winetest.exe version by default, but
> when there are compilation problems I guess this may stay stuck at the
> same revision for some time. So it would be nice if the script could
> know which version it's getting so it could skip the tests if that
> version is too old, or has already been tested.
The script can now use a local cache containing the already downloaded
files, and can be told to skip the tests if it finds that a file has not
changed since the last time it has been used in a given vm+snapshot
combination.
In fact I've been able to verify that it works in real life since
winetest has not been updated since last monday :-(
Compilation problems?
I've attached the latest version of the script.
--
Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/
Hiroshima '45 - Czernobyl '86 - Windows '95#!/bin/sh
# Copyright (C) 2007 Francois Gouget
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
name0=`basename "$0"`
verbose=""
base_url="http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt";
vmware="/usr/local/opt/vmware/bin"
if [ -z "$DISPLAY" ]
then
DISPLAY=":0.0"
export DISPLAY
fi
verbose()
{
if [ -n "$verbose" ]
then
echo "$@"
fi
}
vm_is_busy()
{
vm="$1"
test -f "$vm.WRITELOCK"
return $?
}
vm_is_running()
{
# For VM matching purposes, only keep the last two elements of the path
# to avoid trouble with symbolic links
vm_match=`dirname "$opt_vm"`
vm_match=`basename "$vm_match"`/`basename "$opt_vm"`
vm_match=`echo "$vm_match" | sed -e 's/\([^a-zA-Z0-9_ /]\)/[\1]/g'`
"$vmware/vmrun" list | egrep "$vm_match" >/dev/null
return $?
}
cached_wget()
{
url="$1"
dst="$2"
cache="$3"
if [ -n "$cache" ]
then
filename=`basename "$url"`
(
cd "$cache" &&
wget -N "$url" &&
cp -pr "$filename" "$dst"
)
else
wget -O "$dst" "$url"
fi
}
### Main
opt_vm=""
opt_tag_prefix=""
opt_tag=""
opt_cache=""
opt_version=""
opt_check_sig=""
opt_submit=""
opt_timeout=""
opt_autorun=""
opt_snapshot=""
opt_cddevice=""
opt_usage=""
while [ $# -gt 0 ]
do
arg="$1"
shift
case "$arg" in
--tag-prefix)
if [ -n "$opt_tag_prefix" ]
then
echo "$name0:error: --tag-prefix can only be used once" >&2
opt_usage="2"
break
elif [ $# -eq 0 ]
then
echo "$name0:error: missing argument for the --tag-prefix option"
>&2
opt_usage="2"
break
else
opt_tag_prefix="$1"
shift
fi
;;
--tag)
if [ -n "$opt_tag" ]
then
echo "$name0:error: --tag can only be used once" >&2
opt_usage="2"
break
elif [ $# -eq 0 ]
then
echo "$name0:error: missing argument for the --tag option" >&2
opt_usage="2"
break
else
opt_tag="$1"
shift
fi
;;
--cache)
if [ -n "$opt_cache" ]
then
echo "$name0:error: --cache can only be used once" >&2
opt_usage="2"
break
elif [ $# -eq 0 ]
then
echo "$name0:error: missing argument for the --cache option" >&2
opt_usage="2"
break
else
opt_cache="$1"
shift
fi
;;
--skip-old)
opt_skip_old="1"
;;
--no-skip-old)
opt_skip_old="0"
;;
--version)
if [ -n "$opt_version" ]
then
echo "$name0:error: --ver
Re: [Bug 10266] Numpad keyboard handling is strange, Del keyproduces two events
"Peter Åstrand" <[EMAIL PROTECTED]> wrote: > 1) "Not consistent" > > It might be interesting to compare with CapsLock. Shift can cancel > CapsLock, but also substitute it. This is true on both Windows and Linux. > Additionally, on Linux, NumLock works the same, ie Shift works in both > directions. On Windows, however, Shift can only cancel NumLock, not > substitute it. Regardless of whether users actually finds this useful or > not, I think it's hard to argue for that this is "logical" or > "consistent". Current behaviour emulates what ToUnicodeEx does under Windows. And some apps depend on it. > 2) "Annoying" > > Can it be that you have a Windows background and are therefore used to the > Windows behaviour? When NumLock is off arrow kys on numpad should behave like normal arrow keys IMO. Perhaps you have an idea how to use keypad with NumLock turned off to move cursor, and to select text when needed with Shift just like arrow keys do? > > Besides, I just tested with Wine's notepad and don't see the problem you > > are reporting. > > Which keyboard layout are you using? On my system, Wine selects the > Swedish keyboard layout. I'm using us keyboard layout. -- Dmitry.
iexplore proxy server
Hello Is there supposed to be a way to set a HTTP (or otherwise) proxy server in Wine's iexplore at the moment? I can't find any such documentation, but searching around has found a lot of people suggesting that setting these keys will help: [Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings] "ProxyEnable"=dword:0001 "ProxyServer"="proxyserver:8080" Setting those didn't make any difference in iexplore, but the attached patch which edits a file that the Gecko installer creates, makes HTTP proxy support work perfectly. Is this the correct/only way to do this? Thanks Luke Bratch ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ proxy.patch Description: 843534684-proxy.patch
Re: [Bug 10266] Numpad keyboard handling is strange, Del key produces two events
Perhaps we need to gather more input from other developers: > http://bugs.winehq.org/show_bug.cgi?id=10266 > > --- Comment #4 from Dmitry Timoshkov <[EMAIL PROTECTED]> 2007-11-01 08:32:46 > --- > > But in that case, you will find all of your X11 applications on your > > desktop, > > including Firefox etc, confusing as well? > > Yes, and this behaviour is very annoying and not consistent IMO. Let's break down this statement into two: 1) "Not consistent" It might be interesting to compare with CapsLock. Shift can cancel CapsLock, but also substitute it. This is true on both Windows and Linux. Additionally, on Linux, NumLock works the same, ie Shift works in both directions. On Windows, however, Shift can only cancel NumLock, not substitute it. Regardless of whether users actually finds this useful or not, I think it's hard to argue for that this is "logical" or "consistent". 2) "Annoying" Can it be that you have a Windows background and are therefore used to the Windows behaviour? I haven't actually asked any users yet, but my general opinion is that all applications on the same desktop should behave the same, if possible. We are decorating the Windows windows with the normal window manager decorations etc so I think it's reasonable that the keyboard should behave according to the native system model. Another thing to keep in mind is that most users actually never use the numpad keys in conjunction with Shift. I know this from several years of experience of keyboard hacking - there have been plenty of bugs in many softwares in this area but very few actual bug reports. > Besides, I just tested with Wine's notepad and don't see the problem you > are reporting. Which keyboard layout are you using? On my system, Wine selects the Swedish keyboard layout. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter
Re: Bug in dlls/oleaut32/tests/vartype.c?
[ Updated patch at the end, Alexandre. ]
On Mon, 29 Oct 2007, Alex Villacís Lasso wrote:
> Sorry to object, but which version of exactly which compiler optimizes
> away the negative sign?
You're right, I misread this, sorry. My original patch wasn't wrong,
but the explanation was, and there seems in fact a better patch.
> Consider the following program:
That's a very fair test, and I enhanced it as follows:
#include
#include
void print(const float f) {
union x {
float f;
unsigned char b[4];
} u;
u.f = f;
printf("Value as float is %f\n", u.f);
printf("as bytes %02x %02x %02x %02x\n\n",u.b[0],u.b[1],u.b[2],u.b[3]);
}
int main() {
print(-1e-400);
print(-0.0);
}
Both GCC 3.4 and GCC 4.2 snapshot give 00 00 00 80 in both cases. (All
the original warning referred to actually did was to indicate that the
compiler actually made this change automatically; that was added with
GCC 4.3 it seems.)
Gerald
ChangeLog:
Use -0.0 directly in test_VarBstrFromR4().
Index: vartype.c
===
RCS file: /home/wine/wine/dlls/oleaut32/tests/vartype.c,v
retrieving revision 1.51
diff -u -3 -p -r1.51 vartype.c
--- vartype.c 20 Aug 2007 12:43:49 - 1.51
+++ vartype.c 1 Nov 2007 13:42:48 -
@@ -4747,7 +4747,7 @@ static void test_VarBstrFromR4(void)
}
}
- f = -1e-400;/* deliberately cause underflow */
+ f = -0.0;
hres = pVarBstrFromR4(f, lcid, 0, &bstr);
ok(hres == S_OK, "got hres 0x%08x\n", hres);
if (bstr)
Re: setupapi: Add stub for SetupInstallServicesFromInfSectionW
On 01.11.2007 14:26, Robert Shearman wrote: > There's no need to move the entry for > SetupInstallServicesFromInfSectionW. The list was sorted alphabetically, > but now it isn't. Unless you ignore the A/W suffix. One could argue that this is more intuitive as you could locate an entry in the list by searching for the undecorated name and then look for the one with the appropriate suffix, which is at most one line away. If you sort strictly alphabetically, A/W variants may be a couple of lines away (e.g. FooA/FooExA/FooExW/FooW) which could make finding the right variant slightly counterintuitive. -f.r.
Re: setupapi: Add stub for SetupInstallServicesFromInfSectionW
Chris Robinson wrote: > @ stdcall SetupInstallFromInfSectionA(long long str long long str long ptr > ptr long ptr) > @ stdcall SetupInstallFromInfSectionW(long long wstr long long wstr long ptr > ptr long ptr) > @ stdcall SetupInstallServicesFromInfSectionA(long str long) > +@ stdcall SetupInstallServicesFromInfSectionW(long wstr long) > @ stub SetupInstallServicesFromInfSectionExA > @ stub SetupInstallServicesFromInfSectionExW > -@ stub SetupInstallServicesFromInfSectionW > @ stdcall SetupIterateCabinetA(str long ptr ptr) > @ stdcall SetupIterateCabinetW(wstr long ptr ptr) > @ stub SetupLogErrorA > There's no need to move the entry for SetupInstallServicesFromInfSectionW. The list was sorted alphabetically, but now it isn't. -- Rob Shearman
Re: New DLL, Server and Service Documentation
Am Donnerstag, 1. November 2007 08:00:36 schrieb Roy Shea: > Howdy All, > > This autumn I began learning both Wine and COM. A > combination of limited documentation and trouble finding the > right example code for my task at hand made this a difficult > process. In an attempt to help other new Wine and COM > developers I wrote a tutorial on COM development the Wine > way. This tutorial describes: > This should propably be linked from the wiki. Which would be the right place for that? signature.asc Description: This is a digitally signed message part.
Re: wined3d: Enable clip planes with GLSL shader backend
Am Donnerstag, 1. November 2007 02:01:14 schrieb Ivan Gyurdiev: > > +if (use_vs(stateblock->wineD3DDevice) && > > stateblock->wineD3DDevice->vs_selected_mode == SHADER_ARB) > > GLSL specific logic should go in glsl_shader.c. > > Please try to get away from writing code in terms of flags and if > statements - use the OOP model. > Backend-specific logic should be removed from pixelshader and > vertexshader too... We've had this discussion over and over, but I'm not too fond of pressing everything into an OOP model by force. I agree it is useful in general, and I'm currently working on making the surface type organisation more OOPish. However, in this special case the state management collides with shader differences. Adding a shader model callback for every of those cases doesn't make the code more readable IMHO. I agree that the backend specific code in GenerateShader in vertexshader.c / pixelshader.c should be moved to arb / glsl backends. Then we'd get vertex and pixel shader specifics into arb / glsl, but we can't avoid those anyway. signature.asc Description: This is a digitally signed message part.
Re: Wine Gecko packaging
- Original Message - *From:* Jacek Caban <[EMAIL PROTECTED]> *To:* Dmitry Timoshkov <[EMAIL PROTECTED]> *CC:* wine-devel@winehq.org *Sent:* Wed, Oct 31 2007 at 21:20 +0200 *Subject:* Wine Gecko packaging > Hi Dmitry, > > Dmitry Timoshkov wrote: > >> http://source.winehq.org/winegecko.php still points to an old Gecko >> package >> (0.0.1). Please update it. >> >> > > We can't change it due to compatibility with older Wine versions. We > encode Gecko version in URL instead, so > http://source.winehq.org/winegecko.php?v=0.1.0 will do what you want. > > Jacek > Do you have a magic param to download the latest one available? something like: winegecko.php?v=latest Thanks Boaz
