Interaction Design and Visual Conventions of Desktop Software (1998–2006)

Full report

On this page

Executive Summary

The period between 1998 and 2006 represents a foundational epoch in graphical user interface (GUI) design for desktop computing. This temporal window spans the maturation of the rigid, utilitarian Win32 environment found in Windows 98 and Windows 2000, through the radical aesthetic reimagining introduced by Windows XP, and culminating in the robust, heavily skinnable prosumer application culture that preceded the mobile-first era. For a browser-based historical archive workstation seeking strict period credibility, superficial mimicry of retro aesthetics is insufficient. Authentic replication requires a nuanced understanding of the era’s rendering constraints, typographic strictures, event-driven interactions, and the inherent structural inconsistencies of a fragmented software ecosystem. During this era, operating systems evolved from functional, gray workspaces aimed at enterprise productivity into colorful, consumer-oriented environments. However, third-party software development lagged behind operating system updates. The resulting desktop experience was a chimera: a single machine might simultaneously run a heavily gradient-styled native application, a legacy utility utilizing 16-color jagged icons, and a highly proprietary, dark-themed media player. The primary objective of this report is to translate these disparate historical interface paradigms—encompassing visual, interactive, and architectural conventions—into detailed, actionable recommendations for engineering a historically accurate, yet accessible, web-based workstation.

Timeline of Important Desktop-UX Changes (1998–2006)

The evolution of desktop software design during this period was defined by iterative advancements in rendering capabilities, hardware adoption (the transition from CRT to LCD monitors), and evolving human-computer interaction philosophies.

Visual Conventions

The visual language of the 1998–2006 desktop was defined largely by the limitations and characteristics of the physical hardware of the time, primarily low-resolution CRT monitors, combined with the transition from 256-color standard VGA to 32-bit true color graphics. The early part of this era, dominated by Windows 98 and Windows 2000, relied heavily on the "chiseled" aesthetic. User interface elements were defined by precise one-pixel highlight and shadow borders to simulate three-dimensional depth against a universally standardized neutral gray background (RGB 212, 208, 200, known programmatically as COLOR\_BTNFACE). Buttons, scrollbars, group boxes, and window borders shared these uniform lighting assumptions, mathematically simulating a light source originating from the top-left corner of the screen. With the release of Windows XP in 2001, the visual paradigm shifted dramatically toward "Luna," an interface characterized by bright, energetic color schemes, soft curves, and rich linear gradients5. The default Blue theme was intended to appear fresh and inviting to consumer audiences, replacing rigid bevels with rounded title bars and distinctly colored window controls. Most notably, the prominent red "Close" button was engineered specifically to improve discoverability for novice users5. Alternative official color schemes, such as Olive Green and Silver, allowed users to personalize the environment, though they maintained the same underlying geometric structure5. Despite the operating system-level visual shift, individual applications were not automatically updated. Many legacy programs, or programs written utilizing older third-party component libraries, retained the standard Windows Classic control rendering. This created a pervasive visual juxtaposition: heavily textured, colorful, gradient-filled outer window borders encapsulating flat, gray, bevel-driven application interiors. Furthermore, the 32-bit rendering engine in Windows XP, which supported true alpha-channel transparency, allowed for anti-aliased drop shadows beneath top-level windows and the mouse cursor, a subtle but critical indicator of the era's advanced visual depth compared to the flat planes of Windows 98\. Layouts during this era were inherently fixed-pixel. The concept of fluid or responsive design did not exist in desktop applications. Resizing a window typically resulted in expansive areas of empty gray space or the revelation of a static background color, as child controls remained stubbornly anchored to the top-left corner unless specific, often complex, resize event handlers were manually programmed by the developer.

Interaction Conventions

