Jump to content
Tuts 4 You

Kibloy's Blog

  • entries
    7
  • comments
    19
  • views
    50,165

About this blog

Rants and raves

Entries in this blog

 

XM on x64

This is the result of trying to play back xm music on 64-bit Windows. I wrote a simple wrapper around libmodplug that reads its raw PCM output and writes it to the standard wave output. All you have to do is create an instance of ModPlay which needs a buffer + size of the xm file to be played. Then just call the play() function and voila I have to say that it roughly adds 40kb of code to your binaries, you have to decide if that is worth it for you. Personally I don't care, especially because you can compress the **** out of it with UPX Attached are the wrapper C++ files, WINMM import libraries from the Windows SDK and 2 static libraries of libmodplug (compiled with VS 2008, you might need to build libmodplug yourself for other compilers/configs, see below for tips) Any problems, questions, suggestions, let me know. PS: If you want/need to compile libmodplug, just make sure you define these to keep the library size as small as possible: MODPLUG_BASIC_SUPPORT MODPLUG_FASTSOUNDLIB MODPLUG_NO_FILESAVE NO_PACKING For VC++ I added this version of stdint.h, added the libmodplug subfolder to the include dirs and it pretty much compiled out of the box.

Killboy

Killboy

 

GetRelocSize

Some packers leave a dll's relocation directory intact (e.g. Armadildo). You just have to know the original reloc dir RVA which is easy to find in most cases. However, you need to define the right reloc table size, since the PE loader subtracts every block from the size and checks for 0. That means, you can't just guess and make it big enough to contain all elements. It has to be the exact size of the table. Well, I was looking for a tool that could calculate the size but couldn't find any. I started coding my own and that's the result It takes a PE file, displays the correct size for the reloc table and optionally writes the right size to the file. Supports both normal and PE32+ executables. BEWARE! KOMMANDLINE-APPLIKASHUN! Source and binary attached

Killboy

Killboy

 

Endless fun with tab controls

Anyone who ever tried to implement tab controls using plain Windows API will probably agree with me that it's a ****ing PITA to get it working properly. Some of the problems you'll most likely be facing, mostly because of poor documentation: Handling and adjusting the windows for each tab
Getting Windows to draw the themed background on the windows
Adding transparent (32-bit) icons to tabs
After a lot of googling and guessing around, I got most of this stuff working. I came up with a bunch of functions to help with getting tab controls work without having to deal with all the hassle. The functions should be used exclusively, that is without modifying tab items yourself as the functions assume certain conditions and might cause undefined behaviour if things aren't as expected. Some of the things you shouldn't do: - Add a tab without using the appropiate function - Remove a tab without using the appropiate function - Change the tab items' lParam value (they hold the window handles) - Change the tab's ImageList - Call SetProp on the tab window with "TabCtrlCurWnd" ;D You can still modify the tab control's GWLP_USERDATA. A quick overview over the functions: int AddTab(HWND TabWindow, HWND Window, char * Caption, int Index) Adds a tab item to the tab control and associates the window to it. The window is moved and resized to fit the tab control dimensions. bool RemoveTab(HWND TabWindow, int Index) Removes the tab item from the tab control. bool TabCleanup(HWND TabWindow) Removes all tab items from the tab control. Cleans up internal resources and hides all windows associated with it. It's recommended to call this function before the tab control is destroyed, e.g. if you get a WM_CLOSE message in your dialogbox proc. bool SetTabIcon(HWND TabWindow, int Index, HICON Icon) Sets the tab item's icon. Supports 32bit icons (24bit + 8bit alpha) if comctl32.dll v6 is used (ie. visual styles enabled). The icon should be 16x16 in size and at least contain an 8bit (256 colors) channel. int TabToFront(HWND TabWindow, int Index) Selects the specified tab and shows the appropiate window. For a more detailed overview over the functions take a look at tabs.h In order for the tab selection to work, you will have to add this piece of code to the tab control's parent window handler (usually the dialog procedure): case WM_NOTIFY:
switch(((NMHDR *)lParam)->code)
{
case TCN_SELCHANGE: // Get currently selected tab window to front
TabToFront(TabWindow, -1);
break;
default:
return false;
}
break; Alright, that should be it Attached are the .h and .cpp and an example project.

Killboy

Killboy

 

Notorious H.I.T.

Old, but still worth posting for those who don't know it, I reckon
/>http://www.youtube.com/watch?v=wcrqGdFfHQk&hl=en&fs=1

