In order to change the scrollbars displayed in applications, you have to understand how GUIs are rendered.
A GUI (graphical user interface) can be rendered in, essentially, one of two ways:
Native: The application asks the operating system to render a widget of a particular type. There are built-in widgets available in the Windows operating system; these widgets appear in built-in Microsoft applications, as well as many third-party programs that use the same toolkit.
Custom: Many applications use a custom widget toolkit or custom styling of the widgets, also known as "non-native". The way this is done is, the application requests a generic 2d canvas, which is basically an empty rectangle, and manually "paints" the pixels it wants into that space. Applications that do this are not calling into the Windows operating system to request its own native widgets; instead, they "paint" them using a toolkit, or application-specific code.
Examples of toolkits that directly or indirectly use native widgets include:
- Java SWT
- Most .NET applications that use Windows Forms, although custom Forms renderers are possible
- Applications that use ATL, MFC, or directly the Win32 API
Examples of custom toolkits include:
- GTK+ (certain engines; there exists a "native" engine that paints native Windows widgets)
- Java Swing (Java still does its own painting, but it uses graphical resources from the native widget appearance to emulate or approximate the look and feel of native widgets)
- Qt (certain engines; there exists a "native" engine that approximates native Windows widgets or uses them directly if possible)
- Juce (similar to Java Swing)
Now, when you say "Change Windows 7 default scrollbar", I think you are talking about changing how native scrollbars appear. Because it is difficult, or impossible, to force every application that ever uses a scrollbar to draw it in a specific way, because the application might have custom code that manually draws the scrollbar, and then you can't easily intercept the code it uses and change it.
In particular, if the application you're running uses a well-known custom toolkit, such as Java Swing, you may be able to force customization of the UI for specific toolkits; but you'll have to apply these changes on a "per-toolkit" basis; and you're still out of luck if the application uses hard-coded drawing on a canvas with no toolkit at all.
WindowBlinds, for example, uses a DLL "hook" to inject its own code into graphical applications on the system. The WindowBlinds code intercepts calls into the Windows API that request native widgets, and instead of drawing a default-styled widget, it draws one based on the theme data provided by a WindowBlinds theme. This DLL hook is essentially the only way to do it; there is no general-purpose registry fix or resource hack that can modify graphical elements of native applications. The built-in theming/styling features of Windows are not extremely flexible, hence the need for third-party applications such as WindowBlinds, which inject custom code into every application you run in order to perform the transformation from default scrollbars to custom ones.
Clever applications (or applications with certain security privileges) can prevent this DLL hooking, because it poses a potential security risk to the integrity of the information in the application: if an untrusted program can successfully hook a DLL in your program, it can do anything, essentially, including compromising feature limiting functionality of that application. So, certain applications, for security reasons, prohibit this modification.
The short answer is that you should just use WindowBlinds (come on, pony up the money!), but be aware that you will never be able to achieve 100% scrollbar replacement in all applications, due to the many different possible ways of doing rendering.