"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
Stubs basic DDE interface of Progman.exe. Similar to Progman stub in shell32.dll. Both will need to be extended and a 3rd progman interface will need to be added in user32.
Progman DDE interface should be implemented by shell32.dll, nowhere else. -- Dmitry.
On Tue, 2009-02-03 at 22:55 +0800, Dmitry Timoshkov wrote:
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
Stubs basic DDE interface of Progman.exe. Similar to Progman stub in shell32.dll. Both will need to be extended and a 3rd progman interface will need to be added in user32.
Progman DDE interface should be implemented by shell32.dll, nowhere else.
The shell32.dll DDE callback isn't always initialized & handling Progman calls for all apps. I've seen Progman calls pass through the DDE_client and DDE_server of user32.dll instead and never go through shell32.dll. We can have the actual Progman functions in shell32.dll, but at least user32.dll will have to be able to call & be called by these. I think a separate progman.c/progman.h in /dlls/user32 to handle calls from all locations may be preferred. Any suggestions?
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
Stubs basic DDE interface of Progman.exe. Similar to Progman stub in shell32.dll. Both will need to be extended and a 3rd progman interface will need to be added in user32.
Progman DDE interface should be implemented by shell32.dll, nowhere else.
The shell32.dll DDE callback isn't always initialized & handling Progman calls for all apps. I've seen Progman calls pass through the DDE_client and DDE_server of user32.dll instead and never go through shell32.dll.
progman.exe in Windows is an empty stub.
We can have the actual Progman functions in shell32.dll, but at least user32.dll will have to be able to call & be called by these. I think a separate progman.c/progman.h in /dlls/user32 to handle calls from all locations may be preferred.
Probably you need to write some tests first which actually use the progman DDE interface. -- Dmitry.
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
The shell32.dll DDE callback isn't always initialized & handling Progman calls for all apps. I've seen Progman calls pass through the DDE_client and DDE_server of user32.dll instead and never go through shell32.dll.
That would IMHO only be possible if the shell executable, which normally is just explorer creating the actual desktop view had been replaced by a different executable that does not initialize the shell DDE interface properly. Rolf Kalbermatter
On Thu, 2009-02-05 at 18:58 +0100, Rolf Kalbermatter wrote:
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
The shell32.dll DDE callback isn't always initialized & handling Progman calls for all apps. I've seen Progman calls pass through the DDE_client and DDE_server of user32.dll instead and never go through shell32.dll.
That would IMHO only be possible if the shell executable, which normally is just explorer creating the actual desktop view had been replaced by a different executable that does not initialize the shell DDE interface properly.
Rolf Kalbermatter
DdeConnect, DDeInitialize, and DDeDisconnect can be called directly by including Windows.h and importing the calls from user32 (http://msdn.microsoft.com/en-us/library/ms648745(VS.85).aspx). DDE calls can then be made with SendMessage or PostMessage. I found a couple apps that appear to do this. Wine does not automatically start explorer.exe or initialize the shell DDE interface, nor does it route the DdeConnect routine in user32.dll to the DdeConnect routine in the shell32.dll. The DDE interface in shell32 and user32 will need to call the same set of routines from either method for full functionality of DDE calls, including those to Progman.
2009/2/5 Jeremiah Flerchinger <jeremiah.flerchinger(a)gmail.com>:
On Thu, 2009-02-05 at 18:58 +0100, Rolf Kalbermatter wrote:
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
The shell32.dll DDE callback isn't always initialized & handling Progman calls for all apps. I've seen Progman calls pass through the DDE_client and DDE_server of user32.dll instead and never go through shell32.dll.
That would IMHO only be possible if the shell executable, which normally is just explorer creating the actual desktop view had been replaced by a different executable that does not initialize the shell DDE interface properly.
Rolf Kalbermatter
DdeConnect, DDeInitialize, and DDeDisconnect can be called directly by including Windows.h and importing the calls from user32 (http://msdn.microsoft.com/en-us/library/ms648745(VS.85).aspx). DDE calls can then be made with SendMessage or PostMessage.
I found a couple apps that appear to do this. Wine does not automatically start explorer.exe or initialize the shell DDE interface, nor does it route the DdeConnect routine in user32.dll to the DdeConnect routine in the shell32.dll. The DDE interface in shell32 and user32 will need to call the same set of routines from either method for full functionality of DDE calls, including those to Progman.
http://en.wikipedia.org/wiki/Library_(computing)#Dynamic_linking -- Rob Shearman
Rolf Kalbermatter
-----Original Message----- From: Jeremiah Flerchinger [mailto:jeremiah.flerchinger(a)gmail.com] Sent: Thursday, February 05, 2009 7:33 PM To: Rolf Kalbermatter Cc: wine-devel(a)winehq.org Subject: RE: Stub DDE interface for Progman.exe
On Thu, 2009-02-05 at 18:58 +0100, Rolf Kalbermatter wrote:
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
The shell32.dll DDE callback isn't always initialized & handling Progman calls for all apps. I've seen Progman calls pass through the DDE_client and DDE_server of user32.dll instead and never go through shell32.dll.
That would IMHO only be possible if the shell executable, which normally is just explorer creating the actual desktop view had been replaced by a different executable that does not initialize the shell DDE interface properly.
Rolf Kalbermatter
DdeConnect, DDeInitialize, and DDeDisconnect can be called directly by including Windows.h and importing the calls from user32 (http://msdn.microsoft.com/en-us/library/ms648745(VS.85).aspx) . DDE calls can then be made with SendMessage or PostMessage.
I found a couple apps that appear to do this. Wine does not automatically start explorer.exe or initialize the shell DDE interface, nor does it route the DdeConnect routine in user32.dll to the DdeConnect routine in the shell32.dll. The DDE interface in shell32 and user32 will need to call the same set of routines from either method for full functionality of DDE calls, including those to Progman.
Maybe I'm not understanding you here but you seem to mix the actual and generic DDE support in user32 and the progman DDE server support in shell32. All DDE applications (server and clients) have to use the the DDE functions from user32. Shell32 implements a DDE server that supports the progman interface among other things. Explorer or any properly operating shell desktop replacement will call the according shell32 export that initializes that server. If the progman DDE interface is not available under Windows you are not running any proper shell desktop process. Much like in Windows 3.1 days where you could replace the progman.exe with your own executable too but unless it implemented the progman DDE interface too, no progman DDE was available. Now if you want to add support for the progman DDE server to Wine you will have to improve the stubs in shell32/dde.c. The ShellDDEInit() function is already there and the initialization for the "progman", "shell" and "folder" service too, but it is missing the implementation for all the DDE operations on these services. Rolf Kalbermatter
Shell32 implements a DDE server that supports the progman interface among other things. Explorer or any properly operating shell desktop replacement will call the according shell32 export that initializes that server. If the progman DDE interface is not available under Windows you are not running any proper shell desktop process. Much like in Windows 3.1 days where you could replace the progman.exe with your own executable too but unless it implemented the progman DDE interface too, no progman DDE was available.
Yes you're right. Originally I was wanting to add a shell DDE server to progman.exe, so it could provide that interface as a shell replacement. I thought that explorer.exe should have this similarly. I was trying to think of how Wine's explorer.exe and progman.exe would/could update each other if both were run at the same time. I doubt there would be many instances of this being tried & would like to see a single and persistent shell DDE interface that works first.
Now if you want to add support for the progman DDE server to Wine you will have to improve the stubs in shell32/dde.c. The ShellDDEInit() function is already there and the initialization for the "progman", "shell" and "folder" service too, but it is missing the implementation for all the DDE operations on these services.
Yes, this would be a fine place since the ShellDDEInit in Wine starts a DDE server that stubs these services. The DDE server has to be running though. The built-in explorer shell process does not start (or stop) it. If the server were actually started, then the stubs would actually run & we could work on fixing them. I'd be happy if we get this single DDE interface started on initialization so we can work on patching it and worry about how other replacement shells would interact later.
2009/2/3 Dmitry Timoshkov <dmitry(a)codeweavers.com>:
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
Stubs basic DDE interface of Progman.exe. Similar to Progman stub in shell32.dll. Both will need to be extended and a 3rd progman interface will need to be added in user32.
Progman DDE interface should be implemented by shell32.dll, nowhere else.
And it already is: ShellDDEInit. All it needs is some always running process to call it. It looks like explorer would be a good choice. -- Rob Shearman
On Thu, 2009-02-05 at 18:12 +0000, Rob Shearman wrote:
2009/2/3 Dmitry Timoshkov <dmitry(a)codeweavers.com>:
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
Stubs basic DDE interface of Progman.exe. Similar to Progman stub in shell32.dll. Both will need to be extended and a 3rd progman interface will need to be added in user32.
Progman DDE interface should be implemented by shell32.dll, nowhere else.
And it already is: ShellDDEInit.
All it needs is some always running process to call it. It looks like explorer would be a good choice.
Is explorer always running in Wine? I know "wine explorer" does not run ShellDDEInit when it starts. I thought most people were against additional processes, but I want to see the Progman DDE interface working for the different ways of calling it. ShellDDEInit didn't exist before Win 2000 and was in Shdocw.dll and not shell32.dll. Do we want to call ShellDDEInit in shell32 when Wine starts (and ends) then? It is supposed to be called only by the process that is acting as the shell when it registers itself as a DDE host for the shell. I don't think anything else would ever call it then.
2009/2/5 Jeremiah Flerchinger <jeremiah.flerchinger(a)gmail.com>:
On Thu, 2009-02-05 at 18:12 +0000, Rob Shearman wrote:
2009/2/3 Dmitry Timoshkov <dmitry(a)codeweavers.com>:
"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote:
Stubs basic DDE interface of Progman.exe. Similar to Progman stub in shell32.dll. Both will need to be extended and a 3rd progman interface will need to be added in user32.
Progman DDE interface should be implemented by shell32.dll, nowhere else.
And it already is: ShellDDEInit.
All it needs is some always running process to call it. It looks like explorer would be a good choice.
Is explorer always running in Wine? I know "wine explorer" does not run ShellDDEInit when it starts. I thought most people were against additional processes, but I want to see the Progman DDE interface working for the different ways of calling it.
Try running a simple winelib app with WINEDEBUG=+process set and see for yourself.
ShellDDEInit didn't exist before Win 2000 and was in Shdocw.dll and not shell32.dll. Do we want to call ShellDDEInit in shell32 when Wine starts (and ends) then?
I'm not sure if there is a desire to allow native shell32 to be used in Wine. However, if there is it would be simple to use GetProcAddress with appropriate checks on the shell32 module that has been loaded.
It is supposed to be called only by the process that is acting as the shell when it registers itself as a DDE host for the shell. I don't think anything else would ever call it then.
I can't work out what you mean by this. Perhaps you can rephrase it or describe in more detail what you mean. -- Rob Shearman
On Fri, 2009-02-06 at 10:41 +0000, Rob Shearman wrote:
2009/2/5 Jeremiah Flerchinger <jeremiah.flerchinger(a)gmail.com>:
On Thu, 2009-02-05 at 18:12 +0000, Rob Shearman wrote: Is explorer always running in Wine? I know "wine explorer" does not run ShellDDEInit when it starts. I thought most people were against additional processes, but I want to see the Progman DDE interface working for the different ways of calling it.
Try running a simple winelib app with WINEDEBUG=+process set and see for yourself.
OK, an explorer process is always running, but it does not run ShellDDEInit when it starts & it probably should.
ShellDDEInit didn't exist before Win 2000 and was in Shdocw.dll and not shell32.dll. Do we want to call ShellDDEInit in shell32 when Wine starts (and ends) then?
I'm not sure if there is a desire to allow native shell32 to be used in Wine. However, if there is it would be simple to use GetProcAddress with appropriate checks on the shell32 module that has been loaded.
I don't know if there is any desire for a native shell32 either. I think I agree with Dmitry that the built-in explorer should call ShellDDEInit. As it stands, for the built-in explorer, it is never called and the respective DDE interfaces are never registered.
It is supposed to be called only by the process that is acting as the shell when it registers itself as a DDE host for the shell. I don't think anything else would ever call it then.
I can't work out what you mean by this. Perhaps you can rephrase it or describe in more detail what you mean. ShellDDEInit is supposed to be called by the process that is acting as the shell (progman.exe, explorer.exe, etc) when it starts & begins handling the DDE interface for the shell. The built-in explorer process should call this when it starts, so it starts handling the appropriate calls. It should call ShellDDEInit(1) when it starts and ShellDDEInit(0) when it terminates. I'm not familiar enough with the explorer code currently to know where.
Jeremiah Flerchinger [mailto:jeremiah.flerchinger(a)gmail.com] wrote:
ShellDDEInit didn't exist before Win 2000 and was in Shdocw.dll and not shell32.dll.
Actually it is supported back to at least Win98 in shdocw and most probably even Win95 since that did support the progman interface too.
Do we want to call ShellDDEInit in shell32 when Wine starts (and ends) then? It is supposed to be called only by the process that is acting as the shell when it registers itself as a DDE host for the shell. I don't think anything else would ever call it then.
If you want Wine explorer to potentially run on Windows systems too you would probably call the export in shdocw instead which dynamically forwards to shell32 in Wine. Once the shell32 DDE server does actually something useful I think it would be a good idea to initialize it in the first explorer process that gets started. Maybe ShellDDEInit even should protect itself from being called multiple times to start up the server. Rolf Kalbermatter
participants (5)
-
Dmitry Timoshkov -
Jeremiah Flerchinger -
Rob Shearman -
Rolf Kalbermatter -
Rolf Kalbermatter