Interaction design during this period was characterized by distinct boundaries between modal and non-modal states, rigid keyboard focus management, and heavy reliance on the physical keyboard functioning in tandem with the mouse. The focus rectangle—a dotted one-pixel line drawn just inside the border of a control—was the primary, and often only, indicator of keyboard position3. Focus management was highly explicit; clicking anywhere within a window brought it instantly to the front of the Z-order, and the active element immediately received the dotted focus ring. State changes were binary and instantaneous. Hover states in the pre-XP era were relatively rare for standard form controls; standard push buttons did not glow or change color when hovered, they only depressed visually when clicked. Windows XP introduced subtle hover interactions, such as a slight brightening of the red close button or the appearance of an underline on desktop icons when the system was configured for web-style single-click execution. However, these state changes occurred in exactly zero milliseconds. The modern convention of applying a 200-millisecond CSS transition ease to hover states is a primary reason contemporary recreations feel inauthentic. Drag-and-drop mechanics were highly functional but visually crude compared to modern composited window managers. Dragging an object usually resulted in a translucent static ghost of the icon, or merely a black dashed outline, which snapped to a rigid grid upon release. The context menu, accessed via the right mouse button or the Shift+F10 keyboard shortcut, became a universally standardized interaction model3. The invocation of these menus, however, was strictly synchronous; the application thread would often block until the menu was dismissed, a behavior that defined the structural "feel" of desktop software of the era. Selection models varied distinctly by control type. In standard list boxes and report-view list views, single clicks selected items, while double clicks executed the default action. A critical interaction cue was the active selection state, denoted by a dark blue background (RGB 10, 36, 106 in classic mode, or the Luna equivalent) with inverted white text. Inactive selections—occurring when the window lost focus—turned to a light gray background with black text. Modern web applications frequently omit this inactive selection state, immediately breaking the historical illusion.

Typography

Typographic rendering underwent a fundamental revolution during this eight-year span. In 1998, typography was predominantly aliased, relying heavily on bitmap fonts or un-smoothed vector fonts constrained strictly to pixel grids. MS Sans Serif (a raster font) was the hallmark of the Windows 9x era, typically rendered at 8 points. It provided crisp, distinct legibility on low-resolution, blurry CRT monitors but lacked any capacity for clean mathematical scaling. Windows 2000 and XP systematically replaced MS Sans Serif with Tahoma as the default system font, typically utilized at 8, 9, or 11 point sizes5. Tahoma was engineered specifically for on-screen legibility and was paired with the introduction of ClearType, a sub-pixel anti-aliasing technology optimized for the newly emerging LCD monitors. ClearType utilized the physical red, green, and blue sub-pixels of an LCD screen to smooth the edges of text, providing a slightly softer, highly readable appearance that defined the XP era. The typographic hierarchy in official design guidelines expanded significantly during the early 2000s. Franklin Gothic was designated for large headers (over 14 points) but was strictly prohibited for body text5. Trebuchet MS Bold at 10 points became the standard for window title bars, providing a friendly, slightly geometric contrast to the interface text, while Verdana Bold at 8 points was specified for the title bars of tear-off and floating palettes5. Typographic layout was incredibly dense by contemporary standards. Line heights (leading) were tight, often set at a mere 1.1 or 1.2 times the font size. This allowed for maximum information density within the fixed-pixel constraints of common dialog boxes. Text was rarely allowed to wrap fluidly; rather, it was hard-coded to fit specific static dimensions.

Icon Style

