You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 4, 2018. It is now read-only.
Presently, there are three Platform/Invoke calls that invoke routines that currently exist only as 32 bit routines. The first of the two calls GetExeSubsystemW_WW, a custom routine that expects the fully qualified name of the main assembly, and returns the numeric ID of the Windows subsystem in which the calling assembly runs. The second entry point, SHS_StandardHandleState, expects an integer that maps to one of the standard console streams, and returns an integer that corresponds to the current state of the stream (0 = Undetermined/error, 1 = Attached to Console, 2 = Redirected). The third is SHS_GetStdHandleFNCLI, which takes a handle ID (the same ID that you specify to SHS_StandardHandleState), a pointer to an uninitialized buffer that receives the file name, and the size, of the buffer, in bytes. All three P/Invoke calls are implemented in IP6CUtilLib1.cs. Archive Current_32Bit_Native_API.ZIP contains the C source code of the four routines. While this isn't quite everything you need to build the 32 bit project, it's enough to help you figure out what the 64 bit implementation must accomplish.
Of the three routines, GetExeSubsystemW_WW is the least important, because I have devised a 100% managed implementation of it. However, so far as I can tell, there is no way around calling into the Windows API to satisfy the requirements of the other two.
The final challenge to resolving this issue is something that I simply have yet to investigate, but I feel sure is feasible in managed code, and that is to determine whether the assembly is running in the 32 bit or 64 bit subsystem on a 64 bit CPU, in order to determine which libraries to load and use.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Presently, there are three Platform/Invoke calls that invoke routines that currently exist only as 32 bit routines. The first of the two calls GetExeSubsystemW_WW, a custom routine that expects the fully qualified name of the main assembly, and returns the numeric ID of the Windows subsystem in which the calling assembly runs. The second entry point, SHS_StandardHandleState, expects an integer that maps to one of the standard console streams, and returns an integer that corresponds to the current state of the stream (0 = Undetermined/error, 1 = Attached to Console, 2 = Redirected). The third is SHS_GetStdHandleFNCLI, which takes a handle ID (the same ID that you specify to SHS_StandardHandleState), a pointer to an uninitialized buffer that receives the file name, and the size, of the buffer, in bytes. All three P/Invoke calls are implemented in IP6CUtilLib1.cs. Archive
Current_32Bit_Native_API.ZIP contains the C source code of the four routines. While this isn't quite everything you need to build the 32 bit project, it's enough to help you figure out what the 64 bit implementation must accomplish.
Of the three routines, GetExeSubsystemW_WW is the least important, because I have devised a 100% managed implementation of it. However, so far as I can tell, there is no way around calling into the Windows API to satisfy the requirements of the other two.
The final challenge to resolving this issue is something that I simply have yet to investigate, but I feel sure is feasible in managed code, and that is to determine whether the assembly is running in the 32 bit or 64 bit subsystem on a 64 bit CPU, in order to determine which libraries to load and use.
The text was updated successfully, but these errors were encountered: