Re: [patch/rebase] peflags.c: Use official file structures, make 64 bit capable
On 8/5/2011 8:51 AM, Corinna Vinschen wrote: > On Aug 5 13:17, Corinna Vinschen wrote: >> the below patch cleans up peflags so that it uses the official Windows >> types to access the COFF and PE flags via a memory map, rather than >> seek/read, seek/write to some undocumented byte offsets. This patch >> also makes peflags capable to read and change 64 bit files. >> >> Reading and writing other header info (namely stacksize) follows later. >> >> Patch builds and is tested on Cygwin and x86_64-mingw64. >> >> Ok to apply? > > Second service. I left in everything I only added for debugging a > problem I had with my the native mmap implementation. For some reason > the data was never written back to the file. Turned out I had used > "flags" instead of "prot" in the conditionals. That was already fixed > in the previous patch, but the debug stuff was really supposed to go away. > > Here we go, ChangeLog is unchanged... Looks good, builds cleanly and works correctly on mingw(32) and msys. Go ahead. -- Chuck
Re: SETUP: default to mintty
On 8/5/2011 4:04 PM, Andy Koppe wrote: > How do you create icons including a 256x256 version? I haven't managed > to get the 'icobundl' utility that Warren linked to to do it. I used gimp...see this: http://gimp-tutorials.net/How-to-make-an-icon-from-a-picture (scroll down to the end for the bit about multires ico files) -- Chuck
Re: SETUP: default to mintty
On 8/5/2011 2:04 PM, Andy Koppe wrote: Which leaves the question how the icon with the 256x256 became so big. I'd used a Cygwin build of 'icotool' from 'icoutils' for that, icotool's --help is confusing. The magic incantation is: $ icotool -c -o cygwin-term.ico -r cygwin-term.png where cygwin-term.png is the 256 px Vista icon. -r is the trick. You then append the PNG files for the smaller sizes to the list to have them translated to BMP style "standard" icons within the aggregate .ico. allows to embed PNGs directly, instead storing them in whatever less efficient bitmap format .ICOs have used before. .ico is originally based on BMP, which is a trivial uncompressed file format, basically a small header containing obvious things like width, height, color depth, pixel format and such, followed by raw pixel data. So, a 32 bit RGBA 256x256 .bmp or .ico will be 262,144 bytes plus header overhead. (I get 270,398 bytes here.) Your 300K+ file probably got a bit bigger due to having more icon sizes bundled in. How do you create icons including a 256x256 version? I use the ICO file plugin for Photoshop from Telegraphics, the same people that put out icobundl. You get a dialog on saving the icon, asking if you want a standard or Vista PNG .ico; I say Vista for the 256 px one, and standard for the smaller four sizes. Then, I use icobundl to take the resulting 5 .ico files and assemble them. I can do final compression and assembly if you need me to, but I think the icotool incantation will fix your problem.
Re: 256x256 px icons
On 8/5/2011 1:08 PM, Andy Koppe wrote: I like this a lot. Thanks very much for responding so positively to my whinging. Let me know if you need to see any other changes. I think a large part of the problem is tl;dr, and the resultant talking past each other. I know it's true for me. I've been taking a passive role since you and Corinna took my ball and ran with it, but don't take that to mean you can't ask me for changes. The main thing I need is concrete requests, such as those that lead to the present changes. I will get back to your comments about the semitransparent Konsole icon edge later. I don't see a fade-out here, no doubt because there's precious little standardization in vector art, SVG notwithstanding. That's one of the reasons I decided to install Inkscape instead of continuing to base my work on SVG art imported into Illustrator then re-exported. I'd bet AI is a lot more powerful, but if it impedes communication... Besides, PS fanboy though I am, AI fanboy I am not. :)
Re: 256x256 px icons
On 5 August 2011 16:57, Charles Wilson wrote: > On 8/5/2011 11:05 AM, Andy Koppe wrote: >> On 4 August 2011 15:29, Corinna Vinschen wrote: >>> On Aug 4 09:19, Charles Wilson wrote: Here (well, it's 237x258 but that's nothing that can't be fixed with little GIMP). >>> >>> Nice, thank you. >> >> Ditto. Where did you find that? > > It's at the same place I got the original windows icon: > http://kde-look.org/content/show.php?content=36393 > > It's the 'Fedora' download. > >> There isn't a vector version of this, is there? > > Not that I could see. There's contact info for fatbuttlarry at the link, > but it's several years old, so no telling if it is still accurate, or if > fbl would respond, or if he still HAS any original vector artwork, or if > he'd be willing to share it... I sent a request to the email address given there. At least it hasn't yet come back as undeliverable ... Thanks, Andy
Re: 256x256 px icons
On 5 August 2011 18:35, Warren Young wrote: > On 8/3/2011 11:49 PM, Andy Koppe wrote: >> >> Warren's has the advantage of a 256 version and that it's more >> tweakable assuming he provides the vector version it's presumably >> based on. > > Sorry, there is currently no vector version. Effects like bevels and > shadows are raster effects. However, based on this: > > https://secure.wikimedia.org/wikipedia/en/wiki/SVG_filter_effects > > it does look like SVG's been extended with the raster effects needed to > recreate my beveled icon. I am installing Inkscape now and will try to do > that later, perhaps today, perhaps not. Don't worry too much about that. The below sounds like the Photoshop version should be entirely sufficient. > In the meanwhile, here's my new beveled Cygwin logo: > > http://etr-usa.com/cygwin/logo/beveled-noshadow.psd > > Changes from the original: > > - removed the big drop shadow (outer glow still present) > - softened lighting on the wedge > - dropped outer C stroke from white to a light gray > - rebuilt as 1024 px square, not counting the outer glow, > for finer editing control > > This should open in any version of Photoshop going back to the 90s. (v6 and > up, I'm guessing.) While I realize not everyone will have even that, I'm > providing it because it's based on easy-to-edit procedural effects, rather > than flattened raster effects. > > However, I have made a fully rasterized, layered version compatible with > Gimp for those without even Photoshop 6.0: > > http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf > > I also made a 256 px .ico, for those who just want to see it in action: > > http://etr-usa.com/cygwin/logo/beveled-noshadow.ico I like this a lot. Thanks very much for responding so positively to my whinging. Andy
Re: 256x256 px icons
On 8/5/2011 11:50 AM, Corinna Vinschen wrote: You could also try moving the gamma slider, either alone, or in combination with the above to keep the blacks where you want them. I don't understand this. If I do that, the black C and especially the highlights in the C are getting whiter and chunky, This is due to not having a layered document. The levels move is affecting everything, not just the glow. Lacking a layered document so you can modify the glow in isolation, you're back to needing a good selection to start with. Riffing off the Hue-Saturation tip from the other message, you could take essentially the same path but move the lightness slider in addition to the saturation. Between this and Andy's "select wedge then invert selection" you should get a good result.
Re: 256x256 px icons
On Aug 5 10:13, Warren Young wrote: > On 8/5/2011 9:05 AM, Andy Koppe wrote: > > > >>Do you know how to convert the green glow around > >>the C to grey, by any chance? > > > >Here's what I did, in Paint.net. I very much suspect there are better ways. > > The "right way" is to use Levels. Ctrl-L in Photoshop and > Paint.NET, Colors > Levels in Gimp. > > In this case, I'd drag down the white point of the input levels to > push things toward white, while leaving the dark parts of the image > where they are, more or less. > > You could also try moving the gamma slider, either alone, or in > combination with the above to keep the blacks where you want them. I don't understand this. If I do that, the black C and especially the highlights in the C are getting whiter and chunky, while the green frame gets chunky but stays green. So I'm puzzled. If I do that and then desaturize, what have I won, except that the highlights in the C are chunkier? Where's the trick? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 256x256 px icons
On 8/4/2011 12:16 PM, Corinna Vinschen wrote: On Aug 4 13:24, Charles Wilson wrote: On 8/4/2011 10:29 AM, Corinna Vinschen wrote: Nice, thank you. Do you know how to convert the green glow around the C to grey, by any chance? Not...exactly. I think you should be able to use the magic wand selection tool (with appropriate options), and then apply a desaturate or color shift filter to the selected region. But, that's only a guess. I tried that for about 45 minutes. Don't ask to see any results :( In Gimp, you can say Colors > Hue-Saturation, then click the radio button next to the green color chip to restrict the adjustment to the greens. Dropping Saturation should then give you the result you want. Avoid the Tragic Wand. It is almost never the right tool for the job. There are whole books on better selection methods: http://www.amazon.com/dp/0321441206/ http://www.amazon.com/dp/0735712794/ http://www.amazon.com/dp/0321808231/ Yes, they're all to do with Photoshop, but the principles are the same. In the case of Hue-Saturation, Gimp/PS is computing a mask for you automatically when you restrict it to a color range. When not dealing with simple logo art, you often have to resort to the more advanced techniques in the books I've recommended above.
Re: 256x256 px icons
On 8/3/2011 11:49 PM, Andy Koppe wrote: Warren's has the advantage of a 256 version and that it's more tweakable assuming he provides the vector version it's presumably based on. Sorry, there is currently no vector version. Effects like bevels and shadows are raster effects. However, based on this: https://secure.wikimedia.org/wikipedia/en/wiki/SVG_filter_effects it does look like SVG's been extended with the raster effects needed to recreate my beveled icon. I am installing Inkscape now and will try to do that later, perhaps today, perhaps not. In the meanwhile, here's my new beveled Cygwin logo: http://etr-usa.com/cygwin/logo/beveled-noshadow.psd Changes from the original: - removed the big drop shadow (outer glow still present) - softened lighting on the wedge - dropped outer C stroke from white to a light gray - rebuilt as 1024 px square, not counting the outer glow, for finer editing control This should open in any version of Photoshop going back to the 90s. (v6 and up, I'm guessing.) While I realize not everyone will have even that, I'm providing it because it's based on easy-to-edit procedural effects, rather than flattened raster effects. However, I have made a fully rasterized, layered version compatible with Gimp for those without even Photoshop 6.0: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf I also made a 256 px .ico, for those who just want to see it in action: http://etr-usa.com/cygwin/logo/beveled-noshadow.ico
Re: 256x256 px icons
On 8/5/2011 9:05 AM, Andy Koppe wrote: Do you know how to convert the green glow around the C to grey, by any chance? Here's what I did, in Paint.net. I very much suspect there are better ways. The "right way" is to use Levels. Ctrl-L in Photoshop and Paint.NET, Colors > Levels in Gimp. In this case, I'd drag down the white point of the input levels to push things toward white, while leaving the dark parts of the image where they are, more or less. You could also try moving the gamma slider, either alone, or in combination with the above to keep the blacks where you want them. (The gamma slider is the triangle that starts at the 50% gray point on the Output side in Paint.NET, but it's on the Input side in PS and Gimp, like it should be.) One advantage of using Levels for this is that you can do it *after* the desaturation step. This lets you establish your grayscale, then manipulate the light part visually, instead of guessing at the shade of yellow you need and then blindly hoping the desat step gets you the right shade of gray, and if not, going back and retrying. Also, the Levels tool is just plain awesome, and you should get to know it regardless. The UI for it is confusing in Paint.NET. Gimp does it like Photoshop, which is of course the One True Way. (Not that I'm endorsing Gimp. This example shows up yet another place where it falls down, UI-wise. Levels isn't about color, and the absence of a hot key for such a commonly-used function is a mistake.)
[Patch/rebase] Update docs
FYI, I went ahead and committed the following updates to NEWS and README. Also, took the opportunity to correct some typos and such in ChangeLog. patch gzip'ed because qmail hates embedded email addresses. -- Chuck update-doc.patch.gz Description: GNU Zip compressed data
Re: 256x256 px icons
On 8/5/2011 11:05 AM, Andy Koppe wrote: > On 4 August 2011 15:29, Corinna Vinschen wrote: >> On Aug 4 09:19, Charles Wilson wrote: >>> Here (well, it's 237x258 but that's nothing that can't be fixed with >>> little GIMP). >> >> Nice, thank you. > > Ditto. Where did you find that? It's at the same place I got the original windows icon: http://kde-look.org/content/show.php?content=36393 It's the 'Fedora' download. > There isn't a vector version of this, is there? Not that I could see. There's contact info for fatbuttlarry at the link, but it's several years old, so no telling if it is still accurate, or if fbl would respond, or if he still HAS any original vector artwork, or if he'd be willing to share it... (The pentajock link on the page above is dead, so that doesn't bode well) -- Chuck
Re: 256x256 px icons
On 4 August 2011 15:29, Corinna Vinschen wrote: > On Aug 4 09:19, Charles Wilson wrote: >> On 8/4/2011 4:39 AM, Corinna Vinschen wrote: >> > Sure! I would be more happy with the fatbuttlarry icon if it would >> > be available in a nice 256x256 variation, though. That's really a >> > big plus of Warren's version. >> >> Here (well, it's 237x258 but that's nothing that can't be fixed with >> little GIMP). > > Nice, thank you. Ditto. Where did you find that? There isn't a vector version of this, is there? I'm asking because that would allow to remove the shadow under the C without impacting the edge of the C which has a bit of a fade-out on it. I realised that I'd used the 24bpp version of cygicons-0.dll,9, which doesn't have the shadow, but only because it doesn't have an alpha channel. > Do you know how to convert the green glow around > the C to grey, by any chance? Here's what I did, in Paint.net. I very much suspect there are better ways. - Select the green arrow with the rectangular select tool. - Invert the selection, thereby selecting everything but the green arrow. - Go to Adjustments->Hue/Saturation: Turn the hue to -60 (yellow) and the saturation to 200 (maximum). OK. - Adjustments->Black and White. (The point of turning it bright yellow before the Black and White step is to make the resulting grey as light as possible.) Andy
Re: [Patch] Add rebase-dump application to rebase package
On Aug 5 10:17, Charles Wilson wrote: > On 8/5/2011 10:08 AM, Corinna Vinschen wrote: > > On Aug 5 09:07, Charles Wilson wrote: > >> Which approach do you think is better? > > > > What about this: > > Sure, that looks fine. Go ahead and check it in. (No point in waiting > around for Jason right now, since he's AFK). Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [Patch] Add rebase-dump application to rebase package
On 8/5/2011 10:08 AM, Corinna Vinschen wrote: > On Aug 5 09:07, Charles Wilson wrote: >> Which approach do you think is better? > > What about this: Sure, that looks fine. Go ahead and check it in. (No point in waiting around for Jason right now, since he's AFK). -- Chuck
Re: [Patch] Add rebase-dump application to rebase package
On Aug 5 09:07, Charles Wilson wrote:
> On 8/5/2011 7:31 AM, Corinna Vinschen wrote:
> > Your rebase-dump doesn't build cleanly on mingw64:
> > Here's my fix:
>
> > -printf ("== read %u (0x%08x) bytes (database header)\n",
> > +printf ("== read %zu (0x%08zx) bytes (database header)\n",
> > sizeof hdr, sizeof hdr);
>
> Unfortunately, msys doesn't support %z:
>
> == read zu (0x000zx) bytes (database header)
>
> I see two solutions: (1) #ifdefs in some manner -- e.g. incode, or a
> top-of-file defining the string to use for size_t arguments (decimal and
> hex) or (2) use a temporary variable of type unsigned long long, and
> assign the result of the sizeof() computation to that var, and then use
> %llu or %llx.
>
> Which approach do you think is better?
What about this:
Index: rebase-db.h
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebase-db.h,v
retrieving revision 1.2
diff -u -p -r1.2 rebase-db.h
--- rebase-db.h 3 Aug 2011 13:40:16 - 1.2
+++ rebase-db.h 5 Aug 2011 14:07:50 -
@@ -21,6 +21,13 @@
#include
#include
+#if defined(__MSYS__)
+/* MSYS has no inttypes.h */
+# define PRIu64 "llu"
+# define PRIx64 "llx"
+#else
+# include
+#endif
#define roundup(x,y) x) + ((y) - 1)) / (y)) * (y))
#define roundup2(x,y) (((x) + (y) - 1) & ~((y) - 1))
Index: rebase-dump.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebase-dump.c,v
retrieving revision 1.1
diff -u -p -r1.1 rebase-dump.c
--- rebase-dump.c 3 Aug 2011 13:40:16 - 1.1
+++ rebase-dump.c 5 Aug 2011 14:07:50 -
@@ -124,8 +124,8 @@ load_image_info ()
return -1;
}
if (verbose)
-printf ("== read %u (0x%08x) bytes (database header)\n",
- sizeof hdr, sizeof hdr);
+printf ("== read %" PRIu64 " (0x%08" PRIx64 ") bytes (database header)\n",
+ (unsigned long long) sizeof hdr, (unsigned long long) sizeof hdr);
/* Check the header. */
if (memcmp (hdr.magic, IMG_INFO_MAGIC, 4) != 0)
@@ -178,9 +178,9 @@ load_image_info ()
}
if (ret == 0 && verbose)
{
- printf ("== read %u (0x%08x) bytes (database w/o strings)\n",
- img_info_size * sizeof (img_info_t),
- img_info_size * sizeof (img_info_t));
+ printf ("== read %" PRIu64 " (0x%08" PRIx64 ") bytes (database w/o
strings)\n",
+ (unsigned long long) img_info_size * sizeof (img_info_t),
+ (unsigned long long) img_info_size * sizeof (img_info_t));
}
/* Make sure all pointers are NULL (also dump db as read) */
if (ret == 0)
Index: rebase.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebase.c,v
retrieving revision 1.10
diff -u -p -r1.10 rebase.c
--- rebase.c29 Jul 2011 13:17:44 - 1.10
+++ rebase.c5 Aug 2011 14:07:50 -
@@ -36,12 +36,6 @@
#include
#include
#include
-#if defined(__MSYS__)
-/* MSYS has no inttypes.h */
-# define PRIx64 "llx"
-#else
-# include
-#endif
#include
#include "imagehelper.h"
#include "rebase-db.h"
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [Patch] Add rebase-dump application to rebase package
On 8/5/2011 7:31 AM, Corinna Vinschen wrote:
> Your rebase-dump doesn't build cleanly on mingw64:
> Here's my fix:
> -printf ("== read %u (0x%08x) bytes (database header)\n",
> +printf ("== read %zu (0x%08zx) bytes (database header)\n",
> sizeof hdr, sizeof hdr);
Unfortunately, msys doesn't support %z:
== read zu (0x000zx) bytes (database header)
I see two solutions: (1) #ifdefs in some manner -- e.g. incode, or a
top-of-file defining the string to use for size_t arguments (decimal and
hex) or (2) use a temporary variable of type unsigned long long, and
assign the result of the sizeof() computation to that var, and then use
%llu or %llx.
Which approach do you think is better?
--
Chuck
Re: [patch/rebase] peflags.c: Use official file structures, make 64 bit capable
On Aug 5 13:17, Corinna Vinschen wrote:
> Hi Chuck,
>
>
> the below patch cleans up peflags so that it uses the official Windows
> types to access the COFF and PE flags via a memory map, rather than
> seek/read, seek/write to some undocumented byte offsets. This patch
> also makes peflags capable to read and change 64 bit files.
>
> Reading and writing other header info (namely stacksize) follows later.
>
> Patch builds and is tested on Cygwin and x86_64-mingw64.
>
> Ok to apply?
Second service. I left in everything I only added for debugging a
problem I had with my the native mmap implementation. For some reason
the data was never written back to the file. Turned out I had used
"flags" instead of "prot" in the conditionals. That was already fixed
in the previous patch, but the debug stuff was really supposed to go away.
Here we go, ChangeLog is unchanged...
Corinna
Index: peflags.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/peflags.c,v
retrieving revision 1.5
diff -u -p -r1.5 peflags.c
--- peflags.c 29 Jul 2011 13:17:44 - 1.5
+++ peflags.c 5 Aug 2011 12:50:29 -
@@ -29,25 +29,34 @@
#include
#include
#include
+#if defined (__CYGWIN__) || defined (__MSYS__)
+#include
+#endif
#include
-#if defined(__MSYS__)
-typedef unsigned short uint16_t;
-typedef unsigned int uint32_t;
+/* Fix broken definitions in older w32api. */
+#ifndef IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
+#define IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE
+#endif
+#ifndef IMAGE_DLLCHARACTERISTICS_NX_COMPAT
+#define IMAGE_DLLCHARACTERISTICS_NX_COMPAT IMAGE_DLL_CHARACTERISTICS_NX_COMPAT
+#endif
+#ifndef IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
+#define IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY
#endif
-static uint16_t coff_characteristics_set;
-static uint16_t coff_characteristics_clr;
-static uint16_t coff_characteristics_show;
-static uint16_t pe_characteristics_set;
-static uint16_t pe_characteristics_clr;
-static uint16_t pe_characteristics_show;
+static WORD coff_characteristics_set;
+static WORD coff_characteristics_clr;
+static WORD coff_characteristics_show;
+static WORD pe_characteristics_set;
+static WORD pe_characteristics_clr;
+static WORD pe_characteristics_show;
typedef struct {
long flag;
const char * name;
- uint32_t len;
+ size_tlen;
} symbolic_flags_t;
#define CF(flag,name) { flag, #name, sizeof(#name) - 1 }
@@ -118,29 +127,26 @@ static void version (FILE *f);
int do_mark (const char *pathname);
int get_characteristics(const char *pathname,
-uint16_t* coff_characteristics,
-uint16_t* pe_characteristics);
+WORD* coff_characteristics,
+WORD* pe_characteristics);
int set_coff_characteristics(const char *pathname,
- uint16_t coff_characteristics);
+ WORD coff_characteristics);
int set_pe_characteristics(const char *pathname,
- uint16_t pe_characteristics);
-static int pe_get16 (int fd, off_t offset, uint16_t* value);
-static int pe_get32 (int fd, off_t offset, uint32_t* value);
-static int pe_set16 (int fd, off_t offset, uint16_t value);
+ WORD pe_characteristics);
static void display_flags (const char *field_name, const symbolic_flags_t
*syms,
- uint16_t show_symbolic, uint16_t old_flag_value,
- uint16_t new_flag_value);
+ WORD show_symbolic, WORD old_flag_value,
+ WORD new_flag_value);
static char *symbolic_flags (const symbolic_flags_t *syms, long show, long
value);
static void append_and_decorate (char **str, int is_set, const char *name, int
len);
static void *xmalloc (size_t num);
#define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type)))
static void handle_coff_flag_option (const char *option_name,
const char *option_arg,
- uint16_t flag_value);
+ WORD flag_value);
static void handle_pe_flag_option (const char *option_name,
const char *option_arg,
- uint16_t flag_value);
+ WORD flag_value);
void parse_args (int argc, char *argv[]);
int string_to_bool (const char *string, int *value);
int string_to_ulong (const char *string, unsigned long *value);
@@ -221,10 +227,10 @@ do_mark (const char *pathname)
int has_relocs;
int is_executable;
int is_dll;
- uint16_t old_coff_characteristics;
- uint16_t new_coff_characteristics;
- uint16_t old_pe_characteristics;
- uint16_t new_pe_characteristics;
+ WORD old_coff_characterist
Re: [Patch] Add rebase-dump application to rebase package
On Aug 3 09:44, Charles Wilson wrote:
> On 8/3/2011 4:30 AM, Corinna Vinschen wrote:
> > Hmm. I just figured that moving the entire db stuff into rebase-db.c
> > isn't as simple as I imagined. Functions and global variables are
> > pretty much intertwined in a non modular way.
>
> Yep...I had similar, but much smaller, issues when moving the dump_*
> methods to rebase-db.[h,c]. This will be a non-trivial refactoring.
>
> > I assume you might just go ahead and apply your dumper and we get
> > a new rebase package out of the door. We can clean this up later.
>
> Ack. Given Jason hasn't reponded to my patch, and your positive review,
> I've invoked the libtool 3-day rule and committed it.
>
> > Idle musing: I think we should create some sort of global settings
> > structure which can be used as a parameter or something...
>
> Yep. That's typically the way I handle these issues, even in very simple
> apps that don't need it -- 'cause they ALWAYS grow to become non-simple,
> and it's a lot harder to add it later. :-)
>
> But that can also wait until after the next release. AFAICT, we're
> ready to go -- so it's up to Jason to bump the library and application
> version numbers, tag it in cvs, and publish a new package.
Your rebase-dump doesn't build cleanly on mingw64:
cc1: warnings being treated as errors
rebase-dump.c: In function ‘load_image_info’:
rebase-dump.c:128:6: error: format ‘%u’ expects type ‘unsigned int’, but
argument 2 has type ‘long long unsigned int’
rebase-dump.c:128:6: error: format ‘%08x’ expects type ‘unsigned int’, but
argument 3 has type ‘long long unsigned int’
rebase-dump.c:183:15: error: format ‘%u’ expects type ‘unsigned int’, but
argument 2 has type ‘long long unsigned int’
rebase-dump.c:183:15: error: format ‘%08x’ expects type ‘unsigned int’, but
argument 3 has type ‘long long unsigned int’
make: *** [rebase-dump.o] Error 1
Here's my fix:
Index: rebase-dump.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebase-dump.c,v
retrieving revision 1.1
diff -u -p -r1.1 rebase-dump.c
--- rebase-dump.c 3 Aug 2011 13:40:16 - 1.1
+++ rebase-dump.c 5 Aug 2011 11:31:28 -
@@ -124,7 +124,7 @@ load_image_info ()
return -1;
}
if (verbose)
-printf ("== read %u (0x%08x) bytes (database header)\n",
+printf ("== read %zu (0x%08zx) bytes (database header)\n",
sizeof hdr, sizeof hdr);
/* Check the header. */
@@ -178,7 +178,7 @@ load_image_info ()
}
if (ret == 0 && verbose)
{
- printf ("== read %u (0x%08x) bytes (database w/o strings)\n",
+ printf ("== read %zu (0x%08zx) bytes (database w/o strings)\n",
img_info_size * sizeof (img_info_t),
img_info_size * sizeof (img_info_t));
}
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
[patch/rebase] peflags.c: Use official file structures, make 64 bit capable
Hi Chuck,
the below patch cleans up peflags so that it uses the official Windows
types to access the COFF and PE flags via a memory map, rather than
seek/read, seek/write to some undocumented byte offsets. This patch
also makes peflags capable to read and change 64 bit files.
Reading and writing other header info (namely stacksize) follows later.
Patch builds and is tested on Cygwin and x86_64-mingw64.
Ok to apply?
Thanks,
Corinna
* peflags.c: Include sys/mman.h on Cygwin and msys. Drop conditional
definitions of uint16_t and uint32_t. Use WORD rather than uint16_t
throughout, size_t rather than uint32_t.
(IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE): Define if non-existant to
workaround broken w32api. Fix usage of broken definition throughout.
(IMAGE_DLLCHARACTERISTICS_NX_COMPAT): Ditto.
(IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY): Ditto.
(pe_get16): Remove.
(pe_get32): Remove.
(pe_set16): Remove.
(mmap): Define in terms of Win32 calls for non-Cygwin systems.
(munmap): Ditto.
(pe_file): New type to keep file mapping info.
(pe_open): New function to mmap PE/COFF files.
(pe_close): New function to unmap PE/COFF files.
(get_characteristics): Use pe_opem/pe_close and direct Windows
file structure access.
(set_coff_characteristics): Ditto.
(set_pe_characteristics): Ditto.
Index: peflags.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/peflags.c,v
retrieving revision 1.5
diff -u -p -r1.5 peflags.c
--- peflags.c 29 Jul 2011 13:17:44 - 1.5
+++ peflags.c 5 Aug 2011 11:09:42 -
@@ -29,25 +29,34 @@
#include
#include
#include
+#if defined (__CYGWIN__) || defined (__MSYS__)
+#include
+#endif
#include
-#if defined(__MSYS__)
-typedef unsigned short uint16_t;
-typedef unsigned int uint32_t;
+/* Fix broken definitions in older w32api. */
+#ifndef IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
+#define IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE
+#endif
+#ifndef IMAGE_DLLCHARACTERISTICS_NX_COMPAT
+#define IMAGE_DLLCHARACTERISTICS_NX_COMPAT IMAGE_DLL_CHARACTERISTICS_NX_COMPAT
+#endif
+#ifndef IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
+#define IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY
#endif
-static uint16_t coff_characteristics_set;
-static uint16_t coff_characteristics_clr;
-static uint16_t coff_characteristics_show;
-static uint16_t pe_characteristics_set;
-static uint16_t pe_characteristics_clr;
-static uint16_t pe_characteristics_show;
+static WORD coff_characteristics_set;
+static WORD coff_characteristics_clr;
+static WORD coff_characteristics_show;
+static WORD pe_characteristics_set;
+static WORD pe_characteristics_clr;
+static WORD pe_characteristics_show;
typedef struct {
long flag;
const char * name;
- uint32_t len;
+ size_tlen;
} symbolic_flags_t;
#define CF(flag,name) { flag, #name, sizeof(#name) - 1 }
@@ -118,29 +127,26 @@ static void version (FILE *f);
int do_mark (const char *pathname);
int get_characteristics(const char *pathname,
-uint16_t* coff_characteristics,
-uint16_t* pe_characteristics);
+WORD* coff_characteristics,
+WORD* pe_characteristics);
int set_coff_characteristics(const char *pathname,
- uint16_t coff_characteristics);
+ WORD coff_characteristics);
int set_pe_characteristics(const char *pathname,
- uint16_t pe_characteristics);
-static int pe_get16 (int fd, off_t offset, uint16_t* value);
-static int pe_get32 (int fd, off_t offset, uint32_t* value);
-static int pe_set16 (int fd, off_t offset, uint16_t value);
+ WORD pe_characteristics);
static void display_flags (const char *field_name, const symbolic_flags_t
*syms,
- uint16_t show_symbolic, uint16_t old_flag_value,
- uint16_t new_flag_value);
+ WORD show_symbolic, WORD old_flag_value,
+ WORD new_flag_value);
static char *symbolic_flags (const symbolic_flags_t *syms, long show, long
value);
static void append_and_decorate (char **str, int is_set, const char *name, int
len);
static void *xmalloc (size_t num);
#define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type)))
static void handle_coff_flag_option (const char *option_name,
const char *option_arg,
- uint16_t flag_value);
+ WORD flag_value);
static void handle_pe_flag_option (const char *option_name,
const char *option_arg,
-
Re: [RFU] SuiteSparse-3.6.1
On Aug 5 09:46, Marco atzeri wrote: > On 8/5/2011 9:41 AM, Corinna Vinschen wrote: > >On Aug 5 08:59, Marco atzeri wrote: > >>new upstream version > >> > >>To download: > >> > >>wget -r -np -nH --cut-dirs=2 \ > >>http://matzeri.altervista.org/cygwin-1.7/SuiteSparse/index.html > >> > >>rm ./index.html \ > >>./libSuiteSparse-devel/index.html > > > >Uploaded. What about the old versions 3.2.0-3, 3.4.0-3, 3.5.0-1? > > > > > >Thanks, > >Corinna > > > only 3.5.0-1 Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] SuiteSparse-3.6.1
On 8/5/2011 9:41 AM, Corinna Vinschen wrote: On Aug 5 08:59, Marco atzeri wrote: new upstream version To download: wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/SuiteSparse/index.html rm ./index.html \ ./libSuiteSparse-devel/index.html Uploaded. What about the old versions 3.2.0-3, 3.4.0-3, 3.5.0-1? Thanks, Corinna only 3.5.0-1 Thanks Marco
Re: [RFU] SuiteSparse-3.6.1
On Aug 5 08:59, Marco atzeri wrote: > new upstream version > > To download: > > wget -r -np -nH --cut-dirs=2 \ > http://matzeri.altervista.org/cygwin-1.7/SuiteSparse/index.html > > rm ./index.html \ > ./libSuiteSparse-devel/index.html Uploaded. What about the old versions 3.2.0-3, 3.4.0-3, 3.5.0-1? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
