Re: [patch/rebase] Open file only once
On 8/6/2011 3:25 PM, Corinna Vinschen wrote: > here's another simplification of peflags. The file gets opened and > closed in do_mark now. get_xxx and set_xxx get the pe_flags pointer > rather than the filename as parameter. > > Ok to apply? Sure, with minor changes: there are a couple of early returns where you need to call pe_close() first. line 281 line 353 line 361 -- Chuck
[patch/rebase] Open file only once
Hi Chuck,
here's another simplification of peflags. The file gets opened and
closed in do_mark now. get_xxx and set_xxx get the pe_flags pointer
rather than the filename as parameter.
Ok to apply?
Corinna
* peflags.c (pe_file): Move definition to start of file.
(pe_open): Declare.
(pe_close): Declare.
(do_mark): Call pe_open/pe_close here. Call get/set functions
weith pe_file pointer instead of filename.
(get_characteristics): Change first parameter to pe_file pointer.
Drop calls to pe_open/pe_close.
(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.6
diff -u -p -r1.6 peflags.c
--- peflags.c 6 Aug 2011 08:30:00 - 1.6
+++ peflags.c 6 Aug 2011 19:23:06 -
@@ -53,6 +53,17 @@ static WORD pe_characteristics_set;
static WORD pe_characteristics_clr;
static WORD pe_characteristics_show;
+typedef struct
+{
+ PIMAGE_DOS_HEADER dosheader;
+ union
+{
+ PIMAGE_NT_HEADERS32 ntheader32;
+ PIMAGE_NT_HEADERS64 ntheader64;
+};
+ BOOL is_64bit;
+} pe_file;
+
typedef struct {
long flag;
const char * name;
@@ -126,12 +137,14 @@ static void help (FILE *f);
static void version (FILE *f);
int do_mark (const char *pathname);
-int get_characteristics(const char *pathname,
+pe_file *pe_open (const char *path, BOOL writing);
+void pe_close (pe_file *pep);
+int get_characteristics(const pe_file *pep,
WORD* coff_characteristics,
WORD* pe_characteristics);
-int set_coff_characteristics(const char *pathname,
+int set_coff_characteristics(const pe_file *pep,
WORD coff_characteristics);
-int set_pe_characteristics(const char *pathname,
+int set_pe_characteristics(const pe_file *pep,
WORD pe_characteristics);
static void display_flags (const char *field_name, const symbolic_flags_t
*syms,
@@ -249,7 +262,16 @@ do_mark (const char *pathname)
}
}
- if (get_characteristics (pathname,
+ pe_file *pep = pe_open (pathname, mark_any != 0);
+ if (!pep)
+{
+ fprintf (stderr,
+ "%s: skipped because could not open\n",
+ pathname);
+ return 0;
+}
+
+ if (get_characteristics (pep,
&old_coff_characteristics,
&old_pe_characteristics) != 0)
{
@@ -323,7 +345,7 @@ do_mark (const char *pathname)
/* setting */
if (new_coff_characteristics != old_coff_characteristics)
-if (set_coff_characteristics (pathname,new_coff_characteristics) != 0)
+if (set_coff_characteristics (pep, new_coff_characteristics) != 0)
{
fprintf (stderr,
"Error: could not update coff characteristics (%s): %s\n",
@@ -331,7 +353,7 @@ do_mark (const char *pathname)
return 1;
}
if (new_pe_characteristics != old_pe_characteristics)
-if (set_pe_characteristics (pathname,new_pe_characteristics) != 0)
+if (set_pe_characteristics (pep, new_pe_characteristics) != 0)
{
fprintf (stderr,
"Error: could not update pe characteristics (%s): %s\n",
@@ -360,6 +382,8 @@ do_mark (const char *pathname)
puts ("");
}
+ pe_close (pep);
+
return 0;
}
@@ -713,17 +737,6 @@ munmap (void *addr, size_t len)
}
#endif
-typedef struct
-{
- PIMAGE_DOS_HEADER dosheader;
- union
-{
- PIMAGE_NT_HEADERS32 ntheader32;
- PIMAGE_NT_HEADERS64 ntheader64;
-};
- BOOL is_64bit;
-} pe_file;
-
pe_file *
pe_open (const char *path, BOOL writing)
{
@@ -767,13 +780,10 @@ pe_close (pe_file *pep)
}
int
-get_characteristics(const char *pathname,
+get_characteristics(const pe_file *pep,
WORD* coff_characteristics,
WORD* pe_characteristics)
{
- pe_file *pep = pe_open (pathname, FALSE);
- if (!pep)
-return 1;
if (pep->is_64bit)
{
*coff_characteristics = pep->ntheader64->FileHeader.Characteristics;
@@ -784,37 +794,28 @@ get_characteristics(const char *pathname
*coff_characteristics = pep->ntheader32->FileHeader.Characteristics;
*pe_characteristics = pep->ntheader32->OptionalHeader.DllCharacteristics;
}
- pe_close (pep);
return 0;
}
int
-set_coff_characteristics(const char *pathname,
+set_coff_characteristics(const pe_file *pep,
WORD coff_characteristics)
{
- pe_file *pep = pe_open (pathname, TRUE);
- if (!pep)
-return 1;
if (pep->is_64bit)
pep->ntheader64->FileHeader.Characteristics = coff_characteristics;
else
pep->ntheader32->FileHeader.Characteristics = coff_characteristics;
- pe_close (pep);
return 0;
}
int
Re: 256x256 px icons
On 6 August 2011 09:28, Corinna Vinschen wrote: > On Aug 5 11: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. >> >> 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 > > Thank you very much. I created an icon set from there. The fact that > everything is layered is cool. You can simply change a single aspect of > the picture. What I did: > > - In general the dark shadow of the wedge became too dark (IMHO) when > resizing the image to smaller sizes. The wedge looked pretty > asymmetrically when small. So I lightend the shadow quite a bit > before scaling it down.cd > > - For the 256x256 icon I darkened the C stroke a bit, for 48x48 and below > I used an entirely white stroke before scaling down. > > - For the 256x256 icon I kept the dark outer glow, for the smaller sizes > I removed it. Makes sense. If the outline needs to be any brighter, it would need to be thickened before scaling down. > The 16x16 icon looks blurry when magnified to 800% in gimp, but I'm > surprised how good it looks in normal 100%. I agree. > Is that one ok as default Cygwin icon? I think so. > I'm going to work on the terminal icon based on Andy's blank-terminal > icons and this beveled icon next, as well as on a new setup "box" icon. Looking forward to those. I seem to be in a minority of one regarding the logo-in-terminal approach, so I withdraw my objection to that. Andy
Re: [patch/rebase] peflags.c: Use official file structures, make 64 bit capable
On Aug 5 18:18, Charles Wilson wrote: > 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. Thanks, applied. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: SETUP: default to mintty
On Aug 5 21:04, Andy Koppe wrote: > Going back to the 256x256 PNG I put into the icon though, it's > actually only 16KB, so do find that attached. Also attached is the > 52KB 768x768 version exported from InkScape that I'd generated the > smaller ones from by scaling them down in Paint.net. *grab* Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: SETUP: default to mintty
On 5 August 2011 21:45, Warren Young wrote: > 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. Thanks! (I'd only looked at the man page, where the -r option doesn't appear at all.) >> 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. That makes plenty of sense. >> 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. Right. Now we just need to work out what exactly to put in it. :) Andy
