Trials and tribulations

All development related issues welcome

Moderator: Moderator Team

Post Reply
Posts: 2
Joined: Sun Nov 15, 2020 2:00 pm

Trials and tribulations

Post by Trilabs »

This is more of a learning post to anyone wishing to develop software for ReactOS, rather than a "question" in itself. We are all aware that ReactOS is Alpha software and that certain things you might expect to work, just simply doesn't yet. NOTE: This post will be long, and please excuse me for my digressions.

Please be warned that this is currently just a personal project of mine to learn more about the win32 C++ API. I have no idea when and if the project will be released. It currently runs as a standalone program, and has not been integrated in any way to the current menuband / startmenu (using HPOPUP) code base.

I've been working on a rough implementation of a "modern" start menu (with some modifications in mind). The program is currently being written in Visual Studio 2019 and is compiling with the XP (Visual Studio 2017 v141_xp) compiler. It is in very early development with ownerdrawn transparent buttons, and currently a listview for the right side buttons (although this will have to change to a custom function to manually draw these items, as you will see later in the post).


Shell32.dll : ReactOS uses an iconset in this file that differs from Windows. The first icons (30 or so?) seem to be located at a similar position, but after that you're on your own. Examples are plenty, but if you browse through you'll quickly see that representative icons are moved. A few examples: "My Pictures" icon being found at position 127 in Windows, while it is located in position 123 in ReactOS. "My Recent Documents" icon being found at position 213 in Windows, while it is located in position 208 in ReactOS. "Printers and faxes" icon is located in position 58 in WIndows, while it is found in position "37" in ReactOS. The list goes on.

While Windows has stayed fairly consistent with their icon libraries, there are some examples of changes here as well. I found it particularly interesting that the icon for "Set Program Access and Defaults" (Which I simply call "Program Defaults"), is found in imageres.dll for NT versions newer than 6, while it was earlier located in moricons.dll. ReactOS, on the other hand, has no "real" image (or application) for this, nor any of these iconsets. The current settings can be found in "Folder Options" in the Control Panel, and the icon for this application is found in ReactOS shell32.dll at position 106.

Anyhow, I digress. My current "temporary" solution is a quick "check" if the installed OS directory includes 'ReactOS' and alter the icons on runtime depending on this, but a user 'may' have installed in a different directory. To avoid 'checking' registry keys that may change, I believe the best way to currently solve this in the program itself is a simple #define identifier in the code, which will determine if BOOL variable "IsitReactOS" is TRUE or FALSE.
This will have to be set at compile time, but avoids constant checking via functions to show the 'correct' icons.


Tile view

Making a rookie mistake, I initially opted for a list view setting with a "tile view" to represent the "pinned" programs / "recent" programs bar on the left, as Windows XP and newer NT versions do provide this function to allow for a very similar "visual" experience as you would see in the XP start menu via common controls or newer. After passing several hurdles to actually make this tile view available, I got the view correctly working with subtext. Only then did I realize that ReactOS has no implementation of Tile view as of yet. It simply ignores it and presents the listview in whatever standard was set before enabling it.

(A bit of info: Why Microsoft made it so that a manifest requesting common controls newer than version 6 to be "not" enough is beyond me, but after many hours of searching, I realized they, for some reason, enforce a #pragma comment ('linker') comment to enable this function, which in-turn messes up all owner-drawn buttons with positive BOOL checks, despite being set to FALSE. Such BOOLEAN checks are often used in ownerdrawn buttons to see if the cursor is hovering over a button, but adding this pragma comment made all buttons light up upon initialization, and stay on until the mouse hovered over the affected window. The current solution to this was to force BOOL statements to false 45 times, until the program settled, before drawing the buttons. This code is now set for removal, for reasons coming later.).

While I may, at some point, feel confident enough to look further into the source code of ReactOS, and see how tile view can be implemented, the current course of action is to make a simple custom draw function to manually create the 'buttons' for this view. All buttons up until this point has been initalized with 'static' draw functions depending on what button it is, so this may prove to make the codebase smaller as well, (if I can reuse it to create the existing buttons).


Ownerdraw on ReactOS

When starting this project, I wanted to mimic the style of the "modern" start menu as closely as possible. This meant selecting buttons 'on hover', which is quite possible when ownerdrawing a window. However, coming this far into development, it's become clear it is not a viable option in ReactOS for the time being. The way ReactOS ownerdraws a window seems very cumbersome compared to XP. The current implementation of this program doesn't do much (loads icons, writes text, fillrect when on hover), but it is still too much for the current implementation.

Example and comparison shown here:

In my personal opinion, the best option (not including rewriting the ownerdraw code, which is way beyond my current knowledge of C) is to limit the redraws by removing this 'onhover feature'. It is stricly not important, and will in turn not only make the code 'leaner', but also limit redraws to 'on button presses'.

4. Resized start menu/HPOPUP 'all programs' submenu or "Longhorn-inspired"

Now we are entering an area of the code I have yet to implement, but it is in regards to how the "Start Menu" shows the "pinned programs", and also the "all programs" shortcuts/folder(s). I find the constant expanding of the "modern" start menu in XP to be quite outdated. There is no reason why the menu should increase to the entire screen resolution size to allow for 'pinned items' or 'additional' recent programs. Nor does a massive HPOPUP to display 'all programs' seem very elegant.

Newer versions (Including some Longhorn pre-reset betas) not only enables 'scrolling' in the 'recent programs/pinned programs' pane, but also uses the same area to scroll through both the recent/pinned programs, and the 'all programs', just switching out the elements in the pane itself. I personally found this a much neater solution than the HPOPUP and 'Start menu resize' of days gone. I am contemplating this approach, as it would keep the start menu window-size static, and avoid the (sometimes, depending on the user) "massive" start menus and HPOPUP's of the "classic" Windows days.

Also, looking at XP, the way it stores "pinned programs" for users is horribly convoluted. Instead of having a folder inside the users appdata, it stores this in an 'encrypted' binary registry. IE Windows Server 2003 stores these shortcuts in location %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu. I believe the best course of action would be to mimic Server 2003 for this. I see no reason to 'hide' these items from user control, and no benefits from the constant writes/reads from registry.


These are just some notes on my thoughts and experiences as I continue my development. Despite the obstacles so far, starting on this project has been quite a learning experience. Hopefully this post will help others to avoid some of the glaring mistakes I've made, and hopefully take note of the differences I've observed so far. :)

