New DLL, Server and Service Documentation

2007-11-01 Thread 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:

- A simple DLL providing a in-process COM object
- A simple server providing a local COM object
- A simple service that publishes a COM object and the
  corresponding proxy / stub required to use the service

with instructions on Wine integration and, for Windows users
or testers building for Windows, basic instructions on
building and running these same applications in Windows.
The tutorial is available at:

http://ambleramble.org/wine/

I hope other developers enjoy this documentation.  If you
see mistakes, either minor typos or conceptual problems,
please drop me an email and I'll clean up the docs.

Peace,
-Roy







Re: Wine Gecko packaging

2007-11-01 Thread Boaz Harrosh
- 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





Re: New DLL, Server and Service Documentation

2007-11-01 Thread Stefan Dösinger
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

2007-11-01 Thread Stefan Dösinger
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: setupapi: Add stub for SetupInstallServicesFromInfSectionW

2007-11-01 Thread Robert Shearman
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: setupapi: Add stub for SetupInstallServicesFromInfSectionW

2007-11-01 Thread Frank Richter
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: Bug in dlls/oleaut32/tests/vartype.c?

2007-11-01 Thread Gerald Pfeifer
[ 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 stdio.h
   #include stdlib.h

   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: [Bug 10266] Numpad keyboard handling is strange, Del key produces two events

2007-11-01 Thread Peter Åstrand

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


iexplore proxy server

2007-11-01 Thread Luke Bratch
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 keyproduces two events

2007-11-01 Thread Dmitry Timoshkov
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. 





Re: Make test drill, next steps, call for help with Winetest

2007-11-01 Thread Francois Gouget
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: --version can only be used once 2
opt_usage=2
break
elif [ $# -eq 0 ]
then
echo $name0:error: missing 

Re: Make test drill, next steps, call for help with Winetest

2007-11-01 Thread Paul Vriens
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: Cleanup of riched20 tests - request for help on test_WM_PASTE

2007-11-01 Thread Alex Villací­s Lasso
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-keystroke 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: mshtml: Set IE version when installing wine gecko

2007-11-01 Thread Jacek Caban
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: mshtml: Set IE version when installing wine gecko

2007-11-01 Thread Chris Robinson
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: mshtml: Set IE version when installing wine gecko

2007-11-01 Thread Jacek Caban
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: Wine Gecko packaging

2007-11-01 Thread Jacek Caban
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

2007-11-01 Thread Chris Robinson
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: mshtml: Set IE version when installing wine gecko

2007-11-01 Thread Alexandre Julliard
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]




Dead code in dlls/ntdll/tape.c

2007-11-01 Thread Gerald Pfeifer
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: Dead code in dlls/ntdll/tape.c

2007-11-01 Thread Hans Leidekker
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




Re: Dead code in dlls/ntdll/tape.c

2007-11-01 Thread Robert Shearman
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





valgrind results online

2007-11-01 Thread Dan Kegel
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