|
I assume it's not working because the text file contains a textual representation of the file's data, not the raw data itself. You'd have to parse the text file and write out the corresponding raw data.
Steve
|
|
|
|
|
The best way (only sensible way) is to write code in C or C++ and then use a compiler and linker to generate the "hex code", that is after all, how notepad.exe is created.
Nobody writes binary/hex machine code these days, it's just unheard of.
Besides, the "hex code" you see in notepad is a highly organized file, it is defined by the Microsoft COFF/PE format.
You can download and see this here: http://www.microsoft.com/whdc/system/platform/firmware/pecoff.mspx[^]
The structire is complex, fiddly and requires a great deal of metadata - usually managed by the compiler - in order to work. Unless each section is correctly formed, and correctly linked to other sections and its lengths etc correct, it will just crash when you try and run it.
What is your motive for this question?
Harry.
|
|
|
|
|
As other people have said you need something to convert the textual representation of the code back into binary again. It's a fairly pointless excercise though as it'll be the same as the original.
IF you want to do this so you can change the executable then there's going to be a few things that stand in your way:
- checksums and signatures need to be recalculated. The checksum's easy enough, the signature is going to be a bind
- You'll have to modify the executable header to take into account any change in section offsets
It's a lot hard modifying a windows executable than it was an old DOS one. This is one of the reasons why viruses are so much less prevalent under Windows and malware authors have turned their attention to Worms and Trojans.
Cheers,
Ash
|
|
|
|
|
In my experience the checksum in most files is 0 and not used.
Steve
|
|
|
|
|
Dears,
I want to develop an application which counts the bytes transfered from/to the network.
Is there any API which provides the network byte transfer information of an application?
thanks in advance.
Krishnakumar
|
|
|
|
|
I don't know any API for that, but you could try injecting a DLL into applications and hooking the functions used for sending/receiving bytes and counting, no idea though how hard a task that would be.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I'd guess the proper way to do it is by creating a Firewall-like thingy that sits in the path to the outside world and counts everything that goes through it. IIRC there are some firewall articles here on CP.
|
|
|
|
|
I wonder, would a firewall be able to detect what application a certain packet is coming from or going to?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I don't think so. It would see network packets, hence IP addresses and port numbers, nothing of a higher-level intelligence.
|
|
|
|
|
Theoretically if you could somehow obtain a list of the sockets on the system and find out what socket is bound to which port and also which process the socket belongs to you could look up the connection between the packet and the application i guess. how you'd do that is another question.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Have a look at WinPCAP[^], it might do the sort of thing you're interested in. It's used as the basis for Ethereal/Wireshark/whatever they're calling it this week so it sound be possible for you to sort out what's coming and going to where.
Cheers,
Ash
|
|
|
|
|
|
Krishnakumartg wrote: Is there any API which provides the network byte transfer information of an application?
You could look at the Performance Counters.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Thread A
Thread B
executing Thread A
{
Thread B
Sum = Whatever;}
I'm currently running Thread A, but I want to hold Thread A execution when it calls Thread B.
After Thread B finishes it should resume execution on Sum in Thread A!
|
|
|
|
|
Fareed Rizkalla wrote: I want to hold Thread A execution when it calls Thread B.
After Thread B finishes it should resume execution on Sum in Thread A!
In that case there is little point in using threads, just make B a function that is called from A.
It's time for a new signature.
|
|
|
|
|
Call WaitForSingleObject in thread A on the handle of thread B.
|
|
|
|
|
Is the intent to eventually reach this scenario?
hread A
Thread B
Thread C
Thread D
executing Thread A
{
Thread B
Thread C
Thread D
Sum = Whatever;
}
This is a common parallel model that can either be handled with a worker system (easier) or in a parallel reduce[^] operation.
If not, I agree, chaining one and only one thread with a wait would be handled much more efficiently by a direct function call.
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
It's called a function call, instead of inefficently farting around with threads just call the function.
Go on, it's not so complicated but it works!
Cheers,
Ash
|
|
|
|
|
I get the feeling that certain educational establishments are teaching threads far too early in the curriculum.
It's time for a new signature.
|
|
|
|
|
I'm not sure if it's an educational thing - I've seen programmers go thread happy several times over my career. There's something intrinsically seductive about parallel programming to loads of programmers even when it's not needed.
Actually, having thought about it a bit more it might be an educational thing, but not related to teaching programming for once. A couple of years ago I did an MSc in Software Engineering and the Operating Systems module was obsessed with threads, scheduling and all things to do with multiprogramming. We spent twice as long on that as we did on either device management and file systems which are far more important.
So I'll settle for the people writing OS textbooks and the lecturers who teach it. The language teachers aren't responsible for that, they're just obsessed with pointers and intrinsic arrays.
Cheers,
Ash
|
|
|
|
|
Yes, I don't really have any evidence for this but I just find it strange that people with (apparently) fairly limited understanding of some basic aspects of programming are already working with threads. Particularly when, as would seem in this case, there is absolutely no point in creating a thread just to run a function.
It's time for a new signature.
|
|
|
|
|
Richard MacCutchan wrote: Particularly when, as would seem in this case, there is absolutely no point in creating a thread just to run a function.
My personal opinion only.... It is that there is no realistic examples for teaching programming. Since the problem for threading serves no purpose related to threading, nor the example for single process systems, the result is a complete lack of understanding of when and how to use threading.
I have seen as many thread happy people, and people deathly afraid of threads. Even one programmer who swore up and down that mutexes were required in threads to speed it up. All mutex operations supposedly would speed up your threads and coding without mutexes would automatically devolve back to a single process operation because the mutex was the key to multi-processing....
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
I'm working with very large files and i need to be able to get a 64bit stream position.
ofstream::tellp() returns a streampos, which according to msdn is typedef fpos<mbstate_t> streampos;
Whatever i try and cast the result to, it's wrong for files over 4GB- it's being truncated at 32 bits.
What is odd is that according to mssn, fpos<t> stores a byte offset of type streamoff, and a conversion state of type T. streamoff (according to msdn) is a long in win32 and an __int64 in win64. I am building under win32 but the debugger shows the private _Fpos member of fpos<t> to be of type __int64.
So, irritatingly, the 64 bit value is there in the fpos (i can see in the debugger, it's correct) but i can't get the value out.
Any ideas? there must be a way of getting a 64bit file pos in win32.
|
|
|
|
|
|
What happens when you use the seekpos member of std::fstream::pos_type (i.e. the thing returned by tellp)?
As far as I can tell that's a 64 bit value (long long on VC++ 2010). Not sure how standard that is as I don't deal with large files much.
Cheers,
Ash
PS:
Something like:
std::fstream fs( ... );
std::fstream::pos_type pt( fs.tellp() );
fpos_t fpt( pt.seekpos() );
EDIT: Looks like this is about as portable as a brick. According to the standard about all streampos has to do is support conversion to/from an int and be comparable with another streampos.
modified on Tuesday, June 22, 2010 12:23 PM
|
|
|
|