I'm porting C/C++ code from Unix to Windows that makes use of the symlink() function.
From what I understand, recent Windows file systems have a equivalent of symbolic links.
What would be the best / most portable way replace the symlink() function, so the same code works on both platforms ?
Since Windows Vista there's a function to create true symbolic links: CreateSymbolicLink
Note that Junctions as mentioned in the other answers only support directories, and even with the newer feature, windows symbolic links require you to specify whether the target is a directory or a file. So you won't necessarily be able to get a trivial "drop-in replacement" symlink() function.
The underlying technology on Windows is called Junction points. The Boost Filesystem Library is cross platform and can make symlinks:
http://www.boost.org/doc/libs/1_46_1/libs/filesystem/v3/doc/reference.html#create_symlink
Junctions seem to be the answer from similar questions .
Related
I have a .go file and produced the binary file using go build command from Mac. Is there a way to build a binary file which runs in windows,linux,IOS ?
I am aware we can build binary file for each of them by changing the GOOS,GOARCH params but i would like to have a single go binary file which should run in all the platforms . Please help me out of this.
Thanks in advance
No, it is not at all possible in Go or any other programming language (the executable is necessarily tailored to individual platforms and architectures).
However, to cross-compile, some tools do exist which do the cross compiling for you.
This post helps explain how to cross compile with Golang (which is pretty easy at this point).
There's also a Unix StackExchange question, https://unix.stackexchange.com/a/298283/177527, which explains why different architectures require different binaries:
The reason is because the code is compiled to machine code for a specific architecture, and machine code is very different between most processor families (ARM and x86 for instance are very different).
The binary also depends on the OS, as explained here https://softwareengineering.stackexchange.com/a/251255:
Binary Format: The executable has to conform to a certain binary format, which allows the operating system to correctly load, initialize, and start the program. Windows mainly uses the Portable Executable format, while Linux uses ELF.
System APIs: The program may be using libraries, which have to be present on the executing system. If a program uses functions from Windows APIs, it can't be run on Linux. In the Unix world, the central operating system APIs have been standardized to POSIX: a program using only the POSIX functions will be able to run on any conformant Unix system, such as Mac OS X and Solaris.
For Mac (not Windows), you can associate cross-compilation with a tool like randall77/makefat to generate a "universal binary", which will run on any architecture supported by one of the input executables.
This is currently implemented in goreleaser/goreleaser PR 2572, which means the process would be completely automated.
I am working on a compiler for a small (toy) language that produces 16-bit com-files, which are executable in Windows XP. However, in more modern releases of Windows com-files are executable only with the help of tools such as DosBox. I would like my compiler to produce exe-files that can be executed directly in Windows 10.
As I understand it, the exe-file needs a header that instructs the system of how to execute it. My idea is to simply add the header at the beginning of the com-file to extend it into an exe-file. I wonder if anyone can recommend an appropriate tutorial that describes how exe-files works. More specifically, I am looking for a tutorial of how to build the smallest possible working exe-file.
I also wonder if there is a difference between exe-files for 32-bit or 64-bit Windows?
Best Regards,
Stefan
You can download description exe format here. You need pecoff.docx file.
Also you may look on this old but detailed doc here.
I'm fairly new to C++ and I want to make a Program Launcher, All it does is launch applications for me based on text I input.
I all ready have the basic code for it, but I can't seem to find out how to change the working directory. I know you use chdir, but how Exactly.
C++ still has very little standardized support for filesystem functions, in part because it runs on embedded devices which may not have working directories, or sometimes even directories or files at all. So we have to look to the OS API.
For POSIX, there is chdir() and getcwd().
For Windows, there is SetCurrentDirectory and GetCurrentDirectory, although if you want to deal with per-drive working directory, you will need to work with environment variables.
There is an example on MSDN titled Changing the Current Directory
I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.
First, sorry for my poor English...
I want to add a virtual folder to Windows Explorer using a Namespace Extension (NSE), and I want users to be able to open this virtual folder to explore some path (e.g., c:\test).
How can I do this using Delphi? Thanks.
The place to start is the MSDN documentation: Introduction to the Shell Namespace. Naturally this is written from a C++ perspective but it's not too hard to map that across to Delphi.
Another excellent resource for such tasks is Code Project. For example: The Complete Idiot's Guide to Writing Namespace Extensions - Part I by Mike Dunn. In fact this is just part of an excellent series of articles on shell extensions.
At present Delphi is a poor choice because it does not produce 64 bit executables. This means that your shell extension will not run on 64 bit Windows which is now a serious limitation.
With the recent release of Delphi XE2 this limitation has been removed. XE2 is capable of producing 64 bit executables and can therefore be used to produce 64 bit shell extensions.
Basically a shell extension is a COM object that implements a set of interfaces. Which interfaces needs to be implemented depends on the type of the extension (there are some used by any extension, of course).
You can start reading here (you need some C -> Delphi translation, but when you start to work on such matters is better you get prepared to it), and then the reference is of course MSDN
http://www.shellplus.com/examples/namespace-extension-example.html
http://delphipower.tripod.com/winshell.htm