Re: shell32: Reimplement a factored SHFileOperation [RESEND 2]

[Mike McCormack]

James Hawkins wrote:


Haven't received any comments yet.  Is there anything wrong with this
patch?  I know it's large, but it can't be sent in pieces.  The new
implementation passes all the tests.

Changelog:
* Reimplement a factored SHFileOperation.

 dlls/shell32/shlfileop.c   | 1131 +++-
 dlls/shell32/tests/shlfileop.c |  242 ++---


Hi James,

That's a lot of great work!

Try submit the tests first with todo_wine {} blocks around the stuff 
that fails now, then submit a further change with your main patch that 
shows with tests now pass.


That should reduce the size of your patch a little, and show how messed 
up the old implementation of SHFileOperation is.


thanks,

Mike

Winelib debugging with eclipse in fc4

[Michael Ost]

A while back I posted a question about how to get debugging working with
eclipse in fedora 4. I am having some success, so if anyone else out
there is interested here's how it is set up.

In regedit:

* disabled auto winedbg by renaming AeDebug 
I changed HKEY_LOCAL_MACHINE/Software/Microsoft/Windows
NT/Current Version/AeDebug to AeDebug-DISABLED. Without this gdb
doesn't seem to be able to get a hold of SEGFAULTs.

In eclipse's Run/Debug dialog box:

* set the c/c++ application to WINE_SRC/loader/wine-pthread
WINE_SRC points to a compiled version of wine. For me, I got the
wine src rpm and ran rpmbuild -bb. This is where main() is,
which eclipse looks for at start up.

* put your .exe.so file on the Arguments tab

* choose the GDB Debugger on the Debugger tab

* add WINE_SRC on the Source tab as a "Filesystem directory with
subdirectories"

The only weirdness so far is that sometimes (not always) the debugger
suspends when a new thread is created. I just resume (F8) past that. And
I am not sure what impact bypassing wine-preload's exec-shield
workaround will have on me. More on that if I learn more.

But I gotta say that having a functioning IDE with integrated debugging
on Linux is a major relief and, for me at least, a long time coming!

... mo

PS: I installed FC4, and then did yum update. eclipse is version 3.1.1
updated from the eclipse UI from the version that came with FC4.

Re: winecfg: Problems with audio configuration

[Detlef Riekenberg]

Am Mittwoch, den 04.01.2006, 08:19 +0100 schrieb Michael Jung:

> It fixes the problem for me. Would be nice if this could go into CVS, even if 
> it is just a hack. I guess it crashes on any Debian Sarge setup?
> 
> Your patch is missing an ntdll import. I've attached an updated version.


While reading your Patch, I remembered a comment from Alexandre:

Do not "return" in a __TRY - Block.



-- 
By By ...
  ... Detlef

Re: commit 15667b36e43a571f6bb8726b9dec4f1099d2b4f9 (_fullpath)

[Detlef Riekenberg]

Am Freitag, den 06.01.2006, 10:01 -0600 schrieb Aric Stewart:
> ChangeLog:
> Additional add a regression test for _fullpath
> 
>dlls/msvcrt/tests/dir.c |   58

+
+SetCurrentDirectory("C:\\Windows\\System\\");
+

Please do not use a fixed Path.
This will not work on many Systems:

nt351:   "c:\winnt351"
nt4.0 + w2k: "c:\winnt"
and every windows with a custom Install-Directory.

+
+ok(_fullpath(full,"test", MAX_PATH)>0,"_fullpath failed\n");
+

">0" is not correct for "char *".

The Text in your Tests are useless.
Please print error-values and received buffer-content.


-- 
By By ...
  ... Detlef

Re: winspool: Printing-Environment-Support for GetPrinterDriverDirectory

[Detlef Riekenberg]

Am Dienstag, den 03.01.2006, 00:51 +0100 schrieb Detlef Riekenberg:

What can I do with this Patch ?

> Changelog:
> - Add Function "validate_envW" to validate the user-supplied
>   Printing Environment (respect "Windows Version" - Setting)
> - Change GetPrinterDriverDirectoryW on top of "validate_envW" 
>   to Report the native Path for NT and Win9x
> - 2 Tests are now working in Wine
> 
> 
> Synced to current git-version with suggestions from Alexandre:
> Use a struct to handle the environment-specific parts
> 
> 
> "validate_envW" / printenv_t will be used by more Functions later.
> (WINSPOOL_OpenDriverReg as Example)
> 


-- 
By By ...
  ... Detlef