User avatar
Posts: 1056
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany

Re: Trials and tribulations

Post by gonzoMD »

Hello and welcome.
Glad to read about your interest in ReactOS in general and the shell in special.
For the first questions I have to ask you with which version of windows did you compare? I am one of the guys who almost completed the missing icons in shell32 and the version I took as template was 2k3. They should be exactly at the same position as there (as long as they weren't moved by someone for some reason). If there are differences please document them and I'll take a look.

Tile view: yeah, it's currently unimplemented. I think it should be added to comctl32.dll. This file is winesynched but I am not sure if they are about to implement this missing part because it is not so important for them.

Thanks for your questions. I think that there are more skilled guys who can help you. I suggest that you should join our mattermost chat at

This Jira issue could also be interesting for you:
It is related to the missing modern start menu.

And please tell me more about the icon related things because they could be important for me in the future.


Posts: 2
Joined: Sun Nov 15, 2020 2:00 pm

Re: Trials and tribulations

Post by Trilabs »

Hey, and thank you for the response!

The icon comparison was done with ReactOS Release 0.4.13 (20200409-0.4.13- . A bit old, but while I have the github, I haven't really had the time to sit down and run compilation of nightlies), Windows XP Professional Version 5.1 (Build 2600.xpsp_sp3_qfe_150205-1510 : Service Pack 3), and Windows 10 Professional Version 2004 (Build 19041.630).

I haven't looked if Server 2003 or 7 provides different iconsets at this time, but assuming anything changed during XP -> 10 in the core shell32.dll library, one would assume it would be reflected in Windows 10. In both versions the default icon locations for the 'core' Windows applications remain the same (with the exception of "Set Program Access and Defaults", which as far as I remember came along during XP's service packs? Thus ended, as mentioned earlier, in moricons.dll, and later in imageres.dll).

Tile view is certainly related to of comctl32.dll (common controls), and provides the "tiled" icon view you see in the Windows XP File Explorer (and later builds of Windows). It "requires" this, just like uxtheme does. Its implementation seems kind of 'hacky' from Microsoft's side in XP (mostly due to the 'classic' XP mode relying on an earlier version of comctl32.dll), but it is there. I can only assume this is one of the reasons "classic mode" was removed from later Windows releases, so developers could focus only on the modern version of (amongst others) this file. I do know if you do try to use a program with tiled view in earlier Windows versions (or without the required pragma comment to include the new version), it will simply show the "large icon" view instead, but that's not really a viable option for this project. It's a setback for making the 'non static' buttons in the "modern start menu", but not a hindrance. A custom draw function will provide the same 'look', even if the implementation behind it would be different.
Last edited by Trilabs on Mon Nov 16, 2020 12:28 am, edited 1 time in total.

Posts: 522
Joined: Thu Jan 10, 2013 6:17 pm

Re: Trials and tribulations

Post by karlexceed »

Trilabs wrote:
Mon Nov 16, 2020 12:26 am
I haven't really had the time to sit down and run compilation of nightlies
No problem:

Posts: 2
Joined: Sun Nov 15, 2020 2:00 pm

Re: Trials and tribulations

Post by Trilabs »

Thank you for the link! I did a quick download and test of 0.4.15, and the iconset remains the same in this build as 0.4.13.
For now, the checks must therefore stay, either by define or some other measure to determine OS to ensure the correct iconset is displayed.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest