vortesys/ntstyle

Vintage window borders for modern Windows.

NT Style for Windows

What is NT Style?

NT Style makes your computer look like it's straight out of 1993! Or atleast the titlebars and window borders. Stay tuned.

What does it run on?

Support and compatibility is provided for all versions of Windows NT with kernel version 5.2 and newer. There are currently only compiles for IA-32 and AMD64.

Where do I get it?

The releases page has the latest release of NT Style.

How can I help?

Submitting issues and reporting or commenting on bugs that you find is a massive help. The next level is to contribute and create a pull request.

What does it look like right now?

ntstyle's Issues

Broken link to releases in README.md

The links in README.md that should open up the releases and issues page return error 404.

Issue with windows under certain versions of Photoshop

In Photoshop CS2, both MDI child windows and the main window appear to be correctly themed, but on resize they will flicker with the windows 95 window theme, then flicker back to NTStyle's 3.1 theme - this will only occour if bottom right gripper is used to resize the window, and if you pull the gripper left or up (WTF?):

Correct styling:

When resizing using the gripper:

Code quality in srchook/ntsdlfn.c

Hello, I was looking through the code in srchook/ntsdlfn.c, which temporarily loads a few DWM API functions in during runtime, and have a few questions about the existing design. Notably, I believe that the existing code has a tiny resource leak in successful instances.

Current code is structured something like this for both function imports:

HMODULE hLib = LoadLibrary(L"Dwmapi.dll");
HRESULT hRet = 0;

if (hLib)
{
	FARPROC fLib = GetProcAddress(hLib, <FUNCTION>);
	if (hRet = (HRESULT)fLib(<ARGUMENTS>))
	{
		FreeLibrary(hLib);
		return hRet;
	}
}

return 0;

I believe that the FreeLibrary call should be ran in both cases. Otherwise, what would happen here is that the library is loaded by the application and never freed. Note that S_OK (a successful HRESULT) is equal to 0, so the if condition is passed and the function always returns successful if hRet is 0, without freeing the library. In general, the macros SUCCEEDED() or FAILED() should be used for HRESULTs, for clarity.

If this is the intended behaviour, then it'd be good to add a comment documenting this. Otherwise, appropriate adjustments should be made.

Proposal to fix UIRibbon extraneous titlebar margin

Background

This isn't particularly a priority issue, but it's a small bug with some default Windows programs that can be corrected.

In UIRibbon applications, there is a visual error that can be seen on NTStyle (from the README.md document):

Explanation

This bug occurs due to UIRibbon expecting extended frames under DWM. Because NTStyle forcefully disables DWM on the application, extended frames don't work correctly and the extra allocated space is clearly seen in the client area for the window. This bug also occurs on Windows 8+ versions of UIRibbon, regardless of whether or not DWM is running. It is also observed with official implements of client-side decorations, such as Win32k (classic theme) and UxTheme (XP/Aero Basic theme engine).

To recap, here are the following cases this may occur:

• Under Windows Vista or 7 (or its respective UIRibbon version) when DWM composition is enabled system-wide, the application is not lied to about the DWM composition state via dwmapi hooking, and the window is forced to not use DWM system frames via DwmSetWindowAttribute.
• Under Windows 8+ when the window is forced to not use DWM system frames via DwmSetWindowAttribute.

Proposal

Since you can detect the presence of UIRibbon in an application easily (via current application image name, loaded module image names, child window class name searching, or even a combination of all three), and because the extraneous space is highly predictable (it's the same size as DWM titlebars), a hack can be used for UIRibbon applications to crop this space from the window via custom handlers for window messages like WM_NCCALCSIZE, WM_NCHITTEST, and WM_NCPAINT.

The following information may useful for implementing a system to detect the presence of UIRibbon in a program or window:

• EnumProcessModules from psapi.h can be used to search for UIRibbon.dll in all supported operating systems (Windows NT 4.0+, not supported in 9x).
• UIRibbon creates several windows with the class name UIRibbonCommandBarDock for its UI.
• The following default Windows programs use UIRibbon by default since Windows 7:
  • Paint %SystemRoot%\System32\mspaint.exe (+ x86 copy in SysWOW64)
  • Windows Wordpad Application %ProgramFiles%\Windows NT\Accessories\wordpad.exe (+ x86 copy)
  • Windows Explorer %SystemRoot%\explorer.exe (since Windows 8, only for some windows)

This may not seem a desirable solution (it is really hacky, after all), but it's the easiest solution that I can think of for this case. Another solution is to hook UIRibbon, but this is:

1. The hardest thing in the world. I have not figured out how to do this myself.
2. Requires downloading debugging symbols from Microsoft, which may not be available in some areas of the world.

Problem opening the executable after compilation.

When I try to open the executable (ntstyle.exe), the process appears in the task manager for a second, then disappears.
I used Visual Studio Build Tool 2022 for the compilation; the compilation did not encounter any errors, but there may be a parameter that I forget to enter.

Add screenshots to README.md

Please add screenshots off NTStyle running on multiple Windows versions to README.md.