Re: rundll32.exe - interface: SHHelpShortcuts_RunDLL

[Dmitry Timoshkov]

"Detlef Riekenberg" <[EMAIL PROTECTED]> wrote:

> While implementing this Functions, I have some Question for the
> Interface of:
> 
> shell32.dll SHHelpShortcuts_RunDLL*
> 
> 1. HWND hwnd
> 2. DWORD dwArg2
> 3. LTCSTR szCommand / LPCWSTR wszCommand
> 4. DWORD dwArg4
> 
> 
> Question for 2:
> What is this Parameter for?
> (Seems to always be 0x77d8000. => last ptr for winvdm.exe)
> 
> Question for 3:
> What Parameter / Which Commands did you knew?
> FontsFolder
> PrintersFolder
> AddPrinter
> PrintTestPage
> Connect
> Disconnect
> 
> 
> Question for 4:
> What is this Flags-Parameter for?
> (Seems to always be 0xa.)

I think that answers to most of the above questions you could find by
taking rundll32.exe from win2k or XP, feeding all kinds of different
arguments and running it under Wine with +relay,+snoop trace.

Google(-groups) knows something as well:

rundll32.exe shell32.dll,SHHelpShortcuts_Ru-nDLL PrintersFolder

-- 
Dmitry.

rundll32.exe - interface: SHHelpShortcuts_RunDLL

[Detlef Riekenberg]

Hi.

While implementing this Functions, I have some Question for the
Interface of:

shell32.dll SHHelpShortcuts_RunDLL*

1. HWND hwnd
2. DWORD dwArg2
3. LTCSTR szCommand / LPCWSTR wszCommand
4. DWORD dwArg4


Question for 2:
What is this Parameter for?
(Seems to always be 0x77d8000. => last ptr for winvdm.exe)

Question for 3:
What Parameter / Which Commands did you knew?
FontsFolder
PrintersFolder
AddPrinter
PrintTestPage
Connect
Disconnect


Question for 4:
What is this Flags-Parameter for?
(Seems to always be 0xa.)


-- 
By By ...
  ... Detlef

Re: winedump: Print file offset instead of obscure 'prefix' while dumping data

[Dmitry Timoshkov]

"Eric Pouech" <[EMAIL PROTECTED]> wrote:

