In Python I can write
import platform
>>> platform.system()
'Darwin'
>>> platform.release()
'8.11.1'
How can I find out my systems name and release number in Pascal?
There is no universal way, but the for all *nixes including OS X there is baseunix.fpuname
The platform version can be retrieved using the operating system API. The platform and the architecture can be detected using conditional compilation
{$IFDEF DARWIN}
// darwin specific code
{$ENDIF}
{$IFDEF LINUX}
// linux specific code
{$ENDIF}
{$IFDEF WINDOWS}
// windows specific code
{$ENDIF}
{$IFDEF CPU32}
// X86 specific code
{$ENDIF}
{$IFDEF CPU64}
// X86_64 specific code
{$ENDIF}
read more here and here.
Related
I am now faced with the task of managing the LPT port from a program on Embarcadero Delphi XE in Windows 7 (x86) (in the future on Windows 10 (x64)). To begin with, at least blink the LEDs connected to the outputs of the LPT port. The LPT port is organized on a PCI card, which is connected to the computer via PCI-Express and its own driver is installed for it. In device manager, the board is visible as WCH PCI Express=>DUAL SERIAL&&PARALLEL.
There is such a dll: inpout32.dll, there are such functions
function Inp32(PortAddr: Word): byte; stdcall; external 'inpout32.dll';
function Out32(PortAddr: Word; Data: byte): byte; stdcall; external 'inpout32.dll';
That is, to work with the LPT port, you need to specify the port address PortAdr. Where can you watch it? In the "Resources" tab of the driver properties? If the inpout32.dll library is not suitable for Window 10, then what can be used instead?
I googled the query "parallel port control in delphi windows 10" but didn't find anything relevant.
Problem solved. I used the inpout32.dll driver, as the port address I used the address from the "Input / output range (I / O)" from the "Resources" tab of the parallel port driver in the "Device Manager".
PortAdr1 := $EEFC;
PortAdr2 := $EEFF;
Data := 255;
for PortAdr := PortAdr1 to PortAdr2 do
Out32(PortAdr, Data);
I'm writing a set of PowerShell functions that could theoretically be running in an x86, AMD64, ARM, or ARM64 PowerShell process. The script function will launch a specified executable, but first I'd like to check if the executable's "machine type" is actually supported by the current Windows installation.
Examples:
Windows Server 2019 can have its WOW64 compatibility layer removed - I'd like to detect that WOW64 is unavailable before attempting to launch an x86 EXE
Windows 10 on ARM64 supports x86, ARM, and ARM64 executables at the time of writing, but Microsoft is reportedly working on AMD64 (x64) application support through an extension of the WOW subsystem. So, in some future release of Windows, Windows 10 on ARM64 will support AMD64 applications.
Rather than hardcoding a bunch of checks, is there a way to determine whether the native OS or its WOW subsystem can run a given executable?
Ignoring the specifics of the PowerShell language and using pseudocode, the ideal function would be something like:
IsProcessorArchitectureAvailable(strProcessorArchitecture)
strProcessorArchitecture would be "x86", "AMD64", "ARM", or "ARM64"
The function would return True if applications that use the specified processor architecture can run, False otherwise.
Is there a way to do this?
The IsWow64GuestMachineSupported API can be used to determine if WOW64 is turned off or not:
Apps that need to determine if WOW64 is turned off or not. For example,
many apps assume x86-64 systems can always execute x86-32 code at all
times, everywhere. Note that this ability does not exist on WinPE or
Xbox, and it is an optional component in Server.
Using this API you can also check for ARM architectures, see Image File Machine Constants.
There is also IsWow64Process2 which returns the native architecture of the host system.
To call these API's you would need to P/Invoke with C# from PowerShell.
Full C# Example can be found here and PowerShell example here.
I'm developing some "fun" labs for a Computer Architecture course that have students write and run a very minimal OS. I'm following the Bare Bones setup from http://wiki.osdev.org/Bare_Bones and using Richard Hull's precompiled i686 cross compiler (https://github.com/rm-hull/barebones-toolchain).
When I try to write assembly code using %r8d, I get this error
Error: bad register name `%r8'
The Readme says "There are two platform flavors, 32- and 64-bit depending on your host linux environment", but also lists "i686 (32-bit ELF)" as one of the targets.
Am I correct that the source of the problem is that the ELF target is 32-bit? If so, is there an easy way to get a cross-compiler with a 64-bit ELF target up and running?
I assume what the README says refers to the "CHOST" of the compiler, while the "CTARGET" is always i686 (which is 32-bit.) There is no %r8d (or %r8, or any %r{number}) register, so no you can't use it (it's an x86-64/IA32-E register.)
You can see my blogpost on CHOST/CBUILD/CTARGET to understand the relationship between the different names of platforms for cross-compiling.
I'm developing a Qt project on OS X.
I'm using Jni and include the header jni.h present in the Java jdk.
I'm using the function JNI_CreateJavaVM to create the vm, whose symbols are in the libclient.dylib (libjvm.dylib is the symbol link).
The problem is my app is 64 bits, whereas this library is for i386 architecture, so I cannot link/load it.
How can I use this function in a 64 bits application ?
My only choice is to build Qt in 32 bits, but I don't really like this, cause I'll be stuck in 32 bits forever...(unless java provide this lib for 64bits)
Attempting to call SetupDiCallClassInstaller from a program compiled in 32 bit mode fails on 64 bit Windows.
Apparently this is by design, but I'd like to know the reason.
According to MSDN:
Device Installations on 64-Bit Systems:
The 32-bit version of the application must check the value returned by UpdateDriverForPlugAndPlayDevices. If the return value is ERROR_IN_WOW64, the 32-bit application is executing on a 64-bit platform and cannot update inbox drivers. Instead, it must call CreateProcess (described in the Windows SDK documentation) to start the 64-bit version of the application. The 64-bit version can then call UpdateDriverForPlugAndPlayDevices, specifying a FullInfPath parameter that identifies the location of the 64-bit versions of all files.
So it looks like any API that is designed to report ERROR_IN_WOW64 is specifically intended NOT to work in WOW64, a 32bit process has to invoke a 64bit process to call the API.
If you are making that call from a 32bit process on a 64bit OS, it fails because it has to modify some registry keys in the 64bit portion of the registry. Where else if you were to make that call from a 64bit process on a 64bit OS, it would succeed likewise with 32bit process on a 32bit OS.