Re: shell32: fix folder icon index when read from registry

[Alexandre Julliard]

"Martin Fuchs" <[EMAIL PROTECTED]> writes:

> Any thing wrong with this patch?

Well, yes, you noted it yourself:

>> +DWORD dwNr; /*TODO: change to int type */

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: commctl32 datetime fields mad editable with keyboard

[Robert Shearman]

Siim Karus wrote:


@@ -962,6 +1037,33 @@
DATETIME_IncreaseField (infoPtr, fieldNum, INT_MAX);
DATETIME_SendDateTimeChangeNotify (infoPtr);
break;
+   case VK_NUMPAD0:
+   case VK_NUMPAD1:
+   case VK_NUMPAD2:
+   case VK_NUMPAD3:
+   case VK_NUMPAD4:
+   case VK_NUMPAD5:
+   case VK_NUMPAD6:
+   case VK_NUMPAD7:
+   case VK_NUMPAD8:
+   case VK_NUMPAD9:
+   DATETIME_EditField (infoPtr, fieldNum, vkCode-VK_NUMPAD0);
+   DATETIME_SendDateTimeChangeNotify (infoPtr);
+   break;
+   case (WORD)'0':
+   case (WORD)'1':
+   case (WORD)'2':
+   case (WORD)'3':
+   case (WORD)'4':
+   case (WORD)'5':
+   case (WORD)'6':
+   case (WORD)'7':
+   case (WORD)'8':
+   case (WORD)'9':
+   DATETIME_EditField (infoPtr, fieldNum, vkCode-(WORD)('0'));
+   DATETIME_SendDateTimeChangeNotify (infoPtr);
+   break;
+
case VK_LEFT:
do {
if (infoPtr->select == 0) {
 



I think this would be better done in the processing for the WM_CHAR 
message instead. Then you wouldn't have the mess of having to handle the 
numpad keys as well.


--
Rob Shearman

Re: WINE 0.9.5 and Photoshop 7 & CS

[Hiji]

> Hi,
> 
> I've found the patch that breaks the thing. GIT
> commit-ish is
> 0b17529332b0ef5ee57873afd4ded6f359e76781.
>
(http://source.winehq.org/git/?p=wine.git;a=commit;h=0b17529332b0ef5ee57873afd4ded6f359e76781).
> 
> I haven't looked at it deeply, just done some git
> bisect's.
> 
> -- 
> Elvis Pranskevichus - [EMAIL PROTECTED]

Fantastic!  Now, if somebody could fix this so we
could get Photoshop 7 running on Wine again (broken
since 0.9.3), we could close the loop on this issue.
:)

Thanks!
Hiji

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: commctl32 datetime fix for certain VC++ AppWizard generated applications

[Robert Shearman]

Siim Karus wrote:


As requested, I split my patches as I could.

This patch causes Datetime and Calendar to be registered in DllMain 
(as the tested applications never called InitCommonControls or 
InitCommonControlsEx).



I don't think this change is correct for ComCtl32 v5 or below. I am not 
sure about v6.


I am pretty sure all that are registered are the ICC_WIN95_CLASSES as 
listed on MSDN. Please check your test applications.


--
Rob Shearman

Re: daily winetest generation

[Paul Millar]

On Friday 06 Jan 2006 01:29, Saulius Krasuckas wrote:
> I may perfectly repeat someones else question, but why in the world
> winetest-200YmmDD1000-paul-mingw.exe files aren't being generated if the
> patches arrives too late during partical day?
>
> I think compiled EXEs should be released regardless of their generation
> date.  No?

The current way it works was the concensus decision a little while back.

Personally, I'd prefer building winetest.exe as part of WRT (auto regression 
testing based on CVS commits).  WRT builds winetest.exe anyway (in fact, all 
the DLLs and EXEs it can), but the results are not registered, so no one sees 
them.

However, dealing with asynchronous updates was thought both too difficult and 
not necessary so we have the synchronous once-a-day builds.  I'm maintaining 
a separate cron-triggered build process, although it still uses a fair bit of 
WRT for this.  This causes the occasional headaches, but its working pretty 
well now [*].

The winetest infrastructure was originally designed to work with once-a-day 
releases, although I'm not sure if that restriction is used within the code.  
Changing it to work with potentially more frequent releases might require no 
extra work, or a fair bit.

In favour of the status quo:  it works, its simple, you have to wait (at most) 
one day [*] and there's no need to change any of the winetest/winrash/.. 
infrastructure.

In favour of change: faster turn-around (and would make my life a bit 
simpler :^)

Cheers,

Paul.

BTW, the timing of the builds is somewhat anachronistic.  It was based on the 
time when Alexandre was over in California (IIRC), so it was a reasonable bet 
that he wasn't committing code at 10am GMT (2am PST; OK, maybe not that safe 
a bet).  These days it isn't so clear-cut (committing code at 11am EST is 
possible ;-), so perhaps the time should be revised?

