I rather doubt anybody will know the answer to this, but I'll ask anyway... Under MS Windows, if you right-click on an executable file and select "properties", sometimes there's a "Version" tab that tells you the version number of the program. And sometimes there isn't. (Most especially, GHC-compiled programs do not have this tab.) Anybody know how to go about adding this? Also, anybody know how to give a GHC-compiled program a custom icon? If it's going to be really difficult then I won't bother, but it'd be interesting to know. (In other news, today I discovered that applying UPX to my 2.8 MB GHC-compiled executable shrinks it down to 800 KB and it still functions. And WinZip shrinks it down to just 300 KB. 2.8 MB for a program that just does a little text parsing does seem a touch excessive to me...)
On Tue, 09 Sep 2008 18:13:50 +0100, you wrote:
Under MS Windows, if you right-click on an executable file and select "properties", sometimes there's a "Version" tab that tells you the version number of the program. And sometimes there isn't. (Most especially, GHC-compiled programs do not have this tab.) Anybody know how to go about adding this?
Also, anybody know how to give a GHC-compiled program a custom icon?
Version information and application icons are both stored in data structures called "resources"; these are appended to the executable portion of the application, inside the EXE file. There are a number of predefined resource types, such as the aforementioned version info and icon, which follow specific data formats, and you can also define custom resources to store just about anything you want. (For example, in an application I wrote recently, I used custom resources to embed a set of TrueType fonts into the EXE.) There are a gazillion resource editors available for modifying the resources linked into an EXE; go to the Wikipedia page for a reasonable starting point: http://en.wikipedia.org/wiki/Resource_(Windows) Steve Schafer Fenestra Technologies Corp http://www.fenestra.com/
Steve Schafer wrote:
Version information and application icons are both stored in data structures called "resources"; these are appended to the executable portion of the application, inside the EXE file. There are a number of predefined resource types, such as the aforementioned version info and icon, which follow specific data formats, and you can also define custom resources to store just about anything you want. (For example, in an application I wrote recently, I used custom resources to embed a set of TrueType fonts into the EXE.)
There are a gazillion resource editors available for modifying the resources linked into an EXE; go to the Wikipedia page for a reasonable starting point:
Thanks for your input. I'm now playing with XN Resource Editor. Getting the version information to work correctly appears to be tricky, but everything else seems quite straight forward...
Andrew Coppin
Steve Schafer wrote:
Version information and application icons are both stored in data structures called "resources"; these are appended to the executable portion of the application, inside the EXE file.
Thanks for your input. I'm now playing with XN Resource Editor. Getting the version information to work correctly appears to be tricky, but everything else seems quite straight forward...
In theory, you should be able to use mingw's windres tool to produce an object file from the resource definition which you'd link with the rest of your program. http://www.mingw.org/MinGWiki/index.php/MS resource compiler
Jeff Zaroyko wrote:
In theory, you should be able to use mingw's windres tool to produce an object file from the resource definition which you'd link with the rest of your program.
http://www.mingw.org/MinGWiki/index.php/MS resource compiler
Yes, there's a cryptic comment burried away in the GHC manual that says GHC itself already uses windres to embed the manifest file into the compiled binary file. (And sure enough, if you crawl through with a hex editor you'll find the raw XML in there.) There's an option to tell GHC to not do this - however, I don't see any option anywhere to tell it to embed a *different* resource file instead. And frankly, the linker command looks frightening. (For starters, it's 6 pages long. I'm not kidding!) XN Resource Editor makes adding an icon child's play. (Interestingly, this also becomes the default window icon without any further action, which is nice.) However, either XN nor Resource Hack are able to embedd correct version info. And both of them crash quite a lot. (Even more interestingly, XN seems to make GHC-compiled binary files dramatically *smaller*... huh??)
Andrew Coppin
Jeff Zaroyko wrote:
In theory, you should be able to use mingw's windres tool to produce an object file from the resource definition which you'd link with the rest of your program.
Yes, there's a cryptic comment burried away in the GHC manual that says GHC itself already uses windres to embed the manifest file into the compiled binary file. (And sure enough, if you crawl through with a hex editor you'll find the raw XML in there.) There's an option to tell GHC to not do this - however, I don't see any option anywhere to tell it to embed a *different* resource file instead.
All I meant by linking is including the object file when you invoke ghc. windres foo.rc -o foores.o ghc bar.hs foo.o -Jeff
Jeff Zaroyko wrote:
Andrew Coppin
writes: Jeff Zaroyko wrote:
In theory, you should be able to use mingw's windres tool to produce an object file from the resource definition which you'd link with the rest of your program.
Yes, there's a cryptic comment burried away in the GHC manual that says GHC itself already uses windres to embed the manifest file into the compiled binary file. (And sure enough, if you crawl through with a hex editor you'll find the raw XML in there.) There's an option to tell GHC to not do this - however, I don't see any option anywhere to tell it to embed a *different* resource file instead.
All I meant by linking is including the object file when you invoke ghc.
windres foo.rc -o foores.o ghc bar.hs foo.o
Not sure if that works when using ghc --make, but we'll see. Actually no, we won't. Because I have just spent about 2 hours trying to get that first command to work. I am now exasperated beyond my powers of description. I made GHC print out all the commands it executes. I cut and pasted the windres command and changed the filenames. windres stubbornly *refuses* to work for me. It complains endlessly about "invalid arguments". (E.g., it claims that "-B" isn't a valid option.) And yet, this is the EXACT command that GHC executed, and it didn't complain for GHC. GRRR!!! >_< I even tried removing the arguments it doesn't like - but then it can't find any of the include files. Basically no matter what I do, I cannot make windres compile anything. I literally cannot *believe* how hard it is to put a few little words into that version tab... Every other kind of resource seems to be completely trivial, but this just won't work for toffee!
Andrew Coppin
Jeff Zaroyko wrote:
Andrew Coppin
writes: Jeff Zaroyko wrote:
In theory, you should be able to use mingw's windres tool to produce an object file from the resource definition which you'd link with the rest of your program.
I literally cannot *believe* how hard it is to put a few little words into that version tab... Every other kind of resource seems to be completely trivial, but this just won't work for toffee!
I'm sure you'll work something out, my test worked, I used a .res file I had lying around from Wine's ddraw.dll, used windres ddraw.res -o version.o to make an object file then using ghc hello.hs version.o linked it against hello world.
Jeff Zaroyko wrote:
Andrew Coppin
writes: I literally cannot *believe* how hard it is to put a few little words into that version tab... Every other kind of resource seems to be completely trivial, but this just won't work for toffee!
I'm sure you'll work something out, my test worked, I used a .res file I had lying around from Wine's ddraw.dll, used windres ddraw.res -o version.o to make an object file then using ghc hello.hs version.o linked it against hello world.
Well, you must either be running under a different OS or have Cygwin installed, because when I try it, it just complains constantly. ("Can't find gcc", "can't find cc1", "can't find crt.o", and so forth.) At this point, I'm giving up. I only wanted this for the shininess value. It's not worth this much trouble...
Hello Andrew, Saturday, September 13, 2008, 5:13:21 PM, you wrote:
Well, you must either be running under a different OS or have Cygwin installed, because when I try it, it just complains constantly. ("Can't find gcc", "can't find cc1", "can't find crt.o", and so forth.) At this point, I'm giving up. I only wanted this for the shininess value. It's not worth this much trouble...
yes, you should add path to gcc to your path. that's what i have in my makefile - hope it can help: GHCDIR = C:\Base\Compiler\ghc LIBDIR = $(GHCDIR)\gcc-lib INCDIR = $(GHCDIR)\include\mingw GCC = $(GHCDIR)\gcc.exe -B$(LIBDIR) -I$(INCDIR) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Thu, 11 Sep 2008 20:24:24 +0100, you wrote:
XN Resource Editor makes adding an icon child's play. (Interestingly, this also becomes the default window icon without any further action, which is nice.)
That's how Windows works: If an EXE contains at least one icon, then the first icon is used by default.
However, either XN nor Resource Hack are able to embedd correct version info.
The VERSIONINFO resource is actually rather complicated internally. In particular, the value that we think of as the version number (e.g., 1.2.3.456) is stored in two different formats (binary integer and string) in at least four different places, depending on how many languages are supported in the resource (file version as integer, product version as integer, and one each of file version as string and product version as string for each language). I don't recall offhand which one of these is what you see reported in the Properties dialog, but it's quite possible that you're setting the value of the "wrong" one, and that's why you're not seeing what you expect. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/
Hello Andrew, Thursday, September 11, 2008, 11:24:24 PM, you wrote:
interestingly, XN seems to make GHC-compiled binary files dramatically *smaller*... huh??)
probably it does `strip` on executable. -optl-s option does the same trick -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Andrew,
Thursday, September 11, 2008, 11:24:24 PM, you wrote:
interestingly, XN seems to make GHC-compiled binary files dramatically *smaller*... huh??)
probably it does `strip` on executable. -optl-s option does the same trick
And what exactly does a "strip" mean, then?
On Fri, 2008-09-12 at 18:07 +0100, Andrew Coppin wrote:
Bulat Ziganshin wrote:
Hello Andrew,
Thursday, September 11, 2008, 11:24:24 PM, you wrote:
interestingly, XN seems to make GHC-compiled binary files dramatically *smaller*... huh??)
probably it does `strip` on executable. -optl-s option does the same trick
And what exactly does a "strip" mean, then?
Remove the symbol table. And, for C, other debugging information. Historically, I believe, on Unix the distinction between an executable and an object file was weaker than it is now (so, for example, a.out was originally the default name of an object file, back when you didn't always need to link in a library). So (and this is still sometimes true on linux) the linker's output could be used as input to the linker. Unix linkers still include the combined symbol table in the executables they generate, to allow this. But if your executable is complete, you don't need a symbol table, so Unix includes a program `strip' that removes it from an executable (or object file, if you do something stupid). GHC's Windows port, of course, uses a port of the Unix toolchain, so the above discussion (almost) completely applies. (Although I don't think any (static) linker actually accepts Windows PE executables as input). jcc
Jonathan Cast wrote:
On Fri, 2008-09-12 at 18:07 +0100, Andrew Coppin wrote:
And what exactly does a "strip" mean, then?
Remove the symbol table. And, for C, other debugging information.
Historically, I believe, on Unix the distinction between an executable and an object file was weaker than it is now (so, for example, a.out was originally the default name of an object file, back when you didn't always need to link in a library). So (and this is still sometimes true on linux) the linker's output could be used as input to the linker. Unix linkers still include the combined symbol table in the executables they generate, to allow this. But if your executable is complete, you don't need a symbol table, so Unix includes a program `strip' that removes it from an executable (or object file, if you do something stupid).
GHC's Windows port, of course, uses a port of the Unix toolchain, so the above discussion (almost) completely applies. (Although I don't think any (static) linker actually accepts Windows PE executables as input).
That would certainly explain why the end of my compiled binary contains several miles of ASCII that looks like function names then... ;-) So if I give GHC the right options, it'll do that for me?
On Fri, 2008-09-12 at 18:35 +0100, Andrew Coppin wrote:
Jonathan Cast wrote:
On Fri, 2008-09-12 at 18:07 +0100, Andrew Coppin wrote:
And what exactly does a "strip" mean, then?
Remove the symbol table. And, for C, other debugging information.
Historically, I believe, on Unix the distinction between an executable and an object file was weaker than it is now (so, for example, a.out was originally the default name of an object file, back when you didn't always need to link in a library). So (and this is still sometimes true on linux) the linker's output could be used as input to the linker. Unix linkers still include the combined symbol table in the executables they generate, to allow this. But if your executable is complete, you don't need a symbol table, so Unix includes a program `strip' that removes it from an executable (or object file, if you do something stupid).
GHC's Windows port, of course, uses a port of the Unix toolchain, so the above discussion (almost) completely applies. (Although I don't think any (static) linker actually accepts Windows PE executables as input).
That would certainly explain why the end of my compiled binary contains several miles of ASCII that looks like function names then... ;-)
So if I give GHC the right options, it'll do that for me?
Correct. Finding the right option is left as a Google-enabled exercise for the reader. jcc
Hello Andrew, Friday, September 12, 2008, 9:07:28 PM, you wrote:
probably it does `strip` on executable. -optl-s option does the same trick
And what exactly does a "strip" mean, then?
stripping C debugging info, which is useless anyway -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (5)
-
Andrew Coppin -
Bulat Ziganshin -
Jeff Zaroyko -
Jonathan Cast -
Steve Schafer