windres bug.

windres bug.

[Tom Walsh]

Hello,

I have identified a bug within windres v2.11.90 where it is not
correctly calculating the HEADER_SIZE (offset 4 bytes into the resource
header).  I found this after compiling the windres on a i386 linux box
for use with the Borland Kylix to build RES files that Kylix needs.

The problem shows up when building BITMAPs (I only tested it with
bitmaps), if the name of the bitmap is an EVEN number of bytes, the
res_id header size is improperly calculated.  The effect shows up with
an RC file as follows (the only correct header written is for 'RITE1'):

================================================
 
LANGUAGE 9, 4
 
EFT1 BITMAP MOVEABLE DISCARDABLE "../kylix/images/left1.bmp"
 
EFT2 BITMAP MOVEABLE DISCARDABLE "../kylix/images/left2.bmp"
 
RITE1 BITMAP MOVEABLE DISCARDABLE "../kylix/images/right1.bmp"
 
SRITE2 BITMAP MOVEABLE DISCARDABLE
"../kylix/images/right2.bmp"                
================================================


The problem is within the binutils/resres.c in two functions of
write_res_header() & res_align_file() which currently reads:


================================================
/* Write a resource header */
static void
write_res_header (datasize, type, name, resinfo)
     unsigned long datasize;
     const struct res_id *type;
     const struct res_id *name;
     const struct res_res_info *resinfo;
{
  struct res_hdr reshdr;
  reshdr.data_size = datasize;
  reshdr.header_size = 24 + get_id_size (type) + get_id_size (name);

  res_align_file ();
  write_res_data (&reshdr, sizeof (reshdr), 1);
  write_res_id (type);
  write_res_id (name);

  res_align_file ();

  write_res_info (resinfo);
  res_align_file ();
}

.
.
.

/* align file on DWORD boundary */
static void
res_align_file (void)
{
  if (fseek (fres, ftell (fres) % 4, SEEK_CUR) != 0)
    fatal ("%s: %s: unable to align file", program_name, filename);
}
================================================


With an even number of bytes in the unicode name the DWORD computation
of the header size fails.  I have corrected this problem with rewriting
the write_res_header to:


================================================
/* Write a resource header */
static void
write_res_header (datasize, type, name, resinfo)
     unsigned long datasize;
     const struct res_id *type;
     const struct res_id *name;
     const struct res_res_info *resinfo;
{
  struct res_hdr reshdr;
  reshdr.data_size = datasize;
  reshdr.header_size = 24 + get_id_size (type) + get_id_size (name);

  	/* TomW: align the header size to DWORD boundry. */
  reshdr.header_size += reshdr.header_size % 4;

  res_align_file ();

  write_res_data (&reshdr, sizeof (reshdr), 1);
  write_res_id (type);
  write_res_id (name);

  res_align_file ();

  write_res_info (resinfo);
  res_align_file ();
}
================================================

Would someone please pass this info to the maintainer of the windres
package?  I would also like to know when the fix is released? I am
writing a HOWTO for the Kylix programmers so that they can "wean"
themselves of the need to use windoze to write these resource files for
kylix and would like to time the paper to the release.

Thank you,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net , http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."

Re: windres bug.

[Tom Walsh]

This is the patchfile for two changes in windres v2.11.90

binutils/configure: to allow '--with-windres' to be specified as an
option.

binutils/resres.c: repair of write_res_header() to correct the DWORD
count.


Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net , http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
diff -Nr -U 6 binutils-2.11.2/binutils/configure binutils-2.11.2.new/binutils/configure
--- binutils-2.11.2/binutils/configure	Mon Jun 11 06:04:27 2001
+++ binutils-2.11.2.new/binutils/configure	Sun Jul  8 08:42:34 2001
@@ -5435,12 +5435,15 @@
 	  DLLTOOL_DEFS="$DLLTOOL_DEFS -DDLLTOOL_MCORE_ELF"
 	  ;;
 	esac
     fi
 done
 
