Hi again all, before I go and file another needless bug, I thought I would ask for opinions.
I decided to try to run Process Explorer today with wine. When I first ran it, I got a dialog about missing a function. So I looked back thru the traces and it was because we were missing acledit.dll.. So I imported that from my windows xp install, and got the dialog again. Turned out I was also missing netui0.dll, netui1.dll, and netui2.dll and those in turn needed netrap.dll and samlib.dll.
Once I got all of those imported from XP, Process Explorer now runs beautifully.
I looked at the version information, and here is the description of each dll
acledit is an access control list editor netui0 is NT LM UI Common Code - GUI Classes netui1 is NT LM UI Common Code - Networking classes netui2 is NT LM UI Common Code - GUI Classes netrap is Net Remote Admin Protocol DLL and samlib is SAM Library DLL
I assume SAM is the Security Accounts Manager service, so that last dll would go for that and most likely would never be implemented with wine. But, how about the others? Is doing one of these something possibly feasible for a SoC project? I'm sure that there are other projects that use these dll's as well, but I dont know of them..
My biggest question is when is it appropriate for us to build our own DLL's vs just saying to use native?
I would personally like to at least see the NTLM stuff get built since I know one of the developers is working on NTLM right now
Also, should I file a bug for Process Explorer needing native dll's, or should I maybe file a bug to build our own versions of these dll's, OR should I just leave it alone altogether?
I am creating an AppDB page for the program now. Does anyone object to me putting notes about which native dll's are needed on that page?
Tom Spear wrote:
I decided to try to run Process Explorer today with wine. When I first ran it, I got a dialog about missing a function. So I looked back thru the traces and it was because we were missing acledit.dll.. So I imported that from my windows xp install, and got the dialog again. Turned out I was also missing netui0.dll, netui1.dll, and netui2.dll and those in turn needed netrap.dll and samlib.dll.
I assume SAM is the Security Accounts Manager service, so that last dll would go for that and most likely would never be implemented with wine. But, how about the others? Is doing one of these something possibly feasible for a SoC project? I'm sure that there are other projects that use these dll's as well, but I dont know of them..
My biggest question is when is it appropriate for us to build our own DLL's vs just saying to use native?
netui0.dll, netui1.dll and netui2.dll are completely undocumented and export C++ entry points. They are only required because they are imported by acledit.dll, as is also samlib.dll. You might want to do a little debugging next time to see what modules are importing the DLLs.
The only DLL that is required directly and that needs to be stubbed is acledit.dll.
Tom Spear wrote:
Hi again all, before I go and file another needless bug, I thought I would ask for opinions.
I decided to try to run Process Explorer today with wine. When I first ran it, I got a dialog about missing a function. So I looked back thru the traces and it was because we were missing acledit.dll.. So I imported that from my windows xp install, and got the dialog again. Turned out I was also missing netui0.dll, netui1.dll, and netui2.dll and those in turn needed netrap.dll and samlib.dll.
Once I got all of those imported from XP, Process Explorer now runs beautifully.
I looked at the version information, and here is the description of each dll
acledit is an access control list editor netui0 is NT LM UI Common Code - GUI Classes netui1 is NT LM UI Common Code - Networking classes netui2 is NT LM UI Common Code - GUI Classes netrap is Net Remote Admin Protocol DLL and samlib is SAM Library DLL
I assume SAM is the Security Accounts Manager service, so that last dll would go for that and most likely would never be implemented with wine. But, how about the others? Is doing one of these something possibly feasible for a SoC project? I'm sure that there are other projects that use these dll's as well, but I dont know of them..
My biggest question is when is it appropriate for us to build our own DLL's vs just saying to use native?
I would personally like to at least see the NTLM stuff get built since I know one of the developers is working on NTLM right now
Also, should I file a bug for Process Explorer needing native dll's, or should I maybe file a bug to build our own versions of these dll's, OR should I just leave it alone altogether?
I am creating an AppDB page for the program now. Does anyone object to me putting notes about which native dll's are needed on that page?
Hi Tom,
please have a look at:
http://wiki.winehq.org/PaulVriens
Cheers,
Paul.
Onsdag 11 april 2007 16:48, skrev Tom Spear:
Hi again all, before I go and file another needless bug, I thought I would ask for opinions.
I decided to try to run Process Explorer today with wine. When I first ran it, I got a dialog about missing a function. So I looked back thru the traces and it was because we were missing acledit.dll.. So I imported that from my windows xp install, and got the dialog again. Turned out I was also missing netui0.dll, netui1.dll, and netui2.dll and those in turn needed netrap.dll and samlib.dll.
Once I got all of those imported from XP, Process Explorer now runs beautifully.
I looked at the version information, and here is the description of each dll
acledit is an access control list editor netui0 is NT LM UI Common Code - GUI Classes netui1 is NT LM UI Common Code - Networking classes netui2 is NT LM UI Common Code - GUI Classes netrap is Net Remote Admin Protocol DLL and samlib is SAM Library DLL
I assume SAM is the Security Accounts Manager service, so that last dll would go for that and most likely would never be implemented with wine. But, how about the others? Is doing one of these something possibly feasible for a SoC project? I'm sure that there are other projects that use these dll's as well, but I dont know of them..
My biggest question is when is it appropriate for us to build our own DLL's vs just saying to use native?
I would personally like to at least see the NTLM stuff get built since I know one of the developers is working on NTLM right now
Also, should I file a bug for Process Explorer needing native dll's, or should I maybe file a bug to build our own versions of these dll's, OR should I just leave it alone altogether?
I am creating an AppDB page for the program now. Does anyone object to me putting notes about which native dll's are needed on that page?
No, if native dlls are required then it's very helpful for users to know which ones, and it's even better if you provide download links to these dlls, by using sites such as www.dll-files.com or www.dll-downloads.com, or uploading your own somewhere.
Alexander N. Sørnes
No, if native dlls are required then it's very helpful for users to know which ones, and it's even better if you provide download links to these dlls, by using sites such as www.dll-files.com or www.dll-downloads.com, or uploading your own somewhere.
Helpful and better yes, but legal?
Legal? From Microsoft's standpoint, no, but as long as you have a valid windows license, then I dont see why there should be any problem. Thus the reason I didn't actually provide any links. Besides, a quick google search for the dll brings up the dll-files site for the dll..
Tom
On 4/11/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
No, if native dlls are required then it's very helpful for users to know which ones, and it's even better if you provide download links to these dlls, by using sites such as www.dll-files.com or www.dll-downloads.com, or uploading your own somewhere.
Helpful and better yes, but legal?
Am Mittwoch 11 April 2007 20:26 schrieb Tom Spear:
Legal? From Microsoft's standpoint, no, but as long as you have a valid windows license, then I dont see why there should be any problem. Thus the reason I didn't actually provide any links. Besides, a quick google search for the dll brings up the dll-files site for the dll..
Well, I meant linking or uploading the dlls
Onsdag 11 april 2007 20:09, skrev du :
No, if native dlls are required then it's very helpful for users to know which ones, and it's even better if you provide download links to these dlls, by using sites such as www.dll-files.com or www.dll-downloads.com, or uploading your own somewhere.
Helpful and better yes, but legal?
I think so, because you are only linking to another webpage, and it is that webpage's responsibility to make sure the contents are legal. There has even been a court case about this, if I remember correctly. After all, these appear to be well-known websites, although I do recognize that one is owned by a Swedish company and the other a Canadian one.
Whether uploading your own dlls is legal will depend on where you live, of course, but I don't think anyone will hunt you down for hosting the occasional dll. It should be legal in most (if not all?) countries. Remember that most copyright laws have a 'fair use' clause, and these dlls are needed by unfortunate Windows users, with valid licences.
Regards,
Alexander N. Sørnes
Tom Spear a écrit :
Hi again all, before I go and file another needless bug, I thought I would ask for opinions.
I decided to try to run Process Explorer today with wine. When I first ran it, I got a dialog about missing a function. So I looked back thru the traces and it was because we were missing acledit.dll.. So I imported that from my windows xp install, and got the dialog again. Turned out I was also missing netui0.dll, netui1.dll, and netui2.dll and those in turn needed netrap.dll and samlib.dll.
Once I got all of those imported from XP, Process Explorer now runs beautifully.
I looked at the version information, and here is the description of each dll
acledit is an access control list editor netui0 is NT LM UI Common Code - GUI Classes netui1 is NT LM UI Common Code - Networking classes netui2 is NT LM UI Common Code - GUI Classes netrap is Net Remote Admin Protocol DLL and samlib is SAM Library DLL
I assume SAM is the Security Accounts Manager service, so that last dll would go for that and most likely would never be implemented with wine. But, how about the others? Is doing one of these something possibly feasible for a SoC project? I'm sure that there are other projects that use these dll's as well, but I dont know of them..
My biggest question is when is it appropriate for us to build our own DLL's vs just saying to use native?
I would personally like to at least see the NTLM stuff get built since I know one of the developers is working on NTLM right now
Also, should I file a bug for Process Explorer needing native dll's, or should I maybe file a bug to build our own versions of these dll's, OR should I just leave it alone altogether?
I am creating an AppDB page for the program now. Does anyone object to me putting notes about which native dll's are needed on that page?
don't remember why I didn't send it earlier :-/ it seems it might be useful A+
I just tried the patch is it fails, but I copied and pasted the code into the correct files and am recompiling wine now. We will see just how far we can get with the stubs..
Tom
P.S. did this get submitted to wine-patches today as well?
On 4/11/07, Eric Pouech eric.pouech@wanadoo.fr wrote:
Tom Spear a écrit :
Hi again all, before I go and file another needless bug, I thought I would ask for opinions.
I decided to try to run Process Explorer today with wine. When I first ran it, I got a dialog about missing a function. So I looked back thru the traces and it was because we were missing acledit.dll.. So I imported that from my windows xp install, and got the dialog again. Turned out I was also missing netui0.dll, netui1.dll, and netui2.dll and those in turn needed netrap.dll and samlib.dll.
Once I got all of those imported from XP, Process Explorer now runs beautifully.
I looked at the version information, and here is the description of each dll
acledit is an access control list editor netui0 is NT LM UI Common Code - GUI Classes netui1 is NT LM UI Common Code - Networking classes netui2 is NT LM UI Common Code - GUI Classes netrap is Net Remote Admin Protocol DLL and samlib is SAM Library DLL
I assume SAM is the Security Accounts Manager service, so that last dll would go for that and most likely would never be implemented with wine. But, how about the others? Is doing one of these something possibly feasible for a SoC project? I'm sure that there are other projects that use these dll's as well, but I dont know of them..
My biggest question is when is it appropriate for us to build our own DLL's vs just saying to use native?
I would personally like to at least see the NTLM stuff get built since I know one of the developers is working on NTLM right now
Also, should I file a bug for Process Explorer needing native dll's, or should I maybe file a bug to build our own versions of these dll's, OR should I just leave it alone altogether?
I am creating an AppDB page for the program now. Does anyone object to me putting notes about which native dll's are needed on that page?
don't remember why I didn't send it earlier :-/ it seems it might be useful A+
-- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
[AclEdit]: stubbed out acledit DLL (new in XP)
From: Eric Pouech eric.pouech@wanadoo.fr
- needed by Sysinternals' process explorer
Makefile.in | 2 ++ configure | 3 +++ configure.ac | 1 + dlls/Makefile.in | 5 ++++ dlls/acledit/Makefile.in | 14 ++++++++++++ dlls/acledit/acledit.spec | 8 +++++++ dlls/acledit/main.c | 52 +++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/Makefile.in b/Makefile.in index 7fa8ef0..541ff0d 100644 --- a/Makefile.in +++ b/Makefile.in @@ -157,6 +157,7 @@ ALL_MAKEFILES = \ dlls/Maketest.rules \ programs/Makeprog.rules \ dlls/Makefile \
dlls/acledit/Makefile \ dlls/activeds/Makefile \ dlls/advapi32/Makefile \ dlls/advapi32/tests/Makefile \@@ -498,6 +499,7 @@ dlls/Maketest.rules: dlls/Maketest.rules programs/Makeprog.rules: programs/Makeprog.rules.in Make.rules Makefile: Makefile.in Make.rules dlls/Makefile: dlls/Makefile.in Make.rules +dlls/acledit/Makefile: dlls/acledit/Makefile.in dlls/Makedll.rules dlls/activeds/Makefile: dlls/activeds/Makefile.in dlls/Makedll.rules dlls/advapi32/Makefile: dlls/advapi32/Makefile.in dlls/Makedll.rules dlls/advapi32/tests/Makefile: dlls/advapi32/tests/Makefile.in dlls/Maketest.rules diff --git a/configure b/configure index e240093..4fd1069 100755 --- a/configure +++ b/configure @@ -20202,6 +20202,8 @@ ac_config_files="$ac_config_files Makefi
ac_config_files="$ac_config_files dlls/Makefile"
+ac_config_files="$ac_config_files dlls/acledit/Makefile"
ac_config_files="$ac_config_files dlls/activeds/Makefile"
ac_config_files="$ac_config_files dlls/advapi32/Makefile" @@ -21421,6 +21423,7 @@ do "programs/Makeprog.rules") CONFIG_FILES="$CONFIG_FILES programs/Makeprog.rules" ;; "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;; "dlls/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/Makefile" ;;
- "dlls/acledit/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/acledit/Makefile" ;; "dlls/activeds/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/activeds/Makefile" ;; "dlls/advapi32/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/advapi32/Makefile" ;; "dlls/advapi32/tests/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/advapi32/tests/Makefile" ;;
diff --git a/configure.ac b/configure.ac index 6d9e2cf..beea1df 100644 --- a/configure.ac +++ b/configure.ac @@ -1491,6 +1491,7 @@ AC_CONFIG_FILES([dlls/Maketest.rules]) AC_CONFIG_FILES([programs/Makeprog.rules]) AC_CONFIG_FILES([Makefile]) AC_CONFIG_FILES([dlls/Makefile]) +AC_CONFIG_FILES([dlls/acledit/Makefile]) AC_CONFIG_FILES([dlls/activeds/Makefile]) AC_CONFIG_FILES([dlls/advapi32/Makefile]) AC_CONFIG_FILES([dlls/advapi32/tests/Makefile]) diff --git a/dlls/Makefile.in b/dlls/Makefile.in index a0dcea0..0571524 100644 --- a/dlls/Makefile.in +++ b/dlls/Makefile.in @@ -16,6 +16,7 @@ EXTRADIRS = @GLU32FILES@ @OPENGLFILES@ @ # Subdir list
BASEDIRS = \
acledit \ activeds \ advapi32 \ advpack \@@ -455,6 +456,7 @@ IMPORT_LIBS = \ strmiids/libstrmiids.a \ uuid/libuuid.a \ winecrt0/libwinecrt0.a \
acledit/libacledit.$(IMPLIBEXT) \ activeds/libactiveds.$(IMPLIBEXT) \ advapi32/libadvapi32.$(IMPLIBEXT) \ advpack/libadvpack.$(IMPLIBEXT) \@@ -580,6 +582,9 @@ implib: $(IMPORT_LIBS)
.PHONY: implib
+acledit/libacledit.$(IMPLIBEXT): acledit/acledit.spec $(WINEBUILD)
@cd acledit && $(MAKE) libacledit.$(IMPLIBEXT)activeds/libactiveds.$(IMPLIBEXT): activeds/activeds.spec $(WINEBUILD) @cd activeds && $(MAKE) libactiveds.$(IMPLIBEXT)
diff --git a/dlls/acledit/Makefile.in b/dlls/acledit/Makefile.in new file mode 100644 index 0000000..83565b7 --- /dev/null +++ b/dlls/acledit/Makefile.in @@ -0,0 +1,14 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = acledit.dll +IMPORTLIB = libacledit.$(IMPLIBEXT) +IMPORTS = kernel32
+C_SRCS = \
main.c+@MAKE_DLL_RULES@
+@DEPENDENCIES@ # everything below this line is overwritten by make depend diff --git a/dlls/acledit/acledit.spec b/dlls/acledit/acledit.spec new file mode 100644 index 0000000..9448623 --- /dev/null +++ b/dlls/acledit/acledit.spec @@ -0,0 +1,8 @@ +#4 stdcall DllMain +1 stub EditAuditInfo +2 stub EditOwnerInfo +3 stub EditPermissionInfo +5 stub FMExtensionProcW +6 stub SedDiscretionaryAclEditor +7 stub SedSystemAclEditor +8 stub SedTakeOwnership diff --git a/dlls/acledit/main.c b/dlls/acledit/main.c new file mode 100644 index 0000000..b73a8e3 --- /dev/null +++ b/dlls/acledit/main.c @@ -0,0 +1,52 @@ +/*
- Implementation of the AclEdit Interface
- Copyright 2006 Eric Pouech
- This library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser 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 library 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
- Lesser General Public License for more details.
- You should have received a copy of the GNU Lesser 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
- */
+#include <stdarg.h>
+#include "windef.h" +#include "winbase.h" +#include "winuser.h" +#include "winreg.h" +#include "winver.h" +#include "winnls.h"
+#include "wine/unicode.h" +#include "wine/debug.h"
+WINE_DEFAULT_DEBUG_CHANNEL(acledit);
+/*****************************************************
- DllMain
- */
+BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) +{
- TRACE("(%p, %d, %p)\n", hinstDLL, fdwReason, lpvReserved);
- switch (fdwReason)
- {
- case DLL_WINE_PREATTACH:
return FALSE; /* prefer native version */- case DLL_PROCESS_ATTACH:
DisableThreadLibraryCalls( hinstDLL );break;- }
- return TRUE;
+}
Well the patch definitely works, so if it hasn't been submitted, please do so.
There are still crashes in random spots, but that is documented on Paul's wiki page.
Tom
On 4/11/07, Tom Spear speeddymon@gmail.com wrote:
I just tried the patch is it fails, but I copied and pasted the code into the correct files and am recompiling wine now. We will see just how far we can get with the stubs..
Tom
P.S. did this get submitted to wine-patches today as well?
On 4/11/07, Eric Pouech eric.pouech@wanadoo.fr wrote:
Tom Spear a écrit :
Hi again all, before I go and file another needless bug, I thought I would ask for opinions.
I decided to try to run Process Explorer today with wine. When I first ran it, I got a dialog about missing a function. So I looked back thru the traces and it was because we were missing acledit.dll.. So I imported that from my windows xp install, and got the dialog again. Turned out I was also missing netui0.dll, netui1.dll, and netui2.dll and those in turn needed netrap.dll and samlib.dll.
Once I got all of those imported from XP, Process Explorer now runs beautifully.
I looked at the version information, and here is the description of each dll
acledit is an access control list editor netui0 is NT LM UI Common Code - GUI Classes netui1 is NT LM UI Common Code - Networking classes netui2 is NT LM UI Common Code - GUI Classes netrap is Net Remote Admin Protocol DLL and samlib is SAM Library DLL
I assume SAM is the Security Accounts Manager service, so that last dll would go for that and most likely would never be implemented with wine. But, how about the others? Is doing one of these something possibly feasible for a SoC project? I'm sure that there are other projects that use these dll's as well, but I dont know of them..
My biggest question is when is it appropriate for us to build our own DLL's vs just saying to use native?
I would personally like to at least see the NTLM stuff get built since I know one of the developers is working on NTLM right now
Also, should I file a bug for Process Explorer needing native dll's, or should I maybe file a bug to build our own versions of these dll's, OR should I just leave it alone altogether?
I am creating an AppDB page for the program now. Does anyone object to me putting notes about which native dll's are needed on that page?
don't remember why I didn't send it earlier :-/ it seems it might be useful A+
-- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
[AclEdit]: stubbed out acledit DLL (new in XP)
From: Eric Pouech eric.pouech@wanadoo.fr
- needed by Sysinternals' process explorer
Makefile.in | 2 ++ configure | 3 +++ configure.ac | 1 + dlls/Makefile.in | 5 ++++ dlls/acledit/Makefile.in | 14 ++++++++++++ dlls/acledit/acledit.spec | 8 +++++++ dlls/acledit/main.c | 52 +++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/Makefile.in b/Makefile.in index 7fa8ef0..541ff0d 100644 --- a/Makefile.in +++ b/Makefile.in @@ -157,6 +157,7 @@ ALL_MAKEFILES = \ dlls/Maketest.rules \ programs/Makeprog.rules \ dlls/Makefile \
dlls/acledit/Makefile \ dlls/activeds/Makefile \ dlls/advapi32/Makefile \ dlls/advapi32/tests/Makefile \@@ -498,6 +499,7 @@ dlls/Maketest.rules: dlls/Maketest.rules programs/Makeprog.rules: programs/Makeprog.rules.in Make.rules Makefile: Makefile.in Make.rules dlls/Makefile: dlls/Makefile.in Make.rules +dlls/acledit/Makefile: dlls/acledit/Makefile.in dlls/Makedll.rules dlls/activeds/Makefile: dlls/activeds/Makefile.in dlls/Makedll.rules dlls/advapi32/Makefile: dlls/advapi32/Makefile.in dlls/Makedll.rules dlls/advapi32/tests/Makefile: dlls/advapi32/tests/Makefile.in dlls/Maketest.rules diff --git a/configure b/configure index e240093..4fd1069 100755 --- a/configure +++ b/configure @@ -20202,6 +20202,8 @@ ac_config_files="$ac_config_files Makefi
ac_config_files="$ac_config_files dlls/Makefile"
+ac_config_files="$ac_config_files dlls/acledit/Makefile"
ac_config_files="$ac_config_files dlls/activeds/Makefile"
ac_config_files="$ac_config_files dlls/advapi32/Makefile" @@ -21421,6 +21423,7 @@ do "programs/Makeprog.rules") CONFIG_FILES="$CONFIG_FILES programs/Makeprog.rules" ;; "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;; "dlls/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/Makefile" ;;
- "dlls/acledit/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/acledit/Makefile" ;; "dlls/activeds/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/activeds/Makefile" ;; "dlls/advapi32/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/advapi32/Makefile" ;; "dlls/advapi32/tests/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/advapi32/tests/Makefile" ;;
diff --git a/configure.ac b/configure.ac index 6d9e2cf..beea1df 100644 --- a/configure.ac +++ b/configure.ac @@ -1491,6 +1491,7 @@ AC_CONFIG_FILES([dlls/Maketest.rules]) AC_CONFIG_FILES([programs/Makeprog.rules]) AC_CONFIG_FILES([Makefile]) AC_CONFIG_FILES([dlls/Makefile]) +AC_CONFIG_FILES([dlls/acledit/Makefile]) AC_CONFIG_FILES([dlls/activeds/Makefile]) AC_CONFIG_FILES([dlls/advapi32/Makefile]) AC_CONFIG_FILES([dlls/advapi32/tests/Makefile]) diff --git a/dlls/Makefile.in b/dlls/Makefile.in index a0dcea0..0571524 100644 --- a/dlls/Makefile.in +++ b/dlls/Makefile.in @@ -16,6 +16,7 @@ EXTRADIRS = @GLU32FILES@ @OPENGLFILES@ @ # Subdir list
BASEDIRS = \
acledit \ activeds \ advapi32 \ advpack \@@ -455,6 +456,7 @@ IMPORT_LIBS = \ strmiids/libstrmiids.a \ uuid/libuuid.a \ winecrt0/libwinecrt0.a \
acledit/libacledit.$(IMPLIBEXT) \ activeds/libactiveds.$(IMPLIBEXT) \ advapi32/libadvapi32.$(IMPLIBEXT) \ advpack/libadvpack.$(IMPLIBEXT) \@@ -580,6 +582,9 @@ implib: $(IMPORT_LIBS)
.PHONY: implib
+acledit/libacledit.$(IMPLIBEXT): acledit/acledit.spec $(WINEBUILD)
@cd acledit && $(MAKE) libacledit.$(IMPLIBEXT)activeds/libactiveds.$(IMPLIBEXT): activeds/activeds.spec $(WINEBUILD) @cd activeds && $(MAKE) libactiveds.$(IMPLIBEXT)
diff --git a/dlls/acledit/Makefile.in b/dlls/acledit/Makefile.in new file mode 100644 index 0000000..83565b7 --- /dev/null +++ b/dlls/acledit/Makefile.in @@ -0,0 +1,14 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = acledit.dll +IMPORTLIB = libacledit.$(IMPLIBEXT) +IMPORTS = kernel32
+C_SRCS = \
main.c+@MAKE_DLL_RULES@
+@DEPENDENCIES@ # everything below this line is overwritten by make depend diff --git a/dlls/acledit/acledit.spec b/dlls/acledit/acledit.spec new file mode 100644 index 0000000..9448623 --- /dev/null +++ b/dlls/acledit/acledit.spec @@ -0,0 +1,8 @@ +#4 stdcall DllMain +1 stub EditAuditInfo +2 stub EditOwnerInfo +3 stub EditPermissionInfo +5 stub FMExtensionProcW +6 stub SedDiscretionaryAclEditor +7 stub SedSystemAclEditor +8 stub SedTakeOwnership diff --git a/dlls/acledit/main.c b/dlls/acledit/main.c new file mode 100644 index 0000000..b73a8e3 --- /dev/null +++ b/dlls/acledit/main.c @@ -0,0 +1,52 @@ +/*
- Implementation of the AclEdit Interface
- Copyright 2006 Eric Pouech
- This library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser 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 library 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
- Lesser General Public License for more details.
- You should have received a copy of the GNU Lesser 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
- */
+#include <stdarg.h>
+#include "windef.h" +#include "winbase.h" +#include "winuser.h" +#include "winreg.h" +#include "winver.h" +#include "winnls.h"
+#include "wine/unicode.h" +#include "wine/debug.h"
+WINE_DEFAULT_DEBUG_CHANNEL(acledit);
+/*****************************************************
- DllMain
- */
+BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) +{
- TRACE("(%p, %d, %p)\n", hinstDLL, fdwReason, lpvReserved);
- switch (fdwReason)
- {
- case DLL_WINE_PREATTACH:
return FALSE; /* prefer native version */- case DLL_PROCESS_ATTACH:
DisableThreadLibraryCalls( hinstDLL );break;- }
- return TRUE;
+}
-- Thanks
Tom
Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet!
http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-ema...
-
Alexander Nicolaysen Sørnes -
Eric Pouech -
Paul Vriens -
Robert Shearman -
Stefan Dösinger -
Tom Spear