On Windows 10 with linux subsystem you can compile project with debug information that contains paths like this "/mnt/c/" using mingw compiler.
And software like gdbgui tries to open such file using function like
https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-createfilew
and of course it fails
What is the proper way to write such software in cross platform way?
Edit: Possible workarounds
edit compiled binary and change paths
create small utility and hook winapi FileOpen function
Related
As the title said, with any possible tricks or bugs,can we create a binary file can run both on Linux and Windows without any change?
(The file must be directly created by a compiler)
I know it's nearly impossible,but with some tricky methods,is that possible?
I'm porting a linux app on windows and I need dbus-daemon.exe running on my win session.
My app and dbus-daemon.exe work fine but the latter still opens a default console and, being not familiar with programming on windows, I don't know how to get rid of it.
Maybe by making it invisible ?
Windows, by default, opens a console window for executables compiled for the console subsystem (the "subsystem" being essentially a bit of metadata in the Portable Executable format, aka EXE/DLL). So you have at least two options:
Compile the dbus-daemon for the Windows subsystem, if you're the one doing the compilation. It is a linker option.
Launch the dbus-daemon process passing the CREATE_NO_WINDOW flag to the relevant API function (probably CreateProcess). If you're not using the Windows API directly, look how CreateProcess and CREATE_NO_WINDOW are exposed in the API you are using. In .NET, for example, it's the ProcessStartInfo.CreateNoWindow property.
I have a few things like running SFC, defrag, and reset the page file and so on, things that can be done within windows VBScript, I am just wondering if I can compile that code as a resource and call it as needed. Thanks.
Lee
You can use the Windows Script Host interfaces, IActiveScript and IActiveScriptParse, to execute Javascript/VBScript from memory. You can then compile your Javascript/VBScript into a resource, extract it at runtime, and then execute it when needed.
Update: have a look at this blog article:
Adding Active Scripting to your
Delphi Win32 application
And then look at this discussion to make it work in 64bit:
Writing a scripting host in Delphi XE2 64-bit
I need to use the debug command in Windows 64x for learning purposes. When I type the command debug in the cmd, I get the following message:
'debug' is not recognized as an internal or external command,
operable program or batch file.
As I understand from some previous posts that debug does not work in 64x systems. Is there any work around for this issue?
EDIT:
I am trying to write assembly code for learning. I am not allowed to use any other option for writing assembly code. I have to use DEBUG.
debug.exe is not available in any of the 64 bit windows versions. What are you trying to accomplish? One option for you may be gnu debug - http://www.sourceware.org/gdb/
I know this is an ancient thread, but others might have the same question.
In general to use legacy software, the CLEANEST way to do it is to use the build in Hyper-V. And then have PC-DOS 3.30 (or any suitable 16 or 32 bit OS) on that.
Make sure to use a DYNAMIC disk (vhdx). This allows the disk to be mounted in Windows simply by clicking the vhdx (when not in use by Hyper-V - no sharing), so this allows for simple transfers, without complex net-setup.
There are other alternatives such as DOSBOX, though to my experience their emulation have some bugs (e.g. on the ancient FCB-system - older than file-handles)
I know it's a very long answer, but I just saw your post now. Use the vDosPlus (http://www.vdosplus.org/) or vDos (https://www.vdos.info/) software to run 16-bit (MS-DOS) programs on Windows 64-bit.
I remember a few years ago(2002) there was a multipartite virus that could be run natively on linux and windows. I don't know if a compiler could be specially craft an executable so that it could be read as both ELF and PE, so that the os would start executing at different entry points. Or a program that could merge two programs, one compiled using mingw, one compiled in native linux, to one program.
I don't know if such a program exists, or could it exist, and I'm know this could be implemented in Java or some scripting language, but that's not a native program.
Imagine the possibilities, I could deploy a program with linux and window (and perhaps os/x)libraries, and one main executable that could be run on any os. The cross-platform support would compensate the bigger size.
Windows programs have a DOS stub in the beginning, and I just ran an ELF executable through debug.com, which said that the first instruction of this exe was JG 0x147. Just maybe something could be done with this...
No.
Windows and Linux use vastly different binary file formats. See Portable Executable (Windows) and Executable and Linkable Format (Linux).
Something like WINE will run Windows executables on Linux but that's not the same thing.
This is actually a really terrible idea for multiple reasons.
Cross-compiling across operating system boundaries is extremely difficult to do properly.
If you go for the second route (building separate PE binaries on Windows and ELF on Linux, and then somehow merging them) you have to maintain two machines, each running a different OS and the full build stack, and you'd have to make sure that you tested both versions separately before gluing them together.
Dynamic linking is already a pain to properly manage, on Windows and on Linux; static linking can generate binaries that are much more inconvenient to deal with than whatever imaginary benefits you get from providing one single file type to your end-user.
If you want to run the same binary executable file on multiple OSes, your options are Java, Mono, and potentially NativeClient, the browser plug-in Google's developing to work around the "webapps are too slow" problem.