+if test "${with_windres+set}" = set; then
+	  BUILD_WINDRES='$(WINDRES_PROG)$(EXEEXT)'
+fi
 
 
 
 
 
 
diff -Nr -U 6 binutils-2.11.2/binutils/resres.c binutils-2.11.2.new/binutils/resres.c
--- binutils-2.11.2/binutils/resres.c	Sun Sep 19 19:59:35 1999
+++ binutils-2.11.2.new/binutils/resres.c	Sun Jul  8 08:48:26 2001
@@ -383,12 +383,14 @@
      const struct res_id *name;
      const struct res_res_info *resinfo;
 {
   struct res_hdr reshdr;
   reshdr.data_size = datasize;
   reshdr.header_size = 24 + get_id_size (type) + get_id_size (name);
+  	/* align header_size to a DWORD boundry. */
+  reshdr.header_size += reshdr.header_size % 4;
 
   res_align_file ();
   write_res_data (&reshdr, sizeof (reshdr), 1);
   write_res_id (type);
   write_res_id (name);
 

Re: windres bug.

[Andreas Jaeger]

Tom Walsh <tom@cyberiansoftware.com> writes:

> This is the patchfile for two changes in windres v2.11.90
> 
> binutils/configure: to allow '--with-windres' to be specified as an
> option.

binutils/configure is a generated file.  You need to patch
configure.in instead.

In that case you do also something like the code below (stolen from
GCC's configure.in):

# With GNU ld
AC_ARG_WITH(gnu-ld,
[  --with-gnu-ld           arrange to work with GNU ld.],
gnu_ld_flag="$with_gnu_ld",
gnu_ld_flag=no)

You're allowed to say: --with-windres=no, --with-windres=yes,
--with-windres and even --without-windres (for details check the
autoconf manual on AC_ARG_WITH).  autoconf replaces this with the
appropriate checks.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: windres bug.

[Tom Walsh]

Andreas Jaeger wrote:
> 
> 
> binutils/configure is a generated file.  You need to patch
> configure.in instead.
> 
> In that case you do also something like the code below (stolen from
> GCC's configure.in):
> 

Hi Andreas, 

Thank you for that insight, I have mostly ignored how the configure
script works as I didn't want to learn *another* scripting language (I
have been resistant to learning bash scripting).  I guess that I will
have to do this as I compile most of my applications and they all seem
to use the configure script.

Regards,

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net , http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."

Re: windres bug.

[DJ Delorie]

> binutils/configure: to allow '--with-windres' to be specified as an
> option.

What targets need this but don't do it automatically?

> --- binutils-2.11.2/binutils/configure	Mon Jun 11 06:04:27 2001
> +++ binutils-2.11.2.new/binutils/configure	Sun Jul  8 08:42:34 2001

The patch should be for configure.in.  Configure is generated from
that.

> +  	/* align header_size to a DWORD boundry. */
> +  reshdr.header_size += reshdr.header_size % 4;

This is not the correct math - if header_size is 3, for example, you
end up with a header_size of 6.  I think you want this:

	sz = (sz + 3) & ~3;

Looks like res_align_file is broken that way too.  We probably never
trip over this (because header_size is always a multiple of two), but
better safe than sorry.

Re: windres bug.

[DJ Delorie]

I checked in a patch to fix the alignment problem.  Thanks!

I haven't checked in the --with-windres patch, because (1) independent
patches should be separate anyway, and (2) it should automatically
build on the systems it works for, so if it doesn't, *that* is the bug
to be fixed.

Re: windres bug.

[Tom Walsh]

DJ Delorie wrote:
> 
> I checked in a patch to fix the alignment problem.  Thanks!
> 
> I haven't checked in the --with-windres patch, because (1) independent
> patches should be separate anyway, and (2) it should automatically
> build on the systems it works for, so if it doesn't, *that* is the bug
> to be fixed.

I couldn't get it to build on a gcc system (linux). The decision not to
do so may have been correct (not to include package) at the time it was
made, but with Kylix being distro'd on X86 linux systems, we now need
the ability to create RES packages.  And, I hate the idea of having to
put together a windoze box just to do RES files.

Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net , http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: windres bug.

[DJ Delorie]

> I couldn't get it to build on a gcc system (linux). The decision not to
> do so may have been correct (not to include package) at the time it was
> made, but with Kylix being distro'd on X86 linux systems, we now need
> the ability to create RES packages.  And, I hate the idea of having to
> put together a windoze box just to do RES files.

All you need to do is configure it as a cross compiler, not a native
compiler.  .../configure --target=i686-pc-cygwin

Re: windres bug.

[Tom Walsh]

DJ Delorie wrote:
> 
> > I couldn't get it to build on a gcc system (linux). The decision not to
> > do so may have been correct (not to include package) at the time it was
> > made, but with Kylix being distro'd on X86 linux systems, we now need
> > the ability to create RES packages.  And, I hate the idea of having to
> > put together a windoze box just to do RES files.
> 
> All you need to do is configure it as a cross compiler, not a native
> compiler.  .../configure --target=i686-pc-cygwin

???  Won't that generate code that is specific to a DOS executable
rather than ELF (un*x)?  I just hacked the configure and forced it
compile it as native, so I just assumed it was a decision to eliminate
it from the binary package generation if compiled under un*x?

Whatever, if it will work, okay, it just doesn't seem intuitive to cross
compile it.  I do a lot of cross-gcc code generation as an embedded
developer so the concept of cross compiling (in my mind) is to generate
non-native code (e.g. m68k-elf-gcc for uClinux).

Regards,

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net , http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: windres bug.

[DJ Delorie]

The problem is that windres expects to output not only RES files but
also COFF files (and linux is elf, not coff).  The RES files will be
the same as long as the endian and word sizes are the same, so cross
compiling from i686-linux to i686-cygwin won't matter.  Just don't use
the "-O coff" option :-)

If, however, you've discovered (or patched it so) that windres does
work with ELF output files, then the solution is to change configure
so that windres is built for those configurations which it supports.
Expecting the user to manually specify that it should be built doesn't
seem like the right thing to do; if it's supported for a given
platform we should just build it.

Re: windres bug.

[Tom Walsh]

DJ Delorie wrote:
> 
> If, however, you've discovered (or patched it so) that windres does
> work with ELF output files, then the solution is to change configure
> so that windres is built for those configurations which it supports.
> Expecting the user to manually specify that it should be built doesn't
> seem like the right thing to do; if it's supported for a given
> platform we should just build it.

Just to clarify the issue of ELF.  I was looking for a native RES
compiler that would run under linux and discovered the windres package
within the binutils source.  Decided to try compiling it under gcc so
that it could be run natively under linux.  It did compile, and other
than the problem with the header computation, will create the RES file
for use with kylix (linux version of Borland Delphi).

It seems to run okay as an ELF compiled binary, nothing goofy seems to
happen when I run it.  But, I only use it to create RES files that only
contain bitmaps.  I don't know how it would behave for other resources. 
BTW. It 'decompiles' the RES files into an RC okay (again, bitmaps --
BMP).

Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net , http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: windres bug.

[DJ Delorie]

The question is, what happens when you do this:

	windres -I rc -O coff foo.rc foo.o

Re: windres bug.

[Tom Walsh]

DJ Delorie wrote:
> 
> The question is, what happens when you do this:
> 
>         windres -I rc -O coff foo.rc foo.o

It says:

windres: can't get BFD_RELOC_RVA relocation type: Invalid
argument              

But I don't have a use for a coff file..

Regards,

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net , http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: windres bug.

[Tom Walsh]

DJ Delorie wrote:
> 
> The question is, what happens when you do this:
> 
>         windres -I rc -O coff foo.rc foo.o


That would be an argument in favor of the --with-windres switch for
configure.  If the full functionality is not there, we let the enduser
make the decision to accept the limitations?  What I was attempting to
do was provide a means that a newbie (windoze programmer using kylix for
the first time) to avoid having to purchase vmware (or such) to compile
bitmap RES files under linux. With kylix, we just have mundane stuff
like cursor & BMP resources that are needed to decorate the forms with.

Regards,

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net , http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: windres bug.

[DJ Delorie]

> windres: can't get BFD_RELOC_RVA relocation type: Invalid argument

OK, I recommend two things:

1. Try to detect when the selected output bfd format isn't a PE
   variant and fail with a useful error message.  Or fix it so that it
   works with ELF.  BFD_RELOC_RVA should probably be replaced with
   BFD_RELOC_32 for other formats.

2. Go ahead and post a patch to add the --with-windres option.