I used OpenService function in a VB.NET project and it works without problem in Windows7 or Windows XP.
Something like that:
hService = OpenService(hSCM, sServiceName, ACCESS_TYPE.SERVICE_QUERY_CONFIG Or ACCESS_TYPE.SERVICE_CHANGE_CONFIG)
The same function in Windows 8 doesn't work... It returns 0 and not the correct service handle.
What's happened in Windows 8? Have you any ideas?
Thank you very much.
Related
On a Windows 10 computer, I am calling QuickBooks from a 4th Dimension (4D) database using a PowerShell script. The script calls the QBXMLRP2.dll, a 32bit COM object, to talk to QuickBooks 2019. As I understand, if you call a 32bit dll using a 64bit version of PowerShell, it will fail and vice versa. However, I'm getting different results depending on if I use a 32bit or 64bit version of 4D. This makes no sense to me. Here are my test results:
OS 4D PowerShell DLL Result
64 32 32 32 OK
64 32 64 32 OK //According to my research this should not work!
64 64 32 32 OK
64 64 64 32 X //According to my research this is the expected behavior
Any thoughts on why the 64bit version of PowerShell/32bit dll works with the 32 bit version of 4D? What I really want is for it to work with the 64bit versions of 4D and PowerShell.
In response to questions... Here is what I am doing. 4D first creates a .ps1 script file and saves it to disk, then launches PowerShell in an external process. For example, this would launch 64bit PowerShell (Windows 10) and PowerShell would execute the previously saved script:
"C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -file \""+$ScriptPath+"\""
The PowerShell script looks like this:
[String]$requestXML = '<?xml version="1.0" ?>
<?qbxml version="2.0"?><QBXML>
<QBXMLMsgsRq onError="stopOnError">
<CompanyQueryRq requestID="1">
</CompanyQueryRq>
</QBXMLMsgsRq>
</QBXML>'
$myQBXMLRP = New-Object -com QBXMLRP2.RequestProcessor
$myQBXMLRP.OpenConnection2("qb4D","CCFolioPro",1)
$ticket = $myQBXMLRP.BeginSession("C:\Company Files\Cadinha & Co.,LLC.QBW",$myQBXMLRP.qbFileOpenDoNotCare)
$myQBXMLRP.ProcessRequest($ticket, $requestXML) > $env:_4D_OPTION_OUTPUT_STREAM
$myQBXMLRP.EndSession($ticket)
$myQBXMLRP.CloseConnection()
"Stop" > $env:_4D_OPTION_STOP_TOKEN
As I understand, 4D is out of the picture once PowerShell is launched. 4D does not interact with the dll. It's all PowerShell/dll (COM)/QuickBooks.
With the help off this forum and a bit more research, I understand now that in a 64bit windows operating system, if the OS detects that a 32bit application is making a call to the System32 directory, it will automatically redirect the call to the SysWow64 directory. Thus in my scenario 32bit PowerShell will always run when called from 32bit 4D. Note that this redirect is only in play when the calling app is 32bit on a 64bit machine. So if a 64bit application (4D) cals the 64bit PowerShell in the System32 directory the redirect will not occur. In this case if a 32bit dll is invoked by PowerShell, it will fail. PowerShell/dll must match bitness.
If one wants to force the 64bit version in the System32 directory to run from a 32bit application, the special "Sysnative" directory can be used instead of the System32 directory. Note that this is a virtual directory. You will not find it in the file system. Again,if you do force the use of the 64bit Powershell and PowerShell tries to invoke a 32bit dll, it will fail.
The following article is a very good read...
https://learn.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector
Here is my corrected testing chart...
OS 4D PowerShell DLL Result
64 32 32 32 OK
64 32 64-OS->32 32 OK //OS redirected to 32bit PS. Expected behavior!
64 64 32 32 OK
64 64 64 32 X //No redirect. Expected behaviour
I am using Windows 7 as well as windows 2008 r2, I am trying to write a powershell script to find all the software installed on all the machines on my network. I have done research and see the cmdlets I need to do this task but I get some many unrecognized cmdlts. I am new to powershell and the other admins only use GUI's and I am trying to show them how powerful the command line can be. Is there something I need to run to update my machine with the latest cmdlets?
$PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
3 0 -1 -1
currently the command that is failing is Get-RemoteProgram
I am using 64-bit machines
Assuming that you are using thisGet-RemoteProgram, you need to "dot source" it before you can use the command. This tells your script to read the file and include the functions it contains in your script.
. .\Get-RemoteProgram.ps1
Load the function into memory by dot-sourcing the script file this makes the Get-RemoteProgram function available in your current session of PowerShell
So your script would need to include
. .\Get-RemoteProgram.ps1
prior to any call to Get-RemoteProgram
As far as the version of PowerShell, 3.0 is certinaly not the latest. You can always find the latest version at Microsoft. Currently, https://msdn.microsoft.com/powershell is a good place to reference, or even check Wikipedia--lots of places are kept updated with the latest info on PowerShell.
I want to know the result of following command for Windows 10 OS.
wmic os get Name,Version,CSDVersion /VALUE
Since, I don't have Windows 10 installed. Can someone please help me with this.
I have got following result when I have tried Command.
Caption=Microsoft windows 10 Pro Technical Preview
CSDVersion=
Version=10.0.09926
I've got a legacy application that creates an email message with an attachment. The code uses the MAPI interface to create the message. This code has worked for quite some time.
When the application is run on a Windows 7 64 bit machine, the call to MAPILogon fails with a generic error code.
Is there an incompatibility with MAPI and Win7 64? Or is there some COM issue that I am not aware of?
It looks like the problem depends on which API calls you are using.
Calls to MAPISendMail should work without a problem.
For all other MAPI method and function calls to work in a MAPI application, the bitness (32 or 64) of the MAPI application must be the same as the bitness of the MAPI subsystem on the computer that the application is targeted to run on.
In general, a 32-bit MAPI application must not run on a 64-bit platform (64-bit Outlook on 64-bit Windows) without first being rebuilt as a 64-bit application.
For a more detailed explination, see the MSDN page on Building MAPI Applications on 32-Bit and 64-Bit Platforms
I experienced something like this with a legacy application using Crystal Reports 8.5. The CR report viewer has an "Export" button which brings up a dialog which lets you pick a "Destination", one of which is "Microsoft Mail (MAPI)". Exporting to MAPI was failing on Windows 7.
Apparently the problem was due to Microsoft dropping support for "Simple MAPI" in Windows 7.
We were able to resolve the problem with this hotfix from Microsoft:
http://support.microsoft.com/kb/980681
Here's some other discussion which might be helpful for anyone with a similar problem:
http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/ff8c9af5-faca-4e53-b6eb-121e0061170f
https://forums.sdn.sap.com/thread.jspa?messageID=9028744
Try this
#echo off
REM NOTE: The MAPI32.dll must be included in the same directory as this patchfile!!
REM NOTE: change the username to corresponding if you're not on a domain remove #domain
takeown /f c:\windows\system32\mapi32.dll
cacls c:\windows\system32\mapi32.dll /G administrator#domain:F
ren c:\windows\system32\mapi32.dll c:\windows\system32\mapi32.dll.ORIGINAL
copy mapi32.dll c:\windows\system32\mapi32.dll
if NOT '%PROCESSOR_ARCHITECTURE%'=='AMD64' goto END
takeown /f c:\windows\sysWOW64\mapi32.dll
cacls c:\windows\sysWOW64\mapi32.dll /G administrator#domain:F
ren c:\windows\sysWOW64\mapi32.dll c:\windows\sysWOW64\mapi32.dll.ORIGINAL
copy mapi32.dll c:\windows\sysWOW64\mapi32.dll
:END
not sure specifically in regards to MAPI, but can be if its done in .NET
After testing a while with the Cmd.cmd framework in python, I noticed a problem I don't know what to do about. Plus I believe to have this working some hours before (or I'm just crazy), so this is even more weird.
I have the following example code, tested on both Windows and Linux systems (so it's not a Windows problem), but tab completion simply doesn't work.
If I use the exact same code in Python 2 it does work on the Linux system (not on the Windows one though)
import cmd
class Shell ( cmd.Cmd ):
def do_test ( self, params ):
print( 'test: ' + params )
def do_exit ( self, params ):
return True
def do_quit ( self, params ):
return True
if __name__ == '__main__':
x = Shell()
x.cmdloop()
Do you know why this happens, or what I can do, to make tab completion possible?
It actually works for me on Linux on both Python 2 and 3. However, my python setup was compiled with readline support, which is required for it to be automatic per the cmd documentation. I suspect your Linux Python 3 wasn't compiled with it.
Unfortunately, readline is Unix-specific. See python tab completion in windows for a discussion of other options on Windows.
I got it to work on windows after I installed the pyreadline module from here https://pypi.python.org/pypi/pyreadline/2.0
On Mac there is the Stand-alone GNU readline module.
You can get it with pip install gnureadline.
It has been tested with Python 2.6, 2.7, 3.2 and 3.3.