|
Executables are files though
|
|
|
|
|
and an ice cube is water. What's your point?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
That it's fine to read from cmd.exe, it's just unusual
|
|
|
|
|
I believe we are going to need more details about what you want to do...till now it sounds like you either want to read file data to the clipboard to paste it somewhere OR you need a filecopy method (like copy in a dos prompt).
> 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 want to create a program out of a program.
We all have a cmd.exe in our windows folder, how would i be able to create the cmd.exe out of my own program?
|
|
|
|
|
What would your program do?
> 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. <
|
|
|
|
|
Are you asking how to find executable code inside a program and copy it to another file, in order to run it?
If so, you have to learn the structure of the program.
|
|
|
|
|
ALLERSLIT wrote: Hey, i just wanted to ask if theres a way i can read the data of a file so i can paste it to another file?
Like i read the data of cmd.exe and paste it to whatever.exe?
back in the 1990's, all programs started at the same offset. This made chaining programs easy. In fact a tool called LzExe[^] would compress an executable code, replace the loader function, and chain to the offset starting block.
Now it is a little more difficult. Without knowing your intentions, few people here are likely to give you a step-by-step walk-through. The process is similar, but you will have to read the EXE header and still replace it, that much remains the same, chaining to the code is a little more difficult, but not impossible, but the act of which will cause any security product on the machine such as anti-virus software to halt your action.
If your intent is only to insert program code into a process there are other safer ways to do this without modifying an executable. Dlls offer the safest disk method of injecting code into programs. There are also active methods of inserting code into running processes.
So.... as others have asked, what exactly are you trying to do? modify an executable inserting your own code? for what reason? what are you trying to accomplish?
_________________________
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....
|
|
|
|
|
You already asked this question (although in a slightly different way) here[^]. Reading the contents of an executable file and writing it somewhere else is the same as reading and writing any file; files are composed of bytes and bytes are bytes are bytes. In either case your objective is not clear, try rewording your question to clarify what problem you are actually trying to solve.
It's time for a new signature.
|
|
|
|
|
Why array starts with zero?
Best wishes
Nikesh
|
|
|
|
|
Because it's natural.
-- the C developer
...Or [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Because 0 is the starting number
|
|
|
|
|
(probably not the best technical explanation, but...)
because the first element is at a zero "offset" from the start of the array.
Watched code never compiles.
|
|
|
|
|
Maximilien wrote: probably not the best technical explanation
But may well be the clearest 
It's time for a new signature.
|
|
|
|
|
Watched code never compiles.
|
|
|
|
|
it makes switching between (pointer + offset) and pointer[offset] simple.
if arrays started with 1, pointer[1] would be the same as pointer + 0, and C programs would be full of off-by-one errors as programmers forgot to account for the difference when switching between array notation and pointer + offset notation.
|
|
|
|
|
Can anyone point me to any open source application using exception handling? I have never used EH myself nor ever felt the need to use it. Just wondering what and when is the right use for it?
I want to see how other ppl use exception handling in their code and how does it make their program robust?
one good thing about EH is to quickly exit from deeply nested hierarchy. but how do experts use it?
How often do you use EH in your code?
|
|
|
|
|
For questions like this it's always worth checking Google and/or CodeProject articles[^].
It's time for a new signature.
|
|
|
|
|
One example is the standard library itself:
A stream ask a buffer to read.
If the buffer cannot complain, throws a runtime error that the stream catches, and set its own badbit, so that further reading are discarded in advance.
Believable or not, every software using C++ streams uses exception handling, at least just because of that.
----
Going more personal, wherever you're implementing something at low level that may -in certain RARE condition or in certain WRONG USAGE- not behave correctly, you can throw an exception.
The idea is to manage all those "rare events" not in the "return chain", but at "some point enough hight", typically not necessarily to have a plai n recover, but attempt a clean exit, at least at a level that allows a clean restart.
This works great especially when tighted to technics like RAII, and self-cleaning objects.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Sorry, most of the open source code I use comes from the Linux community and they're not great fans of C++. As a few guidelines:
You generally don't handle exceptions that often. Usually an exception means that something has gone horribly wrong and it's game over folks, let's just clean up and hope a restart gives a better result.
So generally you'd use an exception handler around main() for a console application and that's about it:
int main()
try
{
}
catch( std::exception &e )
{
std::cout << "Something went wrong: " << e.what() << std::endl;
}
catch( ... )
{
std::cout << "Something went wrong, no idea what!" << std::endl;
}
If you're writing a shared library or DLL with a C interface you'll want to catch exceptions before exiting a cdecl function. C (and other programming languages) don't know about C++ exceptions so it's a bit rude to through one at them.
The same goes for callbacks which go through any third party libraries (e.g. windows procedures in Windows). They may or may not have the same exception strategy and may not be able to handle them.
Cheers,
Ash
|
|
|
|
|
I tend to use assert a lot to check on things as its one way to keep code from crapping out.
http://www.contract-developer.tk
|
|
|
|
|
If you mean C style assert then I'd have to disagree with you and say it's just about useless, except for one edge case. The reason being is that C style assert is meant to be turned off when you build your final code, which can change your program's observable behaviour and I don't want the safety checks I think are important pulled out when I need them - i.e. when my code meets a user!
The edge case is using C style assert to as your tool to do Test Driven Development in a tools challenged environment. Having something that does a boolean test and informs the user if it's false is the minimum you need to do TDD and C style assert fits the bit adequately.
If you mean "assert" as in the general concept of checking preconditions, postconditions and class invariants then you've bought into Design By Contract and haven't got a lot of choice. In that case though you use assertions to generate an exception if the pre/postcondition is not true or the invariant is broken. I don't tend to use DBC that formally (it's a pain in the arse with C++ as the conditions end up embedded in every method and you have to manually check invariance) but the concepts are good. I've found that having a good set of unit tests from TDD is a good way of checking post conditions for example.
Cheers,
Ash
|
|
|
|
|
In general I don't approve of this use of catch (...). As with any rule of thumb there are exceptions but here's my policy on catch (...):
In general you should only catch what you expect could be thrown because catching an unknown exception could result in continued execution when the application is in an inconsistent state. Since catch (...) catches everything it should be avoid. One notable exception is the pattern shown below:
try
{
}
catch (...)
{
throw;
}
Also note that by not using catch (...) or using it only when re-throwing means that the call stack to the unexpected exception is available in the crash dump. Another pitfall is centred around the /EH[^] switch, or older MS compilers, but I won't go into that now.
Steve
|
|
|
|
|
Which of the three uses do you disagree with? The first use (catch(...) at the end of main) is only when every other remedial action has failed and the program's going to crash anyway. If you have other base exceptions or exceptions that aren't derived from std::exception feel free to add catches for them at the top level.
Another type is where something throws in a destructor. You can't let exceptions come out of a destructor, std::terminate will end up being called in most cases. So the program's going to crash - you might as well handle it and tell the user that something's gone wrong then bail out cleanly.
A final example is where you don't know where you're throwing. If you have a C interface there's no guarentee that something on the other side knows what to do with it. So catch the exception and translate it to an error code - even if the error code is "Buggered if I know what went wrong in here mate..." which should be translated by the caller into stick up an error message and bail out of the program.
One final point - you shouldn't need to manually clean up resources in the face of an exception. We're talking C++ here and not Java (and even then you've got finally, not catch( ... ) ). The general idiom with C++ is to handle cleanup of resources using RAII, don't do it manually 'cause you're bound to miss something.
Cheers,
Ash
|
|
|
|
|
On the issue of a catch (...) in main as follows (I also have objections on other grounds, but we'll address one issue at a time):
#include "stdafx.h"
#include <tchar.h>
#include <iostream>
#include <stdexcept>
using namespace std;
class MyException : public runtime_error
{
public:
MyException(const char *pMsg) : runtime_error(pMsg) {}
};
void SomeFunction()
{
throw MyException("SomeFunction()");
}
int _tmain(int argc, _TCHAR* argv[])
{
try
{
SomeFunction();
}
catch (...)
{
cerr << "Caught exception..." << endl;
}
return 0;
}
All the error information you get from the unexpected event is the following message:
Caught exception...
If the catch (...) is removed a crash dump is generated and the stack extracted from it (using WinDBG) looks as follows:
0:000> .ecxr
eax=00000000 ebx=0024f2d4 ecx=00000000 edx=0008dcd8 esi=770a030c edi=011915e3
eip=742dbb47 esp=0024f1e8 ebp=0024f214 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
msvcr90!terminate+0x33:
742dbb47 e879100100 call msvcr90!__SEH_epilog4 (742ecbc5)
0:000> kvn 1000
# ChildEBP RetAddr Args to Child
00 0024f214 0119161f 0024f2a4 77009d57 0024f2d4 msvcr90!terminate+0x33 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\hooks.cpp @ 130]
01 0024f21c 77009d57 0024f2d4 b21db5fb 00000000 Console!__CxxUnhandledExceptionFilter+0x3c (FPO: [Non-Fpo]) (CONV: stdcall) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\unhandld.cpp @ 72]
02 0024f2a4 77b10727 0024f2d4 77b10604 00000000 kernel32!UnhandledExceptionFilter+0x127 (FPO: [SEH])
03 0024f2ac 77b10604 00000000 0024f894 77acc3d0 ntdll!__RtlUserThreadStart+0x62 (FPO: [SEH])
04 0024f2c0 77b104a9 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
05 0024f2e8 77af87b9 fffffffe 0024f884 0024f424 ntdll!_except_handler4+0x8e (FPO: [4,5,4])
06 0024f30c 77af878b 0024f3d4 0024f884 0024f424 ntdll!ExecuteHandler2+0x26
07 0024f3bc 77ab010f 0024f3d4 0024f424 0024f3d4 ntdll!ExecuteHandler+0x24
08 0024f3bc 772bb727 0024f3d4 0024f424 0024f3d4 ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0024f424)
09 0024f75c 742ddbf9 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58 (FPO: [4,20,0])
0a 0024f794 0119106a 0024f7b4 01192460 b21db00a msvcr90!_CxxThrowException+0x48 (FPO: [Non-Fpo]) (CONV: stdcall) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 161]
0b 0024f804 011912ca 00000001 005920e8 00591e00 Console!SomeFunction+0x65 (CONV: cdecl) [c:\users\stephen.hewitt\documents\visual studio 2008\projects\scratch\console\console.cpp @ 19]
0c 0024f848 76fe3677 7efde000 0024f894 77ad9d72 Console!__tmainCRTStartup+0x10f (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 579]
0d 0024f854 77ad9d72 7efde000 72bf8284 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
0e 0024f894 77ad9d45 01191412 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [SEH])
0f 0024f8ac 00000000 01191412 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [2,2,0]))
This shows what went wrong and where. What's more, this information is sent to Microsoft and can be analysed by the software publisher using Microsoft's Windows Error Reporting[^] website. You get real crash data from real users as well as statistical information on the most common problems.
In short, a pretty message saying "oops" isn't as helpful — crashing is a feature.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
