I'm trying to create a Fortran code for defining processor id. I can write the processor id into a text file. The text file pid2.txt is created but I can not read it in Fortran. While I open the text file in notepad or NotePad++ everything seems OK! In Fortran when I opening the text file it shows unknown parameter. Can any body help me with this problem?
The content of text file is
ProcessorId
BFEBFBFF00010676
The sample code is as below:
program get_PID
implicit none
character(200) :: line
call system('wmic cpu get ProcessorId >pid2.txt ' )
open (1,file='pid2.txt')
read (1,*) line
read (1,*) line
CLOSE (1)
end program
Do you have any advice?
The issue in your case is the encoding of the ouput from wmic. Windows uses UTF-16 as default. Fortran cannot handle this encoding yet. Referring to the help of Intel Fortran, only UTF-8 is supported as described here.
Therefore you have to change the encoding of the output to ANSI and/or your local codepage. This can be done by piping the result of wmic through the more command as described on SO superuser site under combine-batch-wmic-ansi-unicode-output-formatting.
Please change your system call as follows:
call system('wmic cpu get ProcessorId | more >pid2.txt ' )
You'll get the processor ID information in your code now, as expected.
Hope it helps.
Related
The following code snippet sends PostScript content (saved in pBuf buffer) to a CutePDF printer:
if (OpenPrinter(printerName, &hPrinter, NULL))
{
DOC_INFO_1 di1;
di1.pDatatype = L"RAW";
di1.pDocName = L"Raw print document";
di1.pOutputFile = NULL;
StartDocPrinter(hPrinter, 1, (LPBYTE)&di1);
StartPagePrinter(hPrinter);
DWORD dwWritten = 0;
WritePrinter(hPrinter, pBuf, dwBufSize, &dwWritten);
EndPagePrinter(hPrinter);
EndDocPrinter(hPrinter);
}
During the execution of this code, a dialog appears where I specify the name of the output file (e.g. D:/out.pdf), after that the pdf file is generated. So far so good. The problems begin when I'm trying to avoid the filename specifying step by changing Line 4 of the snippet:
di1.pOutputFile = L"D:/out.pdf";
Such code doesn't show the dialog during its execution (as expected), but the result D:/out.pdf isn't a pdf file, it's a copy of the PostScript file sent to the printer (copy of the contents of pBuf buffer). PDF Writer behaves in the same way. Why do PDF printers behave in this way and how can I achieve the needed behaviour (generate PDF file without specifying its name in UI)?
The Windows print system behaves this way, because, to be blunt, that's how its supposed to behave. If you specify a filename at that point then the print system sends the output to that file. If you don't specify a filename then it proceeds to normal processing.
Normally you would send the printer driver output to a port, and in the case of PDF printers a custom port monitor would pick up the output (PostScript in this case) and process it further. For PDF printers they send the PostScript on to a process which converts the PostScript to PDF (almost always using Ghostscript, though the Adobe print to PDF tools work the same way).
If you want to alter the output of the PDF process (ie write it to a different file), then you need to alter the way the port monitor works, not the way the print subsystem works, which is what your code is currently doing. By setting a filename where you are, you are simply short-circuiting the process, never invoking the port monitor, which is why the 'save file' dialog does not appear, and why the output is PostScript.
There may be a way of specifying the output file documented for the specific PDF printer you are using. If not, then for open source products (and if GS is built in they should be GPL licensed) you can request a copy of the source code for the product and alter it to suit yourself.
Alternatively, you can pick up a copy of Ghostscript and RedMon (open source Port Monitor) and create your own tool for doing the same job.
How I can to read any gdsii file in python,or Convert gds file into text format using gds2text script?
If you can use a C/C++ compiler you might consider using gds2gdt and gdt2gds to read and/or write GDSII using any language/shell of your choice. GDSII is a stream of records each of which is represented in a single line of compact GDT format text. For instance:
p{10 w1.2 xy(41.2 17.1 41.2 33.9)}
is a two-point path on layer 10 with a width of 1.2. you can run these programs externally or call them within your program similar to reading/writing a text file.
https://sourceforge.net/projects/gds2/
Well this time I'm trying to write a program in C which recover deleted files from a disk, it could be an external disk, I have an idea than i had used before on linux, it is to open the disk as a kind of file and scaning the Headers and file footers of everything within the disk, the point is I'm not sure if there's allow on windows to open a disk as an File, basiclly I have the logic how to develope this program, but I'm not sure how to implement it on windows, anybody can give me a hand with this?.
The code I used on linux to open a disk as a file was:
Edit: That was a sample of what I was using guys, it's just to give you an idea of what I was doing, the correct syntax I used was the next:
direccion = ui->linea->text().toLatin1().constData();
f = fopen(direccion,"rb");
I used QT creator on linux, and direccion variable was a TextField value which contained the file path of the disk through a button function that open a QFileDialog...
could I use it in windows as well?
Thank you before hand..
"The code I used on linux to open a disk as a file was:"
File *f = fopen("E:\", "rb");
I seriously doubt you ever got this code working on any linux system (or windows either).
You'll need to escape the backslash path delimiter, if it's presented in any string literal:
FILE* f = fopen("E:\\", "rb");
// ^
Also all that filesystem path style you are presenting to access a particular disk, is about accessing a windows file path/disk.
No linux file system has notion about drive characters, and the file path delimiter value used is '/', not '\\'.
To recover deleted files, you can't use fopen or fstream::open because the file was deleted. Check the return value from the function or test the stream state.
The way to recover deleted files is:
Get the Master File Table as raw data.
Search for the record containing a string similar to the deleted
filename.
Change the entry in the Master File Table to "undeleted".
Write the Master File Table back to the drive.
The above usually requires platform specific API, which is different on Linux and Windows platforms.
I'm porting a source code to open/read/write a file shared between several process. It works well under windows and as it was mainly using boost::interprocess (1.44) I didn't expecting too many issue but I found something weird:
//pseudo code
namespace bip = boost::interprocess;
namespace bipd = boost::interprocess::detail;
loop
bip::file_handle_t pFile = bipd::create_or_open_file(filename, bip::read_write);
bipd::acquire_file_lock(pFile);
// try to read bytes from pFile with 'read'
bipd::truncate_file(pFile, 0);
bipd::write_file(pFile, (const void*)(textBuffer)), bufLen);
When the code run the first time it create the file and write a text. The file mode is ASCII (ASCII text, with very long lines) and I can read the text.
But when the loop run for the second times, the file type change to
data and the textBuffer is in the file but as binary data !
I inspected boost/interprocess/details/os_file_functions.hpp but I didn't find a reason for that behavior.
Have you an idea ?
Finally, I found a solution....
It ssems that if you are at the end of the file (file pointer position after the ::read), the ::ftruncate function used in the implementation of `boost::interprocess::detail::truncate_file' lead to the incorrect behavior.
to keep the same behavior under Linux and Windows (keep my file type as ASCII Text), I used a simple ::seek(id,0,SEEK_SET).
I didn't find that trick in all the page I read !
I have a C++ code I am running in Linux with wine. I think this is actually part of the problem.
Usually, when I do something like this in a native Linux C++ program:
ofstream fout;
fout.open("myfile.txt")
fout<<"blah blah"<<endl;
fout<<"blah blah 2"<<endl;
fout.close;
The file is standard ASCII text. However, in the code I an running under wine, myfile.txt is now ASCII text with CRLF line terminators.
This is a problem because if I want to read the file using a native Linux C++ code running on the same machine, the CRLF line terminators really mess up a lot of the file handling and parsing.
Is there a way to get the code running under wine to output files without CRLF line terminators and in a fashion that I can read it using the native Linux C++ code on the same machine?
You could open the file in ios::binary mode. This doesn't, strictly speaking, mean that it's a binary file [any more than any other file is "text", since all files are binary]. Binary in this context just means "don't muck about with the stuff inside the file by interpreting characters as special, add or remove any characters, etc.
Or when you copy the file to Linux, use dos2unix myfile.txt to convert it from "dos" (and Windows) format to "unix" style text file.