Killboy

Killboy

 

Cryptocrack Unpacker [ap0x SDK]

This is an unpacker for Cryptocrack's PE Protector 0.93 I've done with ap0x's Unpack SDK some time ago. It was supposed to be included with the new version as a VC++ example. He doesnt seem to come round to release the new version anytime soon (that dude is busy ) so I thought I might as well upload it here. It contains include files and libs to use the dlls with VC++ without having to link excplicitly (ie. GetProcAddress). Keep in mind that you cant use the updater module since the dlls cant be replaced at runtime... There might be some other stuff in there some of you might find interesting, the approach of getting imports and a stripped down PE-realigning function for dumps... Put it to good use :">

Killboy

Killboy

 

Docking Windows To Screen Edges

This is a rather simple but effective way to keep a window from being dragged out of the screen area. Add this piece of code to your window/dialog procedure: case WM_MOVING:
long scrx, scry;
RECT * rect;
rect = (RECT *)lParam;
scrx = GetSystemMetrics(SM_CXSCREEN);
scry = GetSystemMetrics(SM_CYSCREEN);
if(rect->right > scrx)
OffsetRect(rect, scrx - rect->right, 0);
if(rect->bottom > scry)
OffsetRect(rect, 0, scry - rect->bottom);
if(rect->left < 0)
OffsetRect(rect, -rect->left, 0);
if(rect->top < 0)
OffsetRect(rect, 0, -rect->top);
return true; Just thought it might be useful to someone...

Killboy

Killboy

 

Bool Isappthemedthistime4real(void);

Maybe you've been trying to find out whether an application (yours, that is) is using visual styles or not before. While you normally know if it does or not (you added the manifest, didn't you), when writing example code or libraries for GUI stuff, it sometimes turns out to be useful to know. I ran across such a case when I dealt with tab controls. Without visual styles tab sheets have the same background as normal dialogs whereas with visual styles enabled, the bg is white... Have you seen the gradient on tabs used by Windows settings dialogs or .NET apps ? There's a function called EnableThemeDialogTexture that applies that background to a window. However, if you call that function on an OS supporting visual styles in an app that does not have them enabled, it will still apply the white background. Which, as you can imagine, looks kinda gay.. Now, there is another function exported by uxtheme.dll called IsAppThemed which is actually supposed to do what it says. Funny thing is, it always returns true on XP, on Vista they seem to have fixed it though. So, it seems like we have to do that ourselves As you might know, you have to enable visual styles with a manifest. What the manifest actually does, is linking to a certain version of comctl32.dll. This is achieved through the so called SxS (Side by Side) directory which keeps all sorts of versions of the same dll. The manifest works like some sort of import table, you tell it the name and the version(!) of the dll to load. The trick with visual styles is that the comctl32.dll located in system32 has version 5.x which doesn't apply any visual styles. This is the one that gets loaded when you import it via the import table. If you add the manifest, it will require version 6 of comctl32.dll which enables visual styles. So, this is how we're going to check for visual styles: load comctl32.dll, call DllGetVersion and check if the major version number is above 5. If it is, the program is using visual styles, otherwise it isn't. If comctl32 does not export DllGetVersion we're on an OS below 2000, in that case we'll just return false because it doesn't support visual styles at all. Otherwise, we'll check if dwMajorVersion of the DLLVERSIONINFO struct is 6 or above, if it is, visual styles are enabled. As easy as that Anyway, for the lazy ones, here's a way to implement it: bool VisualStylesEnabled(){
HMODULE hMod;
DLLGETVERSIONPROC pDllGetVersion;
DLLVERSIONINFO DllVersion;

hMod = GetModuleHandle("comctl32.dll");
if(hMod){
pDllGetVersion = (DLLGETVERSIONPROC)GetProcAddress(hMod, "DllGetVersion");
if(pDllGetVersion){
DllVersion.cbSize = sizeof(DLLVERSIONINFO);
if(pDllGetVersion(&DllVersion) == S_OK){
return (DllVersion.dwMajorVersion >= 6);
}
}
}
return false;
} Be sure to add: #include <shlwapi.h> to the beginning of your source code, this is needed for the definition of DLLGETVERSIONPROC and DLLVERSIONINFO. Hope this helped removing some confusion on that topic, sorry if it went the other way around Win32 is a bitch, if you don't like it, switch to Java or .NET or use Linux But isn't the weird stuff what makes it so unique and adorable

Killboy

Killboy

×