Can't find an answer to this for the life of me...
In the following line of code what does the ^ do?
RegistryKey^ rk;
I only ever see this in Windows code samples. How has Microsoft corrupted my binary operator?
This is from C++/CLI, which a C++/C# hybrid language, that runs on the same CLR that C# and VB do.
T^ is a managed pointer, pointing at objects allocated with gcnew.
T^% is a managed reference. I've never actually used these, and know nothing of them.
http://en.wikipedia.org/wiki/C%2B%2B/CLI
That's the C++/CLI (managed C++) handle declarator ("hat") symbol.
Source: http://msdn.microsoft.com/en-us/library/yk97tc08.aspx
Related
I have to deal with one ancient software module which only support its API being called from VC++6.0.
If I add an indirection layer, that is, wrapping the module in a dynamic library written with VC++6.0 and transferring API to the underlying module. The dll will be called from a VC++ tool chain provided in Visual Studio 2015.
My question is:
Is this doable in principle?
Are there any pitfalls one might want to may attention?
Can it be done in a better way?
Update: I guess that the C ABI is stable through different windows versions as well as corresponding supported VS version. If the dll is made with pure C, this might be done without too much trouble.
There are at least two issues preventing portability between versions/vendors: C++ object/class layout and the C/C++ memory allocators.
To avoid the first issue you should design the visible API as a set of C functions (like most of the Win32 API).
The memory issue can be solved by switching from new/malloc to one of the native Windows functions like LocalAlloc, HeapAlloc or CoTaskMemAlloc. Assuming your old .dll is not statically linked it would theoretically be possible to force newer code to use the malloc in msvcrt.dll but it makes your build setup a bit fragile and it goes against current best practices.
Another alternative is for the middleman .dll to implement everything as a COM object:
EXTERN_C HRESULT WINAPI CreateMyObject(IMyObject**ppv) ...
Windows 7 SP1
MSVS 2010
Qt libraries 4.8.4 for Windows (VS 2010)
Visual Studio Add-in 1.1.11 for Qt4
I, at first, couldn't figure out why this slot didn't fire:
connect (lineEdit, SIGNAL(textChanged(const QString &)),
this, SLOT(enableFindButton(const Qstring &)));
A diff made it clear: Qstring should be QString.
My question: Why did it compile? In fact, it will compile with this:
connect (lineEdit, SIGNAL(textChanged(const nonsense &)),
this, SLOT(enableFindButton(const more_nonsense &)));
Is this expected behavior? Why wouldn't this raise an error?
As far as I know and understand how works Qt, the connection lines works on runtime, not in compilation time. This means that all the operations needed to connect a signal and a slot are performed when the code flow reach that part.
Remember something important about Qt, some of the calls are only macros, not C++ functions. For example, the line "Q_OBJECT" you should add in your class declarations to enable the signals and slots mechanims works, is a macro. Also, the connect call is a macro (...), emit is a macro, etc. Those calls expand into real code once MOC (a pre-compiler, translates Qt macros into real code) analize your code.
Also, the signal/slot mechanism, I repeat, as far as I know, works on runtime, not compilation time. If you read the documentation of the connect macro, it says that the "SIGNAL" and "SLOT" macros you place there, convert the stuff you put there into a string, obviously, with some kind of format, that maybe is too complex to used by hand, so, since it is a string working there, the compilation can't check if the string is correct or not, that is checked on runtime.
I hope my bad english let you understand me, and I hope my knowledge is big enough to not being saying (too much) incorrect tinghs.
do you know where I can find Windows Low Level Assembly examples programs?
I have some exemples using macros (NASM, MASM) but I want pure assembly, in order I can build a shellcode later.
Thanks a lot guys!
This tutorial might be usefull for you: winamtut
Also this topic in MASM forum is great too.
If your architeture is x64 so try this link too.
And finally if you're interested in some theory, maybe this link could be nice.
Doing Windows GUI stuff in assembly language is a lot of work. This is why the examples you've found use macros - it takes away some of the pain.
If you really want pure assembly language, a great way is to ask your compiler. Write some C code to call CreateWindow or whatever, and then generate an assembly listing from the compiler (or step through it with a debugger).
If by "pure assembly" you mean "not done as a macro or library" then this is what you have to do:
download the masm32 package
check through the copius amount of samples, there will be many using CreateWindow or CreateWindowEx
start your own program
link in windows.h
use the invoke macro to call CreateWindow or CreateWindowEx
if you don't want to use invoke then just push the parameters onto the stack and call the functions directly - as this is what invoke does for you anyway
You can also get lots of help using the MASM package from the masm forum.
The best way to really (and quickly) learn win32 assembly is to decompile simple win32 programs. You could download lena's reversing tutorials from tutsforyou.com. Alternative you could tryout the reverse me's from osix.net - they have some pretty straight forward programs for you to reverse, and the best part is you get to see the masm32 sourcecode after completing the level.
tools: ollydbg, masm32 etc.
books: win32 assembler coding by Goppit, the arteam's PE compendium, intel developers handbook
hxxp://osix.net
hxxp://tuts4you.com/download.php?list.17
hxxp://www.intel.com/products/processor/manuals/
I'm not very pleased with your "in order I can build a shellcode later." - it's stuff like that which gives assembly a bad name.
I'd suggesty you take a look at FASM instead of MASM, though, since it's "closer to the metal", and directly supports binary output.
For learning to build shellcode I would suggest creating a very simple c program that does what you want the shellcode to do and than disassemble that using IDA or Immunity (or whatever debugger / dissasembler that you are familiar with). Than you can see what the instructions are that are being used.
I would also recommend the following books:
Hacking: The Art of Exploitation (2nd Edition)
The Shellcoder's Handbook
I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.
I've been doing some MSIL work and have come across references to these three debuggers.
What's the difference between them?
Is one of them better than the others wrt. functionality?
Are there others that I have missed?
I'm assuming you meant DbgClr not Clt and mdbg not mdbug?
DbgClr uses the VS shell so you get a nice GUI.
mdbg is the command line managed debugger.
cordbg was an old sample that sorta shipped, but now it's just a wrapper for mdbg. http://blogs.msdn.com/jmstall/archive/2005/11/07/views_on_cordbg_and_mdbg.aspx
Visual Studio is one you missed, but DbgClr should have the same functionality. http://blogs.msdn.com/andypennell/archive/2005/02/21/377621.aspx.
You can also use windbg with SOS extensions to do managed debugging from Windows debugger. SOS is also helpful when using VS since it lets you inspect memory and so on.
To see source level MSIL debugging, try using ilasm with the /debug option. Last time I checked, VS will let you step through the .il source just like C# or any other language.
MSDN blogs have a ton of content about debugging .NET apps -- I suggest you search further there.