How does one get the name of the computer on macOS with Delphi?
I am trying to automatically get and display the computer's name in my application but cannot seem to get it working on macOS. I have it working on Windows but can not get it working on macOS.
This code will retrieve the computer name on macOS:
uses
Macapi.Foundation, Macapi.Helpers;
function GetComputerName: string;
begin
Result := NSStrToStr(TNSHost.Wrap(TNSHost.OCClass.currentHost).localizedName);
end;
If you're after cross-platform way of doing it, refer to the GetDeviceName method (named that way since it also deals with mobile devices), here:
https://github.com/DelphiWorlds/Kastri/blob/master/Core/DW.OSDevice.pas
this lib support WIN and linux, it may work with macOS ...
https://github.com/RRUZ/tsmbios
use gethostname() in the Posix.UniStd unit
How can I use Whole Program Optimization feature in Free Pascal 2.7.1 on Windows?
I get this error:
Project1.dpr(92,1) Fatal: Cannot find "nm.exe" or "" to extract symbol
liveness information from linked program
The problem is the WPO is trying to extract symbols from your executable using NM. NM is not available for Windows.
The good news is, Windows has DumpBin instead. I think you can use this directly in place of NM.
Windows XP:
I ultimately wanted to install DDD (the debugger). Its not available in binary form for Windows. When I got its source and tried to configure it, it complained that no term caps library was present. So I acquire ncurses and got this after a mostly successfull build using Cygwin Terminal:
../lib/libncurses.a(lib_ttyflags.o)(.text+0x41):lib_ttyflags.c: undefined reference to `_nc_mingw_ioctl'
../lib/libncurses.a(lib_ttyflags.o)(.text+0xd1):lib_ttyflags.c: undefined reference to `_nc_mingw_ioctl'
It works for me when I do this:
configure --enable-term-driver --enable-sp-funcs
make
The --enable-term-driver was needed for "mingw" (I tested on msys, but this should work equally well on cygwin), and --enable-term-driver requires --enable-sp-funcs.
--enable-sp-funcs
compile-in support for extended functions which
accept a SCREEN pointer, reducing the need for
juggling the global SP value with set_term and
delscreen.
--enable-term-driver
compile with terminal-driver. That is used in the
MinGW port, and (being somewhat more complicated)
is an experimental alternative to the conventional
termlib internals. Currently, it requires the
sp-funcs feature to be enabled.
See here: http://lists.gnu.org/archive/html/info-gnu/2011-02/msg00020.html
In this document,
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#paths
To make these device objects accessible by Windows applications, the device drivers create a symbolic link (symlink) in the Win32 namespace, "Global??", to their respective device objects. For example, COM0 and COM1 under the "Global??" subdirectory are simply symlinks to Serial0 and Serial1, "C:" is a symlink to HarddiskVolume1, "Physicaldrive0" is a symlink to DR0, and so on. Without a symlink, a specified device "Xxx" will not be available to any Windows application using Win32 namespace conventions as described previously. However, a handle could be opened to that device using any APIs that support the NT namespace absolute path of the format "\Device\Xxx".
What are the APIs? Let me know some such functions please.
For example, we can have a device sitting in the GLOBAL?? namespace:
GLOBAL??\
COM227
This device we can successfully open using CreateFile:
//Note: we have to prefix it with \\.\ in order to tell CreateFile that
//we want to open something from the Global device namespace.
//Otherwise it will try to open a file
HANDLE hdev = CreateFile("\\.\COM227", GENERIC_READ, 0, null, OPEN_EXISTING, 0, 0);
if (hdev == INVALID_HANDLE_VALUE)
raise new EWin32Exception(GetLastError);
This device (along with every other device in the Win32 Global?? namespace), actually a symbolic link to the "real" device:
GLOBAL??\
COM227 (SymbolicLink) ==> \Device\VCP0
Device\
VCP0 (Device)
So we try to open this real device:
HANDLE hdev = CreateFile("\\.\Device\VCP0", GENERIC_READ, 0, null, OPEN_EXISTING, 0, 0);
if (hdev == INVALID_HANDLE_VALUE)
raise new EWin32Exception(GetLastError);
But it fails with error code 3 (The system cannot find the specified file).
Short:
Works: COM227 (which is an alias of \Device\VCP0)
Fails: \Device\VCP0
The problem is that
#paulsm4 says that CreateFile should work
#larryostermm agrees, and even gives the device path syntax (e.g. \Device\Xxx)
except that it doesn't work
Which means that CreateFile is not one of the "APIs that support the NT namespace absolute path format of \Device\Xxx".
However, a handle could be opened to that device using any APIs that support the NT namespace absolute path of the format "\Device\Xxx".
What are the APIs?
The answers provided so far are misleading at best. They do not answer your question or cover the important distinction between the NT namespace and the other namespaces.
When accessing the NT namespace you need to use the API calls that start with Nt, such as NtOpenFile, if you want to access devices that are only found in the NT namespace of the kernel. For example, a device in \Devices with no symbolic link in \GLOBAL??.
The other calls mentioned above work fine if you are accessing the Win32 device namespace but these require the driver to create a symbolic link in that namespace.
If you want to access a device that is only found in the NT namespace then use NtOpenFile. This is really a very old API call and has drifted in and out of the userpace header files. It is available again and works just fine.
Benjamin -
The simple fact is that you CAN open a "special device file" in Windows, very much as you do in *nix. This is what I tried to say in my original reply. I stand by everything I said in my first post. And I believe the MSDN link I referred to there does a very good job of explaining this, too.
The syntax for a *nix device file is "/dev/SOME_DEVICE". Multiple devices are (by convention, not necessity) distinguished as "/dev/SOME_DEVICE0", "/dev/SOME_DEVICE1", etc. Device files can also be "aliased" using *nix "symbolic links".
The syntax for a Windows device file is a UNC name.
I'm sure you're familiar with UNC shares (for example, "\\myserver\c$").
In all the examples we've discussed above, the server happens to be the local host. Hence "\\.\SOME_RESOURCE_NAME".
It's really as simple as that.
And it DOES work.
Please let me know if you have any further questions.
Thank you in advance .. PSM
The concept of treating a "device" as a "file" is common in *nix (Unix, Linux, Mac OS, etc).
Basically, the MSDN article means that any Win32 API that opens a "file" (either a local disk file, or a UNC resource) could just as easily open a "special device".
A couple of examples:
http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx
CreateFile
WriteFile
ReadFile
CloseHandle
How can I retrieve MAC of network card(s) and what can I retrieve to recognise specific computer and how?
Call Win32's GetAdaptersInfo
Just use INVOKE to call it and pass parms.