I have raw microfocus cobol data file and copybook from old unix server. And wants to read it raw on pc without cobol.
As I scan the file header, found out this is idx format 8 file with compression. How to read this file?
Related
I read some where that in stm32 .bin file reflects exactly as it is in flash but when I compare my flash content(by using cube Programmer) & .bin file(which is generated by keil IDE), they were different from each other?
do any one know why they are different?
Flash contents
Bin file
The data is always the same.
This is a little-endian platform so when you display it as words the digits are in a different order to when you display it as bytes.
I've files with various languages. Tried Notepad ++ and cpconverter but they didnt help as some codepages like codepage 942 or codepage 1381 are not available.
This is an image from IBM machine running on 4690 OS
If it is in binary format, Please make use any of the Hex editor tools to view the contents of the file but before that you should be well versed about the contents (ex: TLOG strings if its Transaction data) to understand the details.
As per my knowledge delphi files having same structure as win32 pe files. And the only difference in resource section i.e RCDATA resource section contains resource with name DVCLAL
My questions are:
Is there any difference in headers of win32 pe and delphi pe.
If there is no difference is no difference in structure then how to differentiate.
If there is difference then what it is?
What changes can be done by malware writers in delphi files.Any example.
What are the file formats of delphi file and win32 pe file.
There is no such thing as a Delphi PE file. Delphi compiled executables, on Windows, use the common platform format, which is PE.
I am writing a C#/C++ program which will decompress win8 hibernation file. However, I haven't found hiberfil.sys format for new OS.
Is there any description of Win8 hiberfil.sys file format to parse it?
That file is not new to Win 8. However, I'm not sure whether the format has changed over time. In any case, here's a link to a PDF from 2008 that describes the file and some tools.
I'm using the IdFTP (Indy 10) component to download some files (zip and txt) from a remote location. Before getting each file I set the TransferType to binary.
IdFTP.TransferType := ftBinary;
IdFTP.Get(ASource, ADest, AOverwrite);
I expect that both text and binary files can be downloaded using the binary mode. However it looks like text files contents is messed up while zip files are downloaded correctly. If I set the TransferType to ASCII for text files it works as expected. How can I detect which TransferType to set for a given file? Is there a common denominator or auto setting?
I don't see how the Binary flag can mess up transferred files. Binary type means the server transfers the files without any processing, as is.
The only thing that an FTP server should use the ASCII flag for, is to correctly handle the end of line in text files, usually (1) either only Line Feed in Unix or (2)Carriage Return + Line Feed in Windows. But nowadays most text editors handle both in either system.
So the safest is use only ASCII flag for very well known text files, probably only files with a .txt extension, and use Binary flag for all the others.
When in doubt, rule it out (!) - try transferring the files from the server using the Windows commandline FTP program, and see if text files still come out wrong. The program will transfer binary (command BIN) or text (command ASCII). If you transfer files with this and they still arrive differently to your expectation, then something is being done at the server end*. If they arrive fine, then either you (or Indy) are doing something. :-)
*In what way are the text files messed up? If you're transferring unicode text files, you might be better off transferring them as BINary anyway. I must admit that, as #unknown (yahoo) said, in most cases you should probably stick to BIN mode.
I guess it would also depend on how you are viewing the text file, ANSI or WideChar as to whether the text is messed up or not.