[*] (this is assuming wine hasn't "broken" the cross-compilation that MinGW 
provides, that is :-)



pgpvNZOyBgjdJ.pgp
Description: PGP signature

Labels on rotated display not drawing in 0.9 release

[Phil Lodwick]

Hi,

I have a display in the portrait position.  I am using Option "Rotate" "90"
in my XF86Config-4 file.  When I rotate the screen like this, labels on
Menus, Buttons, Dialog Boxes, etc do not display until after an expose event
(eg. running a cursor over them).

I have tried Wine 0.9, Wine 0.9.4 and CrossOver 5.0.  I use winemine to test
Wine, and NotePad in the CrossOver Office distribution to test that
configuration -- all fail.

If I don't rotate OR if I revert to the 20050524 release of Wine, the problem
goes away.

Any suggestions on where to start the hunt?

Thanks,
Phil

Re: daily winetest generation

[Saulius Krasuckas]

* On Fri, 6 Jan 2006, Paul Millar wrote:
> * On Friday 06 Jan 2006 01:29, Saulius Krasuckas wrote:
> >
> > I think compiled EXEs should be released regardless of their 
> > generation date.  No?

Excuse me for my typos and logical mistakes, but..

> Personally, I'd prefer building winetest.exe as part of WRT (auto 
> regression testing based on CVS commits).  WRT builds winetest.exe 
> anyway (in fact, all the DLLs and EXEs it can), but the results are not 
> registered, so no one sees them.

I didn't got it - when do the results get not registered?  Or when it 
does?

> However, dealing with asynchronous updates was thought both too 
> difficult and not necessary so we have the synchronous once-a-day 
> builds.  I'm maintaining a separate cron-triggered build process, 

Are its results public? :)
What belongs to WRT and what does to your separate build process?

> The winetest infrastructure was originally designed to work with 
> once-a-day releases, although I'm not sure if that restriction is used 
> within the code.  Changing it to work with potentially more frequent 
> releases might require no extra work, or a fair bit.

Paul, just to note, I am perfectly fine with a per-day releases. :)

> In favour of the status quo:  it works, its simple, you have to wait (at 
> most) one day [*] and there's no need to change any of the 
> winetest/winrash/.. infrastructure.
> 
> In favour of change: faster turn-around (and would make my life a bit 
> simpler :^)

Well, I may not understand your reply correctly, but why then I see only 
1 release during 2006 year at the of the page [2]:

 [DIR] 200512271000/   06-Jan-2006 04:05-   
 [DIR] 200601061000/   06-Jan-2006 05:50-   

when WRT summary page [3] tells us there were several successful builds in 
this year already:

 Thu Jan 5 17:29:03
 Wed Jan 4 20:51:31
 Wed Jan 4 15:00:50
 Tue Jan 3 21:38:32
 Tue Jan 3 14:38:04

Has that happend due to lack of running Winrash clients during this time?  
My Winrash stayed IDLE when I had launched it several times.


[2] http://test.winehq.org/data/
[3] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php

Re: shell32: fix folder icon index when read from registry

[Martin Fuchs]

Any thing wrong with this patch?

On 31.12.2005 21:31:25 Martin Fuchs wrote:
> Changelog:
> fix folder icon index when read from registry


