I am trying to write a unix command line utility that will extract the "application" icon from a Windows Mobile executable. When I look inside the .exe with wrestool from the icoutils package, I see multiple icon and group_icon resources. I am trying to figure out which icon the Windows Mobile Programs view would choose to display to the end user.
At first, I figured it would be the icon with name 32512 (IDI_APPLICATION), but then I found several Windows Mobile binaries that lacked this icon resource, but sure enough had visible icons in the Programs view.
Is there a simple but correct algorithm? like lowest resource id? Is there another resource in the .exe that tells me what is the application icon? Is there something obvious that I am missing?
Any insight would be appreciated.
It's the first RT_GROUP_ICON resource in the executable.
Let's show by steps. First, you need to look what is inside your EXE:
wrestool -l file.exe
Normally, the best icon its the first GROUP_ICON, but when the GROUP_ICONs names are words instead of numbers, then is the GROUP_ICON with the biggest size (or the second biggest size if the first GROUP_ICON is blank, you will need to extract both).
wrestool -x -t14 -n(GROUP_ICON name) file.exe > file.ico
If you want to create a perfect code, you probably should include the GROUP_ICON language too (sometimes the exe won't have a language (16-bit applications), so you will need to put both of the codes):
wrestool -x -t14 -n(GROUP_ICON name) -l(GROUP_ICON language) file.exe > file.ico
In some apps, the GROUP_ICON extraction will fail. That's because some new apps (like new games) are using GROUP_ICON as a link, and inserting the real icons inside ICONs. Then, you will need to extract the biggest ICON with that code:
wrestool -x -R -t3 -n(ICON name) -o. file.exe > file.ico
BUT there will be a BIG problem. That will extract the ICON, but a little part of the file will be missing, which is essential to open this file as an .ico. You will need to open that file in a Hexadecimal Editor and insert in the file a little HEX code before everything else.
00 00 01 00 01 00 80 80 00 00 01 00 18 00 28 C8 00 00 16 00 00 00
Probably, now you think this is the end. NO. The worse part is coming: extract the correct pic from the ICO. Firstly, you will need not only wrestool, but icotool. Then, use that code:
icotool -l file.ico
Then, you will need to extract the file with the biggest width, height and bit-depth.
icotool -x -o. -w(Width) -h(Height) -b(Bit-depth) file.ico
The result will be a PNG file with the perfect icon. Sometimes, that code can fail (Example: The program "Robust Motion Deblurring"), then you will need a second conversor to change from ICO to PNG, but that conversor can fail in some cases (Example: The game "Mass Effect"), so you probably will need both in your code.
I have used that logic in an Objective-C program once, so I know that it's functional (and until now, with 99,9% of success).
Related
In terminfo(5):
Variable String
Capname
TCap Code
Description
cursor_up
cuu1
up
up one line
key_up
kcuu1
ku
up-arrow key
I tried with tput and they produce the same output:
$ tput cuu1 | hd -C
00000000 1b 5b 41 |.[A|
00000003
$ tput kcuu1 | hd -C
00000000 1b 5b 41 |.[A|
00000003
In a terminfo description, names beginning with k denote keys, while other names are used for non-key capabilities. For most keys, there is no readily apparent relationship between the keys and an existing escape sequence, but cursor-keys are the exception.
Whether they are the same or not depends upon the terminal description. For TERM=linux, they happen to be the same, however a terminal description could be written for the Linux console where they are not.
The distinction is whether the terminal is initialized into application mode or left in the (default/power-up) normal mode. In application mode, the cursor keys would send EscapeO as a prefix rather than Escape[.
A little over half (54%) of the terminal descriptions in the ncurses terminal database use application mode, meaning that cuu1 is more often than not different from kcuu1.
There's another quirk to be aware of: for other cursor movement, such as cud1, the terminal description may say \n, while the key for cursor-down would not send that character (see iTerm for example).
Further reading:
My cursor keys do not work
cursor_up is the control sequence sent by the host to the terminal to move the cursor up a line.
key_up is the control sequence sent by the terminal to the host when the up arrow key is pressed.
In VT100-based terminals (which includes all sane modern terminal emulators), these sequences are identical. However, some older terminal hardware may have used different sequences in these two roles, so terminfo keeps them separate.
I'm looking for GPS metadata inside a photo. I know I can use ExifTool and many other tools but I want to analyse the photograph at hex level. So I read that Exif metadata is stored in an APP1 section and there may be more than one APP1 section. The application data in an Exif
APP1 section begins with: 45 78 69 66 00 00 So I looked around there, but nothing.
I then looked at the exif-spec for GPS (http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/GPS.html) and it said that latitude is at offset 0x0002. Offset 0x0002 is the header of the JPG (FF D8 FF).
At the top of the top of the exif GPS specs, it says that the tags may be in a different IFD(image
file directory) within the exif information.
So I'm a bit confused now. Anyone know a proven method of viewing GPS exif in hex?
Thanks in advance.
Yes. ExifTool to the rescue:
1) exiftool -htmldump image.jpg > out.html
2) open "out.html" with your favourite web browser
As far as I know, ExifTool is the best (only?) hex dump utility for TIFF/EXIF metadata.
I am opening a text file in Ada with the following code:
Open (File => out_parcial_variante1, Name => "c.txt", Mode => append_file);
put(File => out_parcial_variante1, Item=> "r");
close(out_parcial_variante1);
The file as a structure like this inside:
01 #510.00:1003.00,512.04:1110.00,515.00:998.00,-98.00,-100.00
<second empty line, this text is not in the file>
Note that besides the initial line the cursor is in a second line there with nothing written.
Whenever my code writes in the file, this happens:
01 #510.00:1003.00,512.04:1110.00,515.00:998.00,-98.00,-100.00
r
It creates another newline instead of appending on the 2nd line like this:
01 #510.00:1003.00,512.04:1110.00,515.00:998.00,-98.00,-100.00
r
How do I fix this?
EDIT: It's a pointer problem since I read the whole line before, but I try to close and open the file again and the pointer remains in the second line instead of going back to the beginning.
I threw together a quick test program with GNAT 2012 on Windows and it works as expected.
Code:
with Ada.Text_IO;
use Ada.Text_IO;
procedure Append_Test is
OPV: File_Type;
begin
Open (OPV, Append_File, "c.txt");
Put (OPV, "r");
Close (OPV);
end Append_Test;
I programmatically created the c.txt file, using Put_Line to output the text, this was the contents of the file:
01 #510.00:1003.00,512.04:1110.00,515.00:998.00,-98.00,-100.00
I used Cygwin's od -t x1 to dump the file, and saw that it terminated with a 0d 0a EOL sequence, i.e. CR/LF.
Running the above code resulted in a file containing the expected output:
01 #510.00:1003.00,512.04:1110.00,515.00:998.00,-98.00,-100.00
r
Again dumping with od showed the file ending with 0d 0a 72 0d 0a. That's the original EOL, to which is appended the 'r' and another EOL.
If this isn't happening for you, then it's not clear what you're actually doing. (Note that on Linux the 0d 0a sequences would instead be simply 0a.)
We've recently moved a website to a new server, and are running into an odd issue where some uploaded images with unicode characters in the filename are giving us a 404 error.
Via ssh/FTP, we can see that the files are definitely there.
For example:
http://sjofasting.no/project/adnoy
none of the images are working:
Code:
<img class='image-display' title='' src='http://sjofasting.no/wp/wp-content/uploads/2012/03/ådnøy_1_2.jpg' width='685' height='484'/>
SSH:
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 836813 Aug 3 16:12 ådnøy_1_2.jpg
What is also strange is that if you navigate to the directory you can even click on the image and it works:
http://sjofasting.no/wp/wp-content/uploads/2012/03/
click on 'ådnøy_1_2.jpg' and it works.
Somehow wordpress is generating
http://sjofasting.no/wp/wp-content/uploads/2012/03/ådnøy_1_2.jpg
and copying from the direct folder browse is generating
http://sjofasting.no/wp/wp-content/uploads/2012/03/a%CC%8Adn%C3%B8y_1_2.jpg
What is going on??
edit:
If I copy the image url from the wordpress source I get:
http://sjofasting.no/wp/wp-content/uploads/2011/11/Bore-Strand-Hotellg%C3%A5rd-12.jpg
When copied from the apache browser I get:
http://sjofasting.no/wp/wp-content/uploads/2011/11/Bore-Strand-Hotellga%cc%8ard-12.jpg
What could account for this discrepancy between:
%C3%A5 and %cc%8
??
Unicode normalisation.
0xC3 0xA5 is the UTF-8 encoding for U+00E5 a-with-ring.
0xCC 0x8A is the UTF-8 encoding for U+030A combining ring.
U+0035 is the composed (Normal Form C) way of writing an a-ring; an a letter followed by U+030A is the decomposed (Normal Form D) way of writing it. å vs å - they should look the same, though they may differ slightly depending on font rendering.
Now normally it doesn't really matter which one you've got because sensible filesystems leave them untouched. If you save a file called [char U+00E5].txt (å.txt), it stays called that under Windows and Linux.
Macs, on the other hand, are insane. The filesystem prefers Normal Form D, to the extent that any composed characters you pass into it get converted into decomposed ones. If you put a file in called [char U+00E5].txt and immediately list the directory, you'll find you've actually got a file called a[char U+030A].txt. You can still access the file as [char U+00E5].txt on a Mac because it'll convert that input into Normal Form D too before looking it up, but you cannot recover the same filename in character sequence terms as you put in: it's a lossy conversion.
So if you save your files on a Mac and then transfer to a filesystem where [char U+00E5].txt and a[char U+030A].txt refer to different files, you will get broken links.
Update the pages to point to the Normal Form D versions of the URLs, or re-upload the files from a filesystem that doesn't egregiously mangle Unicode characters.
Think Different, Cause Bizarre Interoperability Problems.
I want to modify GDLC MP4 Muxer so that
it will not send data to other writer but it will just record it
itself to a file data itself...
It will be not a muxer any more...it will be a writer which have mp4 muxer...
But firstly i have to figure out, where is the last [muxed] data stay , so that i can write it to a file...
To get a playable file, i have to write the data where?
My Attempts:
I put debug info and see that it calls Append and this method call Replace periodically...I write the buffer [ BYTE pBuffer] which is given to Append method of MuxOutput .I get binary data which has some headers but not playable...So it its wrong place or i do it wrong.....Then i check what calls Append --- FillSpace methos and YUVVideoHandler::WriteDescriptor... But can not able to get usefull info from other methods call Append...
UPDATE
Well, i can able to write data to file at MuxOutput::Replace method...The problem is that the header info and footer(tables at the end of file) are wrong... The other data [ payload data] is correct... The playable file which is recorded by File writer started with 00 00 00 18...[hexadecimal] but my recorded data start with 00 00 00 08 [hexadecimal].... when i replace the mp4 header and footer parts with the file generated by the file writer using a hex editor tool, file becomes identical and plays.
What may be the problem?
In Mpeg4Mux::Pause, the MovieWriter is created with a pointer to an AtomWriter interface (in my case, implemented by the output pin by calls to the downstream file-writer filter). All writes to the file are via this interface. The data is written first, and then on stop, the index data (moov chunk) is written and the file header and data chunk headers are updated.
G
I think your problem is caused by Random File Access requirement which is supported by File Writer Filter by default. The steps you need to follow is:
1) Create an empty file at the beginning
std::ofstream outFile;
outFile.open("c:\\out.mp4", ios_base::out | ios_base::binary);
outFile.close();
2) Open file for random access
outFile.open("c:\\out.mp4", ios_base::in | ios_base::out | ios_base::binary);
3) Right after output pin's Write() method add these lines (replace position, buffer and bufferSize with suitable variable names)
outFile.seekp(position);
outFile.write(buffer, bufferSize);
4) At the end of the recording session (somewhere like a Close() method of the muxer) add
outFile.close();
And you are done.