Hello,

I have written - and submit for your judgement - a small utility that allows to use {$R *.dfm} directives on Windows. It is somewhat like a fpcres utility that exists for ELF platforms.

How to use:

1) compile :)
2) rename windres.exe from binutils package to windres1.exe
3) replace windres.exe with compiled binary.

How does it work:

It serves as a proxy for windres.exe. If input file is not a component stream, it simply passes that file to original windres. Otherwise, it optionally converts text stream into binary format, then dumps it to a temporary file (.rc format that contains a hex dump) and passes that temporary file to original windres to compile. Ideally it could write COFF file directly, but now it is just a proof of concept.

Is such thing useful and can it be eventually included into mainstream?

Regards,
Sergei

Yes. The crossfpc people have made a similar tool. I think we should add an option to the compiler which specifies the name of the resource compiler tool - this way we avoid the renaming issue.

I'll discuss it on core, and get back to you.

Michael.

Yes. The crossfpc people have made a similar tool...

Is crossfpc still/again active ?

-Michael

Yes. They're working full-time on it, it seems.

Hmmmm...

http://crossfpc.untergrund.net/#history:

Version history

Here is a list of recent changes to the project:

0.1.0 28 Feb 2005 (internal) 0.2.0 7 May 2005 (internal) 0.2.1 8 May 2005 (internal)

-Michael

Michael Schnell wrote

> Yes. The crossfpc people have made a similar tool... Is crossfpc still/again active ?

Yes. They're working full-time on it, it seems.

Michael.

The website is outdated, but the mailing list recently became quite active again - including flamewars.

Michael.

The website is outdated, but the mailing list recently became quite active again

Great !

- including flamewars.

not that great ;-)

-Michael

Can you give us the the mailing list addess? I can't find it on the web site.

____________________________________________________________________________________ Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

Can you give us the the mailing list addess? I can't find it on the web site.

The webinterface is at:
http://lists.computerman.de/mailman/listinfo/crossfpc

But your subscription will be held for approval by Simon Kissel.

Michael.

.. and seem to have a person working completely on this.

Will it become a commercial product ?

-Michael

Not that I know.

Michael.

Hi,

The name of the resource linker can now be set with -FR<x>. This binary should transform a resource file file to a .o file.

You can also specify the name of the recource compiler with -FC. This binary should transform a resource source file to a .o file. (normally used for .rc files)

Both options expect the name of a binary (will be searched in the PATH), and the binary should handle the same options as windres does.

Can you test this using the latest SVN ? (at least revision 8164)

Michael.

To make sure that I understand things right:
- The new utility is supposed to be invoked as 'fpc -FR<name> <all other options>';
- The new utility has nothing to do with -FC switch;
- 'windres' name is still hardcoded within the utility.

I probably should support win64/gorc, too. What will be the proper way to do it: recognize gorc switches in the commandline, or compile a separate executable, or whatever else? Is gorc executable available for crosscompiling from win32?

Can you test this using the latest SVN ? (at least revision 8164)

I shall test it, and report separately.

Sergei

Yes.

- The new utility has nothing to do with -FC switch;

Currently not.

- 'windres' name is still hardcoded within the utility.

This is as you wish :-)

I have no idea. I suppose it is up to you to detect whether you want to use windres or gorc, and transform the arguments if you are going to call gorc.

Michael.

After initial testing with r8164, things appear to be exactly opposite than I imagined initially: the utility must be specified in -FC switch and has nothing to do with -FR. This is due to recent changes in resource handling, I guess.

Basically it works this way (the only required thing is to change "windres1" name back to "windres" in windr.pp).

However, I ended up realizing that my binutils (2.9.5) are too outdated. Windres 2.9.5 has a bug - it does not round resource header length up to a dword boundary, so created .res files are correct only if resource name length is odd. This bug appears to be fixed in recent 2.17.50, but in turn it does not work without '--use-temp-file' commandline switch... I believe I must set this stuff up properly before going further.

So the questions are:
1) what version of binutils is the 'current' for FPC development?
2) Is it possible to download it somewhere in one piece like crossbinutils (i.e. compiled binaries for win32 only and without fpc binaries)?

Sergei

There are no changes, except that you can configure the used utility.

However, I noticed that my explanation was wrong. -FC is used to create a .res file, -FR is used to create a .o file:

see comprsrc.pas:

  if output=roRES then
    Bin:=SelectBin(RCCompiler,target_res.rcbin) // Set using -FC
  else { roOBJ, create object file }
    Bin:=SelectBin(ResCompiler,target_res.resbin); // Set using -FR

Michael.

That's exactly one of the reasons why I think that it's better to move the utility into the compiler.

I was thinking about this, too. For binary streams there's no visible problem to do this. But for text streams, it's necessary to call ObjectTextToResource(), and that would make compiler depend of Classes unit.

There's another point. Before revision 7515, windres was used to convert .rc directly into .o, therefore I designed the utility to be a windres proxy - just not to mess with .o format internals. But now the resources are processed in two steps, and the first step must write .res only - that is fairly easy. The utility may write .res directly and need not be a windres proxy.
So maybe it could be better way to detect format of resource file in compiler and invoke either new utility or windres? (customizations introduced in r8164 would then be unnecessary)

Sergei

You must then introduce new 'helper binary' definitions in the compiler This is what I wanted to avoid with the command-line switch in the first place. My solution is more general, as it means no names are hardcoded in the compiler.

Michael.

Here is a status update:

I tested the utility with binutils 2.16.91 under win32. It works when invoked as 'fpc -FCwindr <other options>'.

I've also made some modifications:
- windres name is hardcoded, but can be overriden by setting WINDRES environment variable;
- added checking extension of input files. By default, only .dfm, .xfm, .lfm and .mfm are recognized as component streams, but this list can be extended using DFMEXTS environment variable. If set, it must contain semicolon-separated list of extensions, e.g. DFMEXTS=ex1;ex2;ex3
- if '-O res' is given in the commandline and input file is a component stream, it writes .res file directly, without involving windres.

I also investigated win64/gorc in more details. It appears that gorc '/machine' switch applies only to .o files, not to .res. Also there is no difference between .res files generated from the same source by windres and gorc. So it should be possible to switch resource compiling for win64 to windres by changing res_win64_gorc_info.rcbin and res_win64_gorc_info.rccmd to the values used in res_gnu_windres_info - then the utility will be supported for win64 without any further efforts.

My next task is to investigate cross-compiling issues...

Sergei