Iconography progressed rapidly from 16-color and 256-color constrained palettes to 32-bit graphics with full alpha-channel transparency. Early era icons were characterized by distinct, hard black outlines, flat color fills, and a strict isometric perspective. Due to the lack of true transparency in the drawing APIs, the edges of these icons were often jagged, relying on a single designated transparent color (commonly pure magenta, \#FF00FF) to mask the background when blitted to the screen. The XP era introduced a vastly different illustrative style under the Luna guidelines. Icons utilized rich colors, soft curves, subtle gradients, and high-quality anti-aliased drop shadows5. They abandoned the hard black outlines in favor of varied line weights and contextual coloring. Standard sizes were strictly adhered to across the operating system: 16x16 pixels for title bars, list views, and status bars; 32x32 pixels for the desktop and standard large icon views; and a newly introduced 48x48 pixel size designed specifically for the Explorer details pane and Wizard97 setup screens. Despite this OS-level evolution, the juxtaposition of old and new was omnipresent. Navigating deep into an XP system's administrative tools, or installing third-party shareware, would frequently uncover 16-color icons left unchanged since Windows 95\. A credible archival workstation must simulate this exact inconsistency, utilizing polished 32-bit icons for top-level system functions while deliberately deploying older, magenta-keyed icons for simulated legacy applications.

Menu Behavior

Menu bars were the primary navigation and command apparatus for nearly all productivity software. A standard application menu adhered to a strict, predictable taxonomy: File, Edit, View, Insert, Format, Tools, Window, Help. Menus featured a flat, three-dimensional gray background with a distinct relief border when invoked. A defining feature of the era's menu behavior was the keyboard mnemonic, visually indicated by an underlined letter within the command name (e.g., \&File, \&Save). Prior to Windows 2000, these underlines were always visible. However, Windows 2000 introduced a behavior where mnemonic underlines were hidden by default to reduce visual noise and intimidation for novice users3. They appeared only when the user depressed the Alt key3. This specific behavior was retained through Windows XP and became a hallmark of the Win32 ecosystem. Furthermore, menu rendering was instantaneous and completely opaque. Transition animations, such as the subtle fade-in or slide-down effects common in later operating systems, were either non-existent or frequently disabled by power users for maximum performance. Checkmarks alongside active menu items were small, pixel-perfect bitmap indicators rather than vector glyphs, and cascading sub-menus opened with a slight, deliberate delay (typically 400ms) to prevent accidental triggering when dragging the mouse diagonally across the menu plane.

Toolbar Behavior

Toolbars evolved significantly during this era, transitioning from flat, static arrays of buttons into complex, customizable rebar controls, officially known as CommandBars. The introduction of the "gripper"—a vertical line of raised pixels or a dotted texture on the left edge of a toolbar—provided a physical affordance allowing users to drag, undock, and reposition toolbars across the application window7. Toolbar buttons typically lacked visible borders when in an inactive state, relying solely on the 16x16 or 24x24 pixel icon to indicate function. Upon hovering, a distinct 3D border would suddenly appear around the icon, accompanied by a delayed tooltip explaining the function. Text labels were optional and highly configurable, often presented below the icon or placed selectively to the right of high-priority buttons to save horizontal space. When toolbars were constrained by window width, a chevron (\>\>) appeared at the far right edge; clicking this chevron produced a standard dropdown menu containing the truncated commands.

Dialog Conventions

Dialog boxes were the fundamental containers for configuration and interaction, operating as strictly modal windows that prevented interaction with the parent application until resolved or dismissed. Official User Experience guidelines dictated strict anatomical structures for these windows to ensure consistency across the ecosystem. The standard button cluster consisted of OK, Cancel, Apply, and Help. OK and Cancel were typically positioned at the bottom right corner, with Apply utilized exclusively in property sheets to enact changes without closing the window. The inclusion of a Help button in a dialog box implied a specific, highly regulated design constraint: if Help was present alongside OK and Cancel, the dialog was generally expected to omit the standard red "Close" (X) button in the title bar15. This forced the user to make a deliberate choice via the standard command buttons rather than dismissing the window arbitrarily. Keyboard accessibility required that access keys (mnemonics) must never be assigned to the OK, Cancel, or Apply buttons, as they would conflict with standard Return and Escape key bindings13. Spacing between these buttons was typically standardized at 6 pixels. Tabbed property sheets were pervasive, acting as a solution for layering multiple panes of complex settings into a single small window designed for 800x600 resolution constraints. These tabs were visually represented to mimic physical file folders. If the number of tabs exceeded the width of the dialog, multi-row tabs were employed. This created a notoriously confusing interaction paradigm: clicking a background tab would cause the entire row structure to dynamically rearrange itself, changing the physical location of all other tabs on the screen so that the active tab remained physically connected to the content pane.

Application-Specific Conventions

To achieve a historically credible archival workstation, replicating standard OS controls must be balanced against the highly specific, often idiosyncratic conventions of archetypal third-party and native applications.

Internet Explorer 5/6

The dominant browser of the era utilized heavy branding and deep system integration. The interface featured a prominent spinning logo (the "throbber") in the top right corner during page loads. By 2004, with the release of Windows XP SP2, the browser introduced the InfoBar—a pale yellow strip that appeared beneath the toolbars to notify users of blocked pop-ups or ActiveX installations without using an intrusive modal dialog. This non-modal alert pattern became highly influential in subsequent software design.

Windows Explorer

Explorer in Windows XP introduced the "Task Pane," a thick, accordion-style blue panel on the left side of the window replacing the traditional folder tree16. This pane contained collapsible groups (e.g., "File and Folder Tasks," "Other Places") utilizing white text on gradient blue headers, with distinct hover underlines on the task items16. The list view on the right featured column headers in "Report View" that provided a flat, non-beveled appearance in Luna, with a small gray triangle indicating sort direction17.

WinZip-Era Utilities

Utility software often straddled the line between power-user density and consumer accessibility. WinZip championed a dual-interface paradigm, offering a "Classic Mode" characterized by a dense toolbar and a massive data grid view of archive contents, alongside a "Wizard Mode" that simplified extraction into a step-by-step process19. Status bars at the bottom of these applications were heavily utilized to display total file counts, compression ratios, and uncompressed sizes in highly segmented, sunken 3D panels.

Notepad and WordPad

Notepad represented the absolute baseline of Win32 applications: a single multiline edit control wrapped in a standard window with a basic menu bar. It featured no toolbars, no status bar by default, and a strict adherence to a fixed-width system font (Terminal or Courier New) unless manually overridden. WordPad, conversely, utilized a RichEdit control, a standard formatting toolbar with combo boxes for font selection, and a physical ruler control at the top of the document, mimicking early Microsoft Word paradigms.

Early Acrobat Reader

Early PDF viewers utilized heavily panelized interfaces. Unlike modern iterations that rely on floating context menus, Acrobat Reader 5/6 utilized permanent navigation panes on the left for bookmarks and page thumbnails, and a dense, sprawling double-row toolbar at the top of the screen21. The interface relied heavily on custom UI elements that slightly deviated from standard Windows controls, reflecting its cross-platform C++ codebase.

Paint Shop Pro and Graphics Tools

Prosumer graphics software like Paint Shop Pro 7 utilized the Multiple Document Interface (MDI), where child image windows lived entirely within the bounds of a dark gray parent application window7. Maximizing a child window merged its close/minimize controls into the parent menu bar. These tools were characterized by floating tool palettes that featured a "roll-up" mechanism: clicking the title bar of a floating palette would collapse it vertically to save screen real estate, expanding only when hovered or clicked7. Icons in these applications were highly proprietary, visually cryptic, and densely packed7.

Winamp and Skinnable Utilities

Media players birthed an entirely distinct UI culture centered around modularity and bitmap skinning. Interfaces were broken into independent, dockable windows (Main Player, Equalizer, Playlist) that snapped together magnetically. Visually, these tools abandoned standard OS gray in favor of dark interfaces, simulated LCDs, and green or amber numeric readouts. The spectrum analyzer, governed by strict 24-line RGB configurations (the viscolor.txt standard), provided continuous, low-latency visual feedback22. Playlist colors were defined by pledit.txt, and non-rectangular interfaces were achieved via boolean mask bitmaps defined in region.txt22.

Setup Wizards

The Wizard97 specification dictated a uniform installation experience across the platform. Exterior pages (Welcome, Completion) utilized a strictly dimensioned 317x193 dialog unit canvas featuring a watermark bitmap on the left and a large, bold Verdana 12pt title on the right2. Interior pages shrank to 317x143 dialog units to accommodate the standard navigation footer, featuring a white header spanning the top of the window, an aligned 16x16 or 32x32 icon in the top right corner, and standard Next, Back, and Cancel buttons anchored to a bottom gray panel separated by a deeply etched 3D line2.

Help Files (CHM)

Compiled HTML Help files utilized a standard tri-pane layout. A toolbar at the top contained Back, Forward, Print, and Options buttons. The left pane housed a tabbed navigation control (Contents, Index, Search) featuring a hierarchical tree view with small book and page icons. The right pane rendered standard HTML 4.0 content, effectively acting as an embedded instance of Internet Explorer27. Calling HH\_DISPLAY\_TOPIC from an application would invoke this specific viewer architecture natively27.

Terminal and Command Prompt

The command prompt operated outside the standard UI paradigms. It featured a pure black background with light gray text (\#C0C0C0). Crucially, the window did not support fluid resizing; its width and height were restricted strictly by the underlying character count buffer (e.g., 80 columns by 25 lines). Font rendering was strictly raster-based with no anti-aliasing, ensuring perfect pixel alignment for ASCII graphics.

Common Inconsistencies of the Era

The desktop environment of 1998–2006 was not perfectly uniform. The transition between Windows 9x, Windows 2000, and Windows XP meant that backwards compatibility often resulted in glaring visual anachronisms. It was common to see a modern program open a Windows 95-style file picker (utilizing older Win32 APIs) alongside a native OS program utilizing the modern common dialog boxes featuring the "Places Bar" on the left side. Furthermore, third-party developers often built custom controls that failed to inherit system-wide accessibility or visual settings. Custom toolbars might fail to utilize the system's selected highlight color, relying instead on hardcoded hex values. Font rendering within a single application could be highly inconsistent, with standard OS dialogs rendering crisp, ClearType Tahoma while custom graphical canvases drew blurry or un-antialiased text. Fake tab controls were also prevalent; developers sometimes used sets of adjacent toggle buttons visually styled to look like tabs, resulting in incorrect keyboard navigation orders and non-standard focus rectangles.

Tasteful Ways to Reproduce Inconsistencies

To ensure the archival workstation feels authentic rather than like a sanitized, idealized caricature, deliberate introduction of period-accurate inconsistencies is required.

1. API Epoch Mismatches: Configure different applications in the workstation to trigger different variations of common dialogs. The basic "Notepad" app should open a visually updated XP file picker with the Places Bar, while a niche utility app (like the archive tool) should trigger an older, 98-style file picker with a smaller footprint and traditional folder dropdowns.

2. Hardcoded Aesthetics in Custom Apps: The media player application should ignore the global desktop theme (Luna or Classic) entirely, operating on a fixed, dark-mode bitmap skin to simulate the Winamp paradigm24.

3. Variable Button Heights: Standardize most dialog buttons at 22 pixels in height29, but intentionally design one or two legacy utility windows where buttons are slightly cramped (e.g., 20 pixels) to simulate an application designed for an older 640x480 resolution constraint.

4. Mismatched Icon Formats: Populate the simulated file system with a mix of high-resolution 32-bit icons for modern files and jagged, 16-color icons for older system executables or obscure file types.

Details Modern Recreations Often Get Wrong

When recreating turn-of-the-millennium software, modern web developers and designers frequently fall into several well-documented traps that immediately break immersion:

• Over-Pixelation: Designers often apply heavy CSS pixelation filters, assuming all old interfaces looked like 8-bit video games. In reality, CRT monitors inherently smoothed edges due to phosphor glow, and by the XP era, LCDs utilizing ClearType produced highly readable, slightly softened text. The interface should be crisp, but never artificially blocky.
• Omnipresent Animations: Modern UI frameworks default to 200ms ease-in-out transitions on hover states, menu dropdowns, and dialog invocations. In 2001, state changes were instantaneous and binary. A menu appeared in exactly zero milliseconds.
• Incorrect Typography: Recreations frequently default to Arial, Helvetica, or standard web sans-serif. True authenticity requires Tahoma, MS Sans Serif, or perfectly mapped web-font equivalents, set at the exact pixel sizes dictated by historical guidelines (typically 11px or 12px CSS equivalent to 8pt/9pt desktop rendering).
• Missing Focus Rectangles: The one-pixel dotted focus rectangle is often discarded because modern designers find it aesthetically displeasing. Its absence immediately breaks the illusion for anyone who used the software natively, as it was the primary method of tracking state13.
• Improper Z-Indexing and Window Modality: Modern web modals typically overlay a dark, translucent backdrop over the entire screen to focus user attention. Historical desktop modals did no such thing; they merely blocked interaction with the specific parent window, emitting a system "ding" sound and flashing the title bar if the user attempted to click outside the dialog bounds.

Aspects That Should Remain Modern (Accessibility/Security)

While visual and interactive authenticity is the paramount goal, the workstation ultimately exists within a modern web browser. Certain historical paradigms must be overridden to ensure security, modern accessibility compliance, and functional viability.

1. Semantic DOM Structure: Do not simulate list boxes or menus using highly nested, meaningless \<div\> tags. Utilize semantic HTML (\<menu\>, \<dialog\>, \<ul\>, \<button\>) heavily styled with CSS to look vintage. This ensures screen reader compatibility, which was notoriously poor in the actual software of the era.

2. Font Scaling and High DPI: Hardcoding text to 11px will render the workstation entirely unusable on modern 4K or Retina displays. Typography must utilize scalable units (rem or em) that are functionally mapped to replicate the proportions of 8pt Tahoma relative to the viewport size, allowing the browser's native zoom functionality to work gracefully.

3. Sandboxing and Security: If the workstation allows user-uploaded files or simulates web browsing (such as an internal IE6 clone), it must rely on modern iframe sandboxing, CORS limitations, and strict Content Security Policies (CSP) to prevent cross-site scripting (XSS), deliberately bypassing the catastrophic ActiveX security flaws of the early 2000s.

4. Responsive Outer Shell: While the internal simulated desktop should operate on a fixed or explicitly managed coordinate system to emulate a 1024x768 desktop, the outer web application containing the emulator must be responsive, gracefully handling browser resizing and zooming without breaking the illusion or creating inaccessible scroll traps.

Recommendations for Each Current Workstation App

To build a cohesive ecosystem, each module within the archive workstation must adhere to specific historical archetypes outlined in the research.

Recommended Desktop-Wide Style Guide

To maintain coherence across the workstation and ensure multiple engineers build compatible components, developers must adhere to a strict CSS variable framework defining the aggregate OS environment. Color Palette (Luna Blue Variant base):

• Active Title Bar: Linear gradient from \#0058e6 to \#3a93ff.
• Inactive Title Bar: Linear gradient from \#7a96df to \#9db9f6.
• Window Background (Application Workspace): \#ffffff (for document canvases), \#ece9d8 (for standard dialog and control backgrounds, replacing the older Classic \#d4d0c8).
• Selection Blue (Highlight): \#316ac5.
• Selection Text: \#ffffff.
• Menu Background: \#ffffff with a \#ece9d8 vertical left gutter for 16x16 icons.

Typography Variables:

• \--font-system: Tahoma, Geneva, sans-serif (aliased rendering preferred if achievable via CSS).
• \--font-size-standard: 11px (or scalable equivalent mapping to 8pt).
• \--font-size-title: 13px bold (Trebuchet MS equivalent for title bars).
• \--font-size-wizard-header: 16px bold (Verdana equivalent for Wizard97 exteriors).
• \--line-height-standard: 1.2.

Metrics and Spacing:

• Title Bar Height: 25px (Luna), 18px (Classic).
• Standard Button Height: 22px29.
• Standard Button Width: 75px.
• Spacing between OK/Cancel buttons: 6px.
• Window Border Width: 3px (Luna, rounded top corners), 1px \+ 2px 3D bevel (Classic).
• Focus Rectangle: 1px dashed or dotted, inner offset by 1px from the control bounds.

Authenticity Checklist

The following 75-point checklist serves as the definitive Quality Assurance measure for verifying historical accuracy during the development of the archival workstation.

Works cited

1. Visual C++ 6.0 Brings Home a Full Bag of Tricks and Treats for MFC, https://jacobfilipp.com/MSJ/vc6.html

2. How to Create Wizards \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/controls/wizards

3. Why does Windows hide keyboard accelerators and focus, https://devblogs.microsoft.com/oldnewthing/20061005-00/?p=29463

4. Using Mnemonics \- wxWidgets, https://wxwidgets.org/docs/tutorials/using-mnemonics/

5. Windows XP Visual Design Guidelines | PDF \- Scribd, https://www.scribd.com/document/714877372/Windows-XP-Visual-Guidelines

6. Enhance Your Programs with New Windows XP Shell Features, https://learn.microsoft.com/en-us/archive/msdn-magazine/2001/november/new-graphical-interface-enhance-your-programs-with-new-windows-xp-shell-features

7. Paint Shop Pro 7.0 Jumps on the Vector, Web Bandwagons, https://creativepro.com/paint-shop-pro-7-0-jumps-on-the-vector-web-bandwagons/

8. Winamp \- Paweł Porwisz, https://pawelporwisz.pl/winamp/winamp.php

9. Visual Styles and themes in Windows XP \- DamienG, https://damieng.com/blog/2005/visualstylesandthemesinwindowsxp/

10. A retrospective on the Luna theme (and Royale). What was ... \- Reddit, https://www.reddit.com/r/windowsxp/comments/1em4urm/a\_retrospective\_on\_the\_luna\_theme\_and\_royale\_what/

11. History Of Windows Visual Styles: Luna, Aero & Unreleased\! 🖼️, https://www.youtube.com/watch?v=2kR42Vjn12M

12. Windows XP Design Guidelines \- retrospace, https://www.retrospace.net/download/WebApplications/WindowsXPDesignGuidelines/default.htm

13. Guidelines for Keyboard User Interface Design \- Microsoft Learn, https://learn.microsoft.com/en-us/previous-versions/windows/desktop/dnacc/guidelines-for-keyboard-user-interface-design

14. PaintShopPro User Guide | PDF | Icon (Computing) | Image Editing, https://www.scribd.com/document/138951069/PaintShopPro-User-Guide

15. Windows User Experience | PDF \- Scribd, https://www.scribd.com/doc/76548593/Windows-User-Experience

16. XP Task Pane Control for Windows Forms | Syncfusion, https://www.syncfusion.com/winforms-ui-controls/xptaskpane

17. Learn VB Net | PDF | Computers \- Scribd, https://www.scribd.com/doc/142198763/Learn-Vb-Net

18. Mastering Delphi 6, http://delphi.borlandforum.com/impboard/attach/0000040362/Mastering%20Delphi6.pdf

19. Christmas Giveaway: Winzip 14 \- gHacks Tech News, https://www.ghacks.net/2009/12/01/christmas-giveaway-winzip-14/

20. WinZip for Windows | FileForum, https://fileforum.com/detail/WinZip-for-Windows/948205652/1?all\_reviews

21. Moving Toolbars and Other Tools around on the Screen in Adobe DC, https://community.adobe.com/questions-9/moving-toolbars-and-other-tools-around-on-the-screen-in-adobe-dc-1302370

22. Winamp Skin Templates \- ReadMe \- Alpha-II, https://www.alpha-ii.com/Info/Template.html

23. Creating Winamp Skins \- bjoreman.com, https://www.bjoreman.com/old/winamp/skins.htm

24. Playing MP3 files (Designing Web Audio), https://docstore.mik.ua/orelly/web2/audio/ch08\_03.htm

25. Winamp skinning tutorial \- 4 \- Hugi, https://www.hugi.scene.org/online/hugi26/hugi%2026%20-%20graphics%20skinning%20sacrat%20winamp%20skinning%20tutorial%20-%204.htm

26. Writing Win32 apps like it's 2020: A DPI-aware resizable wizard, https://building.enlyze.com/posts/writing-win32-apps-like-its-2020-part-3/

27. HtmlHelpA function (htmlhelp.h) \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/api/htmlhelp/nf-htmlhelp-htmlhelpa

28. Connecting HTML Help To C++ & MFC Programs \- Scribd, https://www.scribd.com/document/55024336/Connecting-HTML-Help-to-C-MFC-Programs

29. What is the ideal height of a button in regular desktop applications?, https://ux.stackexchange.com/questions/9997/what-is-the-ideal-height-of-a-button-in-regular-desktop-applications