When downloading the tar file from AdaCore for the GNAT compiler (the libre version), I noticed that there are two exe files for installation purposes:
win32ada-gpl-2010.exe of size 2.67 MB
and
gnat-gpl-2010-i686-pc-mingw32-bin.exe of size 70.2 MB
In the folder containing the second one, there are instructions for the installation and it installs the GPS editor as well.
I have Win XP and chose to install the second exe file. Now I'm thinking that the second one is for a MINGW installation whereas the first exe file is for a native Windows installation. But I can't find information for this. Which of the two exe files is for a normal Windows installation?
Thanks a lot...
Win32Ada I believe is just a set of Win32 bindings for Ada. That's why it is so much smaller.
You might download that if you want to do a lot of Win32 systems programming or GUI work, and don't have a set of higher-level bindings (eg: GTKAda)
Related
I'm currently trying to learn Assembly for x64 Windows. I tried the example code from this Intel website,
but whenever I try to compile it with the command given in the document:
ml64 hello.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Start
I always get an
LNK1104 error
I know that it means the compiler can't find the library file, I googled the problem and quickly found that I need Visual Studio with Windows SDK, which I downloaded and installed. But still can't find a kernel32.lib or user32.lib in any files other than the Windows system files.
I tried everything and I simply can't fix it. I hope someone could help figure this out.
There is a well-known MASM32 SDK available created by hutch--. This package contains the requested libraries in a (legacy) 32-bit version.
But there is also a 64-bit update of that famous package by hutch--:
Current build of the 64 bit MASM SDK.
It should contain the .inc and .lib files you need and more...
This is the current build of the 64 bit MASM SDK. This one is a lot closer to complete and with the correct Microsoft binaries added to it, it is capable of building a wide array of application types. It can be use in 2 different ways, it should be unzipped from the root directory of the partition that it is being installed on. You can either manually add it to an installation of the MASM32 SDK OR you can install it on a partition that does not have MASM32 on it and simply rename the buildx64 directory to MASM32. Installing it on another partition is the preferred technique as QE has its menus and accessories set up for building 64 bit code.
You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.
In the "buildx64" directory is a batch file called "makeall.bat". This must be run to build all of the libraries and include files.
They are the gold standard of Windows assembly developing.
I installed (extracted) msysgit portable (PortableGit-1.9.5-preview20150319.7z)
The compressed archive is 23 MB, but once extracted the contents take up 262 MB. This is mostly due to the git command binaries (under 'libexec\git-core'). Almost all of the binaries are identical, they just have different names.
Why did the developers build the project like this? I suppose they need an executable for each command to support the CLI on windows cmd.exe.
But isn't there a way to avoid having ~100 identical binaries, each 1.5 MB in size (ex: using batch files)?
Why did the developers build the project like this? I suppose they
need an executable for each command to support the CLI on windows
cmd.exe.
Under unixoid OSes, you can have symbolic links to another file that behave exactly like the original file; if you do that for your executable, your executable can look into argv[0] to find out how it was called. That's a very common trick for many programs.
Under Windows, and especially without installers, it's (to my knowledge) impossible to get the same behaviour out of your file system -- there's just no symbolic link equivalent. Especially when you consider that programs that are meant to run from USB drives have to cope with ancient filesystems such as FAT32!
Thus, the executables simply were copied over. Same functionality, more storage. However, on a modern machine that you'd run windows on, you really don't care about 200MB give or take for such a versatile tool such as git.
In conclusion: the developers had no choice here; since windows (though having some posix abstraction layer) has no proper filesystem support for symbolic links, that was the only good way to port this unix-originating program. You either shouldn't care or use an OS that behaves better in that respect. I'd recommend the latter, but OS choices often aren't made freely...
I am trying to use a 32 bit wix installer to install to the powershell directory c:\windows\????\windowspowershell\v1.0
i have hard coded the 32bit directory
and i am trying to read the registry to return the 64 bit location.
all works fine on a 32bit machine, the registry gets read with the correct value and the file is installed to the correct place.
however when running on a 64bit machine (server 2008 R2) the registry picks up the correct 64 bit location but my hard coded 32 bit location is overwritten with the 64 bit registry value.
what is going on?
is there a better way of doing this?
what i have is a single ps1 script that needs to be installed to the powershell directory, if there is a 64 bit and 32 bit directory the same file should be copied to both locations
thanks
James
Windows Installer was designed to be platform specific. X86 packages can only write to X86 locations and X64 packages can only write to X64 locations. There are some hacks that allow you to get around this but they aren't supported. The official Microsoft solution is to create multiple MSI's and use a bootstrapper to chain them together ( ugly ) but you can also use a custom action to copy the file to the secondary location.
Sorry, no good solutions on this one IMO.
I've been using RCS (revision control system) from MKS Source Integrity for several old projects. I have to move to a new Windows 7 computer. The old version I have does not install on Windows 7, and a new version of the software is very expensive.
What is the best free or cheep source of RCS for Windows 7? Also, will it be compatible with MKS Toolkit which I am still going to install?
The official website for RCS has Windows 32-bit binaries, but they are dated. YMMV. http://www.cs.purdue.edu/homes/trinkle/RCS/.
Edit: I just tried the binaries (from the first zip file). They seem to work on a trivial text file.
I put them in a directory. Then I created an "RCS" directory. Then I created a text file. Then I ran "set TZ=EST" in my cmd.exe window (the tools require a timezone). Then I was able to check the text file in and out with the RCS command line tools.
Note that large files are probably not supported given the date of the binaries.
If you want the binaries to be available system wide, you have to place them in a location on your Windows PATH and set the TZ environmental variable to the zone you need in your account's environment.
RCS offers reverse merge which can be useful when you want to apply selected fixes for ECO version of your software without addition on less tested product enhancements. I was able to produce ECO version of real-time control system with several hundred fixes without the assistance of software engineers working on the next release of the product. ClearCase did not offer similar capability at the time.
We used rcs and gmake. Build scripts were written in Perl. Each ran on native Windows. I wish the idiots at the software company in Washington would use / instead of \ for file separator.
On Windows 7 64-bit SETUP32.EXE fails "not compatible with the version of Windows you're running"
My workaround:
Copy sintcm32.dll from a 32-bit machine into c:\windows\syswow64.
In Explorer, double-click a .pj file, set description to "MKS Source Integrity Project/Sandbox File" and target to "[network location]\mkssi\mkssi32.exe"
Create start menu shortcuts to "[network location]\mkssi\mkssi32.exe" etc.
Git (MSysGit) works on Windows 7 and is free. There is a learning curve associated with Git, which I think is worth it (for the benefits you get, especially regarding a distributed VCS), but some may disagree. This bundles come with bash and an ssh client (useful synchronization with remote repositories).
EDIT: For RCS specifically, there is an RCS package via Cygwin or an independent package from the Purdue RCS Homepage (the latter says "The latest PC (OS/2 DOS Win95 NT)", but I guess it might work on Windows 7, I'm fairly sure the Cygwin package works on Win 7).
I have always wondered about this. So many application setups have a zip file that you unzip, and in it are a bunch of files, among other things an exe and an msi. What is the difference? They are often even about the same size. I am never really sure which one to execute, sometimes I do the exe and sometimes the msi, and it usually works with either one. But does one of them do anything that the other doesn't do? And if not, isn't it kind of a waste having two files that does the same thing? Especially when thinking about download size, etc...
Not sure if this should be here or on ServerFault, or maybe neither, but I figured since developers usually are the ones creating setup files, then developers might know why this is like it is =)
In the case where you have both exe and the msi the exe is just a loader for the msi. If you have an installation supporting multiple languages then the exe applies a language transform (mst) on the msi before installing.
You can consider the exe as a wrapper around the msi. The msi file may or may not be given separately. The reason why people give the msi file too is to facilitate a group policy installation (in a Windows Active Directory infrastructure) as you can only push down installations of msi files and not exes.
The setup.exe is a wrapper for the MSI, but it is not only a wrapper.
The setup.exe can rely on a setup.ini to define parameters
The setup.exe checks for the Windows Installer (a MSI cannot be installed otherwise)
The setup.exe can check for frameworks, like the .NET framework. The developer can pick one of those defined in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages (for Visual Studio 2008). If it is lacking, it will try to download it from http://www.microsoft.com/
The setup.exe can be reconfigured with msistuff.exe
The actual installation is done in the MSI. As Prashast said, the exe is just a wrapper, but the reason for having the exe, is that an exe is allways possible to run. If the user do not have MS Installer installed on the computer, or his version of MS Installer is older than the version required by your installation, then the MSI file is not possible to run.
The exe provides automatic installation of MS Installer (including some question to the user if he/she wants to do this) before running the MSI file. In most cases, the install packages needed for Microsoft Installer is included inside the setup.exe, or sometimes it is just the prerequisites check with a link to download the installation from Microsoft.
In very basic words,
you can deliver just the .msi file and it will install. but .exe will not work without the .msi