> Index: folders.c
> ===
> RCS file: /home/wine/wine/dlls/shell32/folders.c,v
> retrieving revision 1.66
> diff -u -p -d -r1.66 folders.c
> --- folders.c 26 Aug 2005 10:05:35 -  1.66
> +++ folders.c 31 Dec 2005 20:29:30 -
> @@ -166,7 +166,7 @@ static HRESULT getIconLocationForFolder(
>   LPWSTR szIconFile, UINT cchMax, int *piIndex, UINT *pwFlags)
>  {
>  IExtractIconWImpl *This = (IExtractIconWImpl *)iface;
> -DWORD dwNr;
> +DWORD dwNr;  /*TODO: change to int type */
>  WCHAR wszPath[MAX_PATH];
>  WCHAR wszCLSIDValue[CHARS_IN_GUID];
>  static const WCHAR shellClassInfo[] = {
>  '.','S','h','e','l','l','C','l','a','s','s','I','n','f','o',0 };
> @@ -202,9 +202,13 @@ static HRESULT getIconLocationForFolder(
>  if (!HCR_GetDefaultIconW(folder, szIconFile, cchMax, &dwNr))
>  {
>  lstrcpynW(szIconFile, swShell32Name, cchMax);
> -dwNr = IDI_SHELL_FOLDER;
> +dwNr = (DWORD)-IDI_SHELL_FOLDER;
>  }
> -*piIndex = -((uFlags & GIL_OPENICON) ? dwNr + 1 : dwNr);
> +
> +if (uFlags & GIL_OPENICON)
> +*piIndex = (int)dwNr<0? (int)dwNr-1: dwNr+1;
> +else
> +*piIndex = dwNr;
>  }
>  return S_OK;
>  }

daily winetest generation

[Saulius Krasuckas]

I may perfectly repeat someones else question, but why in the world 
winetest-200YmmDD1000-paul-mingw.exe files aren't being generated if the 
patches arrives too late during partical day?

I think compiled EXEs should be released regardless of their generation 
date.  No?

Re: Question regarding the Wine Vs WineLib performance

[Boaz Harrosh]

What are the timing for the three classes ?

Ananth M wrote:



On 1/5/06, [EMAIL PROTECTED] 
* <[EMAIL PROTECTED] 
> wrote:



Thank you !!

I will try to compile the windows application using MinGW and check 
the performance using the same DLL.


Here is the some more information that I would like to share with you  
is :
 I am using the Binary only DLL. I am not having the source for the 
DLL. SO I am not compiling the DLL in windows or in Linux. I am 
linking this binary only dll with my windows application, (since my 
application uses the function exported by this binary only DLL)
Then I moved the executable to Linux and executed using the wine 
.
I checked the execution time of  the function exported by the Binary 
Only DLL


In the second Case , I created the .so for the binary only dll, such 
that the functions that are exported by the binary only dll will be 
called from the stub functions exported by the .so
Then I called the stub function (exported by .so)  from my winelib 
application.
But, In this case  also, I checked the time duration for the execution 
of the dll function only.( by adding a code that gives the time 
duration, in the stub function that calls the dll function).


As a third Case, I loaded  the binary dll directly (without creating 
the .so),  using LoadLibrary ("Binaryonlydll"),  and compiled and 
linked the application using Wine supplied DLL's and header files. 
Then I called the function exported by the binary only dll directly 
from the application  and checked the time duration for the execution 
of  the dll function .


In this case also we are  getting the same timing as in Second Case, 
but we are not getting the better performance as in first case.


 
 
 






  

Re: Wine 0.9.5 no longer runs Dragon Naturally Speaking

[Mike McCormack]

On Fri, 2006-01-06 at 07:36 +0100, Emmanuel Charpentier wrote:


As stated in the title, Wine 0.9.5 no longer runs Dragon Naturally 
Speaking (voice recognition). 


Please do a regression analysis (as described on winehq.org) to find the 
patch that caused the regression, rather than just trying to use an 
older version of Wine.


http://winehq.org/site/docs/winedev-guide/x1344

thanks,

Mike

Re: Wine 0.9.5 no longer runs Dragon Naturally Speaking

[Scott Ritchie]

There's no apt repository for old packages, however old debs are
available here:

http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=174803

I'll put a link to there on the download-deb page at winehq soon.

I've forwarded this message to wine-devel as that's the proper place to
report regressions, rather than emailing me.

Thanks,
Scott Ritchie
On Fri, 2006-01-06 at 07:36 +0100, Emmanuel Charpentier wrote:
> Dear Scott,
> 
> As stated in the title, Wine 0.9.5 no longer runs Dragon Naturally 
> Speaking (voice recognition). I Cc this mail to [EMAIL PROTECTED], 
> because he's seriously interested with this program (he published the 
> how-to-install document...). The program stops early in the setup 
> process (an error dialog box pops up *behind* DNS' flash screen) : the 
> error message refers to an "Access violation" error and points to 
> Dragon's own log (which reports a segment violation and barfs a somewhat 
> largish stack dump).
> 
> Using DNS on a daily basis, I wish to revert to wine 0.9.4 or 0.9.3, but 
> I am unable to find a repository for the older Debian packages. Is there 
> a repository for these packages ?
> 
> Sincerely yours,
> 
>   Emmanuel Charpentier