> > Changelog:
> > Dmitry Timoshkov <[EMAIL PROTECTED]>
> > Print file offset instead of obscure 'prefix' while dumping data.
> prefix is used to properly indent the output of the dump, so you do want to 
> keep 
> the prefix (this doesn't prevent you from adding the offsets for dumps)

The offset is going to replace the prefix, not to coexist with it.
Are you objecting to it?

-- 
Dmitry.

Re: urlmon: Prevent possible use of freed memory

[Troy Rollo]

On Sun, 22 May 2005 20:24, Jacek Caban wrote:

> The right solution is separating IBinding and IMoniker interfaces. They
> shouldn't be implemented in the same object. I'll send the patch.

There is potential for the problem to re-occur when asynchronous binding is 
implemented. A comment warning of the potential issue would be helpful in 
there somewhere.

Re: [RESENT] MSVCRT: Use DuplicateHandle for CONOUT too

[Uwe Bonnes]

> "Eric" == Eric Pouech <[EMAIL PROTECTED]> writes:

Eric> Uwe Bonnes a écrit :
>> Changelog: dlls/msvcrt/console.c: msvcrt_init_console Use
>> DuplicateHandle for STDOUT too ( CreateFileA("CONOUT$" failed) Bump
>> up error reporting of missing console handles

Eric> that's that's not a correct fix... this handles must be to the
Eric> console itself, whatever the input / output handles are (from
Eric> process inheritance) the issue you have is that you run your
Eric> program without being attached to a (wine) console...  you're
Eric> facing the corner cases of running wine with the "fake" console as
Eric> being inherited from the unix stdin/stdout streams the correct fix
Eric> would be to let OpenConsoleW work in those cases A+ -- Eric Pouech

Would it be right to first try to open the console and and on failure to use
DuplicateHandle?

-- 
Uwe Bonnes[EMAIL PROTECTED]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --

Re: urlmon/umon.c: Fix corruption

[Jacek Caban]

Uwe Bonnes wrote:

>Changelog:
>   dlls/urlmon/umon.c: URLMonikerImpl_Release()
>   Release structure elements before Freeing structure
>  
>
My patch I sent today fixes this too.

> Changelog:
>   wine/dlls/urlmon/umon.c:URLMonikerImpl_BindToStorage()
>   Don't use a HeapAllocated pointer for other purposes

...

> +if (path)
> + HeapFree(GetProcessHeap(), 0, path);

You don't need this check.


> Changelog:
>   dlls/wininet/internet.c: CrackURL, dlls/wininet/tests/http.c
>   Add some escape/unescape cases and code thor that cases
...
> +  ok(InternetCrackUrlA(TEST_URL3, 0, ICU_DECODE, 
> &urlComponents),"InternetCrackUrl failed with GLE 0x%lx\n",GetLastError());
> +  fprintf(stderr,"BON:%*s\n", (int)urlComponents.dwUrlPathLength, 
> urlComponents.lpszUrlPath);
>  
>  }

You shouldn't use fprintf() here. Use trace() instead.

Jacek

Re: [RESENT] MSVCRT: Use DuplicateHandle for CONOUT too

[Eric Pouech]

Uwe Bonnes a écrit :

Changelog:
dlls/msvcrt/console.c: msvcrt_init_console
Use DuplicateHandle for STDOUT too ( CreateFileA("CONOUT$" failed)
Bump up error reporting of missing console handles


that's
that's not a correct fix... this handles must be to the console itself, whatever 
the input / output handles are (from process inheritance)
the issue you have is that you run your program without being attached to a 
(wine) console...
you're facing the corner cases of running wine with the "fake" console as being 
inherited from the unix stdin/stdout streams

the correct fix would be to let OpenConsoleW work in those cases
A+
--
Eric Pouech

Re: [OLE #90] Marshal Objects & Monikers into the ROT

[Robert Shearman]

Alexandre Julliard wrote:


Robert Shearman <[EMAIL PROTECTED]> writes:

 


Changelog:
- Marshal objects & monikers into the ROT.
- Test for this behaviour.
   



This fails make test here:

../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so 
moniker.c && touch moniker.ok
fixme:ole:MkParseDisplayName (0x77c518a0, 
L"clsid:20D04FE0-3AEA-1069-A2D8-08002B30309D:", 0x77acfe68, (nil)): stub.
err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x80004005
moniker.c:145: Test failed: Number of monikers should be equal to 2 not 0
err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x80004005
moniker.c:164: Test failed: Number of monikers should be equal to 2 not 0
fixme:ole:CreateClassMoniker {0002e005---c000-0046}
err:ole:get_unmarshaler_from_stream Failed to read common OBJREF header, 
0x0001
make[3]: *** [moniker.ok] Error 2
 



Thanks for catching that. The test will now work after applying patches 
#91 and #92.


Rob

Re: WineHQ css; binfmt && Mono && wine

[Jakob Eriksson]

Dimi Paun wrote:


This is just wasted effort. They will probably get "close", but
will never be "good enough". They just fail to understand that.
Nevertheless, a lot of effort will be wasted, and we as a community 
will be years behind providing a good solution. Sigh.


Not to mention that we (the Wine project) lost a huge contributor.
If only a fraction of that effort would have been put into improving
the controls say, we would have been in a much better place.

I really think we need to put more effort in addressing this properly.



Hear, hear!

//Jakob

Re: urlmon: Prevent possible use of freed memory

[Jacek Caban]

Troy Rollo wrote:

>This fixes Bugzilla bug 2969 
>
>ChangeLog:
>   Prevent a URLMonikerImpl from being freed before its work in
>   BindToStorage is done.
>  
>
>
>
>Index: dlls/urlmon/umon.c
>===
>RCS file: /home/wine/wine/dlls/urlmon/umon.c,v
>retrieving revision 1.52
>diff -u -r1.52 umon.c
>--- dlls/urlmon/umon.c 5 May 2005 09:50:46 -   1.52
>+++ dlls/urlmon/umon.c 21 May 2005 23:57:36 -
>@@ -456,6 +456,13 @@
> *ppvObject = (void *) This->pstrCache;
> IStream_AddRef((IStream *) This->pstrCache);
> 
>+/* We are about to start calling back into the application. It is
>+ * possible that the application will release its reference to us in
>+ * these callbacks, so we need to add a reference to This to make 
>sure the
>+ * URLMonikerImpl is not freed before we reach the end of this method.
>+ */
>  
>
The right solution is separating IBinding and IMoniker interfaces. They
shouldn't be implemented in the same object. I'll send the patch.

Jacek

Re: qcap/avicap and driver models

[Eric Pouech]

Maarten Lankhorst a écrit :

Hi Alexandre,

I implemented a driver model in qcap now, but avicap32 still uses my old 
#ifdef LINUX_VIDEODEV_H, since some people might be interested in 
writing capcreatecapturewindow, I think we should move out the drivers 
from qcap to our own vfwwine dll/driver, windows uses a similar model 
for it, as rolf kalbermatter pointed out in 
http://www.winehq.com/?issue=274#Video%20Capture%20in%20Windows


as already stated, drivers should be written as follows:
1/ since it's wine specific, its name should start with wine (so winevfw or 
whatever)

2/ the driver shall be a driver for both avicap and qcap DLL
3/ interfaces to the driver should be the regular windows' ones (fetch 
information on avicap driver interface, as well as DShow driver interface - DDK 
info on the Web are your friend)
4/ a single driver shall be provided for all possible unix interfaces (you can 
start with v4l of course) and shall


Item 2/ has the following benefits:
- it centralizes access to a given kernel resource in a single DLL
- some information between the two types of interfaces may have to be shared

Item 3/ has the following benefits:
- you can test the qcap, avicap... DLLs under windows with *real* drivers and 
see if it works

- we can share all the qcap, avicap... DLLs with the folks from ReactOS
- some braindead programs may look at some (real driver) interfaces for their 
own use


Item 4/ has the following benefits:
- it's up to the driver, at runtime, to find out and setup the existing physical 
devices
- you don't need to have fancy settings (configuration...), which most users 
won't understand


BTW this is was has to be done for the audio/midi drivers (where 1, 2, 3 are 
already done, and 4 is missing)


A+

--
Eric Pouech

Re: console behaviour of tty vs. x11 driver

[Eric Pouech]

Kuba Ober a écrit :

Hi,
I'm running vc.net as a cross-compiler under wine. Everything looks very nice 
when you run it with X server running. Yet, when there's no X present, 
winetty driver kicks in and corrupts the console output. Is there a simple 
remedy? Here are the problems that I observe:


this has already been discussed. what is needed is to delay "real" init for X11 
or TTY driver until the app really needs (by "real", I mean connect to X11 
server or init the ncurse(s) backend)


A+
--
Eric Pouech