Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I really like the way the SysInternals utilities (e.g. Process Explorer) handle 64bit compatibility. It looks like the 32bit executable has the 64bit version embedded in it, and extracts it if necessary.
I'd like a tool which automates this - i.e. takes 32bit and 64bit executables, packs them together somehow, and inserts stub code to launch the right executable according to which platform its gets run on.
Before I start to roll my own, does anyone know of something like this which already exists?
This appears to have been covered already (although it's quite shallow on detail) within...
Roll 64-bit and 32-bit versions of an app into the same binary?
Mark Russinovich of SysInternals fame describes their method here. They do embed an x64 image in an x86 image. Unfortunately above blog post doesn't actually go into too much detail but mentions that their technique is based on a much older article found here.
Not a tool, but it seems fairly easy to embed your executables in a VC++ project as resources, and run the correct one after checking the OS environment.
Use the IsWow64Process function to detect 32 or 64 bit, and here is a nice writeup including source code on how to embed the executables: http://www.codeproject.com/KB/winsdk/binaryresources.aspx .
While this is possible, I would consider it a bad practice since most of those applications (e.g. Process Explorer) extract that file in working directory. If you like to put programs in "Program Files" folder, that clashes with that directory being read-only.
For me it just seems easier to have two programs separated and make shortcut just to x86 file. If that version detects 64-bits, it just needs to launch x64 file.
If you have really good reason to combine those two, than embeedding it as resource seems like a correct path.
Here is a guide to compiling an AutoIT script which does the job, although you don't have any control over how the packing & stub launcher works.
I will reproduce the AutoIT script here in case the link disappears:
; Check if we’re on 64-bit OS…
If EnvGet(“PROCESSOR_ARCHITEW6432″)=”” Then
; No we’re not – run x86 version…
FileInstall(“D:\Support\ETrustCheck_x86.exe”,#TempDir & “\ETrustCheck_x86.exe”)
RunWait(“D:\Support\ETrustCheck_x86.exe”,#TempDir & “\ETrustCheck_x86.exe”)
FileDelete(#TempDir & “\ETrustCheck_x86.exe”)
Else
; Yes we are – run x64 version..
FileInstall(“D:\Support\ETrustCheck_x64.exe”,#TempDir & “\ETrustCheck_x64.exe”)
RunWait(“D:\Support\ETrustCheck_x86.exe”,#TempDir & “\ETrustCheck_x64.exe”)
FileDelete(#TempDir & “\ETrustCheck_x64.exe”)
EndIf
; The END
This script can be wrapped by the AutoIT script editor into 32bit launcher with your two executables packed into it.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
In recent versions of PE files there is a stub to show for MS DOS users the sentence This program can not be run in DOS mode. Why such message still exists althogh it wastes about 38 bytes? Is there any one still uses MS-DOS?
It's still there because there's no easy way to remove it without breaking the file format, and nobody seems to think 38 bytes per executable is worth the trouble. The requirements on section alignment nearly always "waste" a lot more than that anyway.
Somewhere, someone is still using DOS. And, for backwards compatibility issues, the 38 bytes still need to be there. Even if no one is using DOS.
You would be amazed to know how many hoops the Windows code jumps through to remain backwards compatible.
When the PE format was introduced (year 1994, Windows NT 3.1), DOS was still very much around. The risk that a Windows EXE would be run from DOS by mistake was very real. So they needed to make Windows EXE's superficially compatible with the DOS loader. So that in such a scenario the program would do something (i. e. print a message and quit) instead of crashing randomly.
Obviously, somehow modifying the DOS loader to recognize the Windows EXE's was not an option. And there was no "platform/architecture" identifier in the DOS exe header, like in PE - there was no built-in mechanism for future introduction of incompatibility. Also, "This is a Windows program, please run under Windows" is a much friendlier message that "This program is not compatible with your system".
The DOS stub was also a part of the older 16-bit Windows EXE format ("NE" for "New Executable"). The path to the stub was even a settable linker parameter, so that making a "fat binary" of a sorts was possible - the Windows bits would be your program for Windows, and the DOS stub would be the same program (i. e. same functionality) for DOS. AFAIK, very few people ever took advantage of that.
While Disk Operating System (DOS) is not in use these days, DOS-mode which is basically command line (or console mode) still exists and very popular. By DOS-MODE it probably means commandline mode. Console Application are very popular and used everywhere esp in test and development environment.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Linux utilities like sed, awk and other shell scripting features are awesome and life becomes a lot harder when I am developing on windows and cant use any of these.
People suggest to use cygwin for those who want the linux like tools under windows. But I feel cygwin will be an overkill for someone who only wants to use the handful commands.
Some say that Windows Services for Unix can also be a good alternative.
I have used none of these. Can some experienced programmer suggest best/simplest way to do this? of course apart from switching to linux itself.
I think the GnuWin32 project is exactly what you're looking for. Unix command line tools ported to Windows.
I've been using UnxUtils which are ports of common GNU utilities to native Win32 for ages.
I should add that I've also used Cygwin (et al.) and Microsoft's Services for Unix and neither of them were any good for me because they don't work as well as native versions from the command prompt, and using ksh/bash/whatever under Windows never really works right, even though I use ksh under unix all the time.
I tried something like this quite often, but to be honest, none of it really works well.
I therefore suggest using a virtual machine (such as VirtualBox) and install a small linux inside that. You can easily move files from and to the guest system with shared folders.
Judging by my experience, it is the best solution I used so far.
I tried Gow for some time, and it's nice. It offers 130 Unix-shell utilities for Windows. The contextual menu in the File explorer, to start a prompt in the current folder, is really handy.
There's a GNU port of many of the utils. I find that quite useful.
If you need Perl, I recommend Strawberry Perl.
The problem with most of the tools suggested here is that they don't get updated very often E.g. the last update GnuWin32 got was on 27 December 2010; UnxUtils was last updated on 01 March 2007.
I suggest MSYS2, a very good option which has a Win32 port of Arch's pacman package management system built-in. It's a spin-off from Cygwin like MSYS but much better than MSYS (lots of packages and gets updated almost daily) and (very light as opposed to) Cygwin.
It's a rolling release distribution that works under Windows and thus you get the latest and greatest of the packages. MSYS2 additionally has MinGW, provided in both x86 and x86_64 flavours. They've their own list of packages - MinGW packages.
Maintainers are very affable too.
MSYS is a common alternative for people who find CygWin excessive. It's still a special prompt, but it was originally intended to set up just enough Unix-compatibility to build programs using the MinGW compilers and the typical configure/make routine.
Using tools like sed and awk isn't going to work quite as expected in a normal Windows command prompt. It can be done to a point, but common usage involves command-line syntax that is normally interpreted by the shell, but which the Windows command prompt doesn't support. One example is wildcard file specifications. I've often found that Unix-centric tools aren't as usable on Windows as they assume the shell has expanded those wildcards into lists of files for them.
Install msysGit (netinstaller), it comes with a (msys/minGW) shell environment.
It also adds a "open shell here" in explorer.
It's faster than Cygwin, but at the sacrifice of unix compatibility.
Maybe it is stupid, but I usually search google for i.e.: "indent windows". You can select tools from mixed platforms. Lot of stuff from open systems has been ported on windows.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
The community reviewed whether to reopen this question 11 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm looking for cross-platform scripting (language) for windows, Linux, MacOS X.
I'm tired of .bat / bash .
I would like to do things like for example ,,lock workstation'' at automatic login (I had this in X-Window but the solution was pretty ugly; now, I would like that on MS Windows and not that ugly :-) ).
Generally: automate tasks.
Or would I be better off with Windows Scripting Host?
PowerShell also comes to mind, but that's seems to Windows-only for my taste.
Can languages like Python, Ruby, (Java?) interact (elegantly? sensibly?) with WSH?
Also things like DBUS, DCOM, etc come to mind as part of the picture.
Currently I use a mixture of Java, .bat, bash, Ruby, Scala; some VBA for Excel. Which sometimes gets pretty ugly.
I would like a cross-platform general solution with/using ,,native'' parts close to OS-specifics. Like e.g. Ruby driving some Windows-specific stuff (just a guess).
What do You use?
TIA
I'm a huge fan of Lua:
Syntax is vaguely Pascal-like and works well in scripts.
Superb power-to-weight ratio. Superb engineering. Very good design.
Extremely portable to any platform with an ANSI C compiler.
GUI support through wxLua and other bindings
Some support for hiding OS differences in common tasks, e.g., the Lua File System add-on
The core system and libraries are simple enough that you can understand all of what you're using, but still have excellent leverage compared to bash/bat. Expressive power is comparable to Python or Ruby.
You're not overwhelmed with libraries and frameworks, which can be a plus or a minus.
There is an excellent book: Roberto Ierusalimschy's Programming in Lua; you can get the previous edition free online.
Performance beats tcl, perl, python, ruby
For even faster performance on x86 hardware, there is LuaJIT.
Finally, and this is the ace in the hole: if you run into any kind of platform-specific problem, it is easy to write platform-specific C code and load it into a Lua script dynamically. Lua was designed with this task in mind and does it extremely well. You can also easily dip into C for performance (e.g., compute MD5 checksum).
Over the last 3 to 5 years, I have been gradually migrating scripts from bash/ksh/awk/sed/grep/perl into Lua. I have been very happy with the results.
You could try Batsh
Batsh is a simple programming language that compiles to Bash and Windows Batch. It enables you to write your script once runs on all platforms without any additional dependency.
Perl and Python are both available on almost every platform
I think you're juggling on the edge of contradictory: you would like platform-independent (commendable) but also "close to OS specifics".
If, however, you put a bit more emphasis on platform independence, I've been entertaining the idea of using groovy (a more java-friendly relative of ruby) for general purpose scripting. When you need it, you get OS-specific behaviour by invoking OS shell commands.
My motivation is a bit different: I find groovy code to be more robust than that of bash, although I too will need a good multi-platform scripting tool for a project I'm developing.
You could write your scripts in Tcl.
the syntax is simple and closer to
what you'd expect from a script;
it is cross-platform, and will run on all major platforms;
you can easily create simple GUIs for your scripts in Tk, which will also work everywhere and use native controls;
for the Windows-specific functions,
you can use Twapi (Win32 API
bindings).
you can install a Tclkit, which is a single file that is the whole Tcl distribution. There's no lengthy install process or hidden files or mysterious directories;
you can easily put a linux, windows and mac runtime on a single flash drive so you always have an interpreter handy even if there's not one installed locally.
Like e.g. Ruby driving some Windows-specific stuff
It certainly can and on the Ruby on Windows blog you can find lots of examples also there's a chapter in the Pickaxe book and in the humble one.
there is possibility for UNIX and UNIX like platforms in shell, but I don`t think that this what you are asking for is possible in any scripting language because of windows.
For UNIX systems you can use this:
#!/bin/sh
TYPE=`uname`;
echo 'this is ' ${TYPE};
if [ ${TYPE} = HP-UX ]
then bdf /var;
elif [ ${TYPE} = Linux ]
then df -h /var;
elif [ ${TYPE} = FreeBSD ]
then df -k /var;
else echo "Unsupported OS - ${TYPE}"
fi
I hope it will help you!
source
I would use C# with Mono.
Not sure if you still need it, but if so, try ant ( http://ant.apache.org/ ). It's a cross platform "script language". Basically, a ant file is a xml file interpreted by a JVM programm.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
What if I want to run native Unix-like applications on Windows? What's the best application out there?
Cygwin is closest to what you are looking for, though not exactly like Wine.
Cygwin is a Linux-like environment for Windows. It consists of two parts:
A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.
A collection of tools which provide Linux look and feel.
It is not binary-compatible with Linux applications, you still need to rebuild them from source to run under Cygwin. Once rebuilt, however, they should work exactly like on Linux.
Not quite the same, but you could also run a full linux installation inside a VM such as Virtualbox: http://virtualbox.org/
Take a look at andLinux (based on coLinux).
From the site:
andLinux is a complete Ubuntu Linux
system running seamlessly in Windows
2000 based systems (2000, XP, 2003,
Vista; 32-bit versions only).
...
Although this technology is a bit like
running Linux in a virtual machine,
coLinux differs itself by being more
of a merger of Windows and the Linux
kernel and not an emulated PC, making
it more efficient. Xming is used as X
server and PulseAudio as sound server.
andLinux is not just for development
and runs almost all Linux applications
without modification.
Not Cygwin.
What Isn't Cygwin?
Cygwin is not a way to run native linux apps on Windows. You have to rebuild your application from source if you want it to run on Windows.
Cygwin is not a way to magically make native Windows apps aware of UNIX ® functionality, like signals, ptys, etc. Again, you need to build your apps from source if you want to take advantage of Cygwin functionality.
Cygwin will give a Linux-like shell but can not directly run linux applications in Windows. Cygwin "acts as a Linux API emulation layer providing substantial Linux API functionality."
At one point in the distant past, there was LINE Is Not an Emulator, which aimed to be exactly the inverse of Wine: provide binary compatibility for Linux executables running under Windows.
It kinda worked, at least as a proof of concept, but there isn't a big need for it.
If you're interested in porting those *nix applications to a Win32 environment, you might take a look at the MinGW project. I've mainly used it for GCC on windows, but they also provide an interesting environment called MSYS:
A Minimal SYStem providing a POSIX
compatible Bourne shell environment,
with a small collection of UNIX
command line tools. Primarily
developed as a means to execute the
configure scripts and Makefiles used
to build Open Source software, but
also useful as a general purpose
command line interface to replace
Windows cmd.exe.
Microsoft, for a while, offered SFU which sort of works for some things. Cygwin works much better.
If you're hoping for ABI Compatability, as wine offers unix systems for windows binaries, things are quite bleak. CoLinux also sort of works, but generally won't help you at all with any kind of graphical application, unless you configure a windows X11 server as well.
I've used andLinux which is built on coLinux. The organization has compiled an Ubuntu installation (Gutsy, I think, but I upgraded to Intrepid pretty easily).
One warning: development on andLinux is pretty slow -- the last beta has been out for almost a year.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Does anyone know of free tools (languages, environments) that would support development of GUI applications on the Windows platform?
I am looking to be able to create a single executable file that has no dependencies on any external runtime or library.
I would like to be able to then run this EXE in a very similar manner to Process Explorer or Autoruns from SysInternals. In other words; a no installer, portable application.
This application must also provide a reasonably rich windowing (controls, widgets etc) user interface and should run on Windows 2000, XP, Vista and later.
I'm aware of C/C++ but I'm looking for an environment/language that provides more specific and faster support for GUI development. Also, Delphi costs money.
For quick prototyping, Autoit is a viable option (but it is a scripting language though).
Combined with Scite as an Editor, and autoit to exe capability (AutoIt3.exe in Scite and Autoit3Wrapper.exe to actually produce exe), you have a full GUI development environment.
AutohotKey is an alternative, but based on old AutoitV2.
Still, you can execute AutohotKey scripts from Autoit ;)
Run("c:\Program Files\Autohotkey\Autohotkey.exe c:\scripts\devicesset.ahk")
While interactive debugging is not natively supported, they are (2008, but in 2014: was?) several debugging tools to facilitate the debug process. (from this ticket)
Update 2014: the "AutoEditDebugger" might not be supported:
EDIT October 2009: NB This script has not been maintained since some time in 2008. Due to some problem with the editor it crashes in Vista.
Delphi is definitely a good way to go. There is a free version called Turbo Delphi.
The version available is a couple of years old, so it's a shame they haven't release Turbo versions of the new stuff.
There are also trials available of the full fledged RAD Studio, but I don't think that's what you're looking for.
You can Get Turbo Delphi and Turbo C++ Builder explorer editions for free, and you can develop with them native application that you can have only .exe file without any dependencies on any windows version from (win98 to win7), both of them include more than 200 components, and you can use more (without installing to IDE that the only restriction), and you develop with them free and commercial software.
Delphi is the most RAD(Rapid Application Development) IDE that you can use to produce windows application in very easy and efficient way, you get fast developing application with fast execution time compared to speed of C++.
Another option to use Lazarus IDE, which based on FreePascal compiler, so you can have your application running on windows/linux/MacOS/Unix and more.
Visual C++ Express + WTL. Both are free. WTL is a relatively good(1) windowing library. No wizards, though, and you have to have good understanding of the Win32 windowing system.
You can also use Visual C# Express along with Mono to build WinForms app. While the end result is not technically a standalone executable and requires a framework, Mono dlls can be distributed along your exe (2), so you can just have a single folder for xcopy deployment. (And I think on Windows with .Net installed, your exe will be run on .Net automatically)
(1) I am spoiled by WPF. :-)
(2) Read on the intertubes. I have not personally tried it, though.
Perhaps not an option given your statement regarding C++, but if you are developing an open source / free application then Qt is a very nice GUI toolkit with designer.
Also, wxWidgets is a very functional toolkit that will allow you to deploy a single exe, although the best GUI designers are not free.
Maybe D is an option? A friend of mine blogged about a GUI Designer for D here and I believe that the resulting executable has no dependencies.
Just use VS.NET with C and Win32 api.
No runtime needed of course, as the CRT is native.
You should use Digital Mars C/C++ in pure C and program with GDI32 functions of WIN32 API (Just #include ). Don't forget to link your binary object executable with gdi32.lib.
Check out Microsoft's Express editions of their developer tools.
If you're doing very simple applications, AutoIt might be an option as it requires no runtime files and its executables will even run on WinPE. It's a bit primitive though and not exactly object-oriented. It works a bit like the old VB. It is, however, free and easy to learn and apart from something like NSIS (NullSoft Install System) there aren't many free, standalone GUI creators.