19 Oct 2019 @ 3:22 PM 

Over the last few years – more than a decade, really – it seems that, somehow, *nix- and Linux in particular, has been tagged as being some sort of OS ideal. It’s often been cited as a "programmers OS" and I’ve seen claims that WIn32 is terrible, and people would take the "Linux API" over it anyday. That is a verbatim quote as well.

However, I’ve thought about it some and after some rather mixed experiences trying to develop software for Linux I think I feel something of the opposite. Perhaps, in some ways, it really depends what you learned first.

One of the advantages of a Linux-based (or to some extent, UNIX-based) system is there is a lot of compartmentalization. The user has a number of choices and these choices will affect what is available to the applications.

I’d say that generally, The closest thing to a "Linux API" that applications utilize would probably just be the Linux Kernel userspace API.

Beyond that, though, as a developer, you have to start making choices.

Since the user can swap out different parts, outside of the Linux Kernel userspace API, pretty much nothing is really "standardized". Truth be told most of that kernel userspace API isn’t even used directly by applications- usually they get utilized through function calls to the C Standard library.

The Win32 API has much more breadth but tends to be more "simple", which tends to make using it more complicated. Since it’s a C API, you aren’t going to be passing around OO instances or interfaces; typically more complicated functions accept a struct. Hard to do much better than that with a C API.

However, with Windows, every Window is created with CreateWindowEx() or CreateWindow(). No exceptions. None. Even UWP Windows use CreateWindow() and have registered Window classes. Even if perhaps it’s not the most pleasant base to look at at least there is some certainty that, on Windows, everything is dealt with at that level and with those functions.

With Linux, because of the choices, things get more complicated. Since so many parts are interchangable, you can’t strictly call most of what is made available and used by applications a "Linux API" since it isn’t going to exist on many distributions. X11, for example, is available most of the time, but there are still Linux distributions that use Wayland or Mir. Even using just X11, it only defines the very basic functions- It’s a rare piece of software that actually interacts directly with X11 via it’s server protocol, usually software is going to use a programming interface instead. But which one? For X11 you’ve got Xlib or xcb. Which is better? I dunno. Which is standard? Neither. And then once you get down to it you find that it only actually provides the very basics- what you really need are X11 extensions. X11 is really only designed to be built on top of, with a Desktop Environment.

Each Desktop environment provides it’s own Programming Interface. Gnome as I recall uses "dbus"; KDE uses- what was it? kdetool? Both of these are CLI software that other programs are supposed to call to interact with the desktop environment. I’m actually not 100% on this but all the docs I’ve found seem to suggest that at the lowest level aspects of the desktop environment is handled through calls to those CLI tools.

So at this point our UI API consists of calling a CLI application which interacts with a desktop environment which utilizes X11 (or other supported GUI endpoints) to show a window on screen.

How many software applications are built by directly interacting with and calling these CLI application endpoints? Not many- they are really only useful for one-off tasks.

Now you get to the real UI "API"; the UI toolkits. Things like GTK+ or Qt. These abstract yet again and more or less provide a function-based, C-style API for UI interaction. Which, yes- accepts pointers to structs which themselves often have pointers to other structs, making the Win32 API criticism that some make rather ironic. I think it may arise when those raising the criticism are using GTK+ through specific language bindings, which typically make those C Bindings more pleasant- typically with some sort of OO. Now, you have to choose your toolkit carefully. Code written in GTK+ can’t simply be recompiled to work with Qt, for example. And different UI toolkits have different available language bindings as well as different supported UI endpoints. Many of them actually support Windows as well, which is a nice bonus. usually they can be made to look rather platform native- also a great benefit.

It seems, however, that a lot of people who raise greivance with Win32 aren’t comparing it to the direct equivalents on Linux. Instead they are perhaps looking at Python GTK+ bindings and comparing it to interacting directly with the Win32 API. It should really be no surprise that the Python GTK+ Bindings are better; that’s several layers higher than the Win32 API. It’s like comparing Windows Forms to X11’s server protocol, and claiming Windows is better.

Interestingly, over the years, I’ve come to have a slight distaste for Linux for some of the same reasons that everybody seems to love about it, which is how it was modelled so heavily on UNIX.

Just in the last few years the amount of people who seem to be flocking to OS X or Linux and holding up their UNIX origins (obviously more so OSX than Linux, strictly speaking) as if that somehow stands on it’s own absolutely boggles my mind. I can’t stand much about the UNIX design or philosophy. I don’t know why it is so constantly held up as some superior OS design.

And don’t think I’m comparing it to Windows- or heaven forbid, MS-DOS here. Those don’t even enter this consideration at this point- If anything can be said it’s that Windows wasn’t even a proper competitor until Windows NT anyway, and even then, Windows NT’s kernel definitely had a lot of hardware capability and experience to build off that UNIX never had in the 70’s- specifically, a lot of concepts were adopted from some of the contemporaries that UNIX competed against.

IMO, ITS and MULTICS were both far better designed, engineered, and constructed than any UNIX was. And yet they faded into obscurity. often People point at Windows and say "The worst seems to get the most popular!" But if anything UNIX is the best example of that. So now we’re stuck with people who think the best OS design is one where the the shell is responsible for wildcard expansion and the underlying scheduler is non-preemptive. I wouldn’t be surprised if the UNIX interrupt-during-syscall issue was still present, and instead of re-entering the syscall it returned an error code, making it the application’s responsibility to check for the error and re-enter the syscall.

It seems to me that one of the axioms behind many of the proclamations that "*nix is better designed" seems to be based on definitions of "better designed" that correspond to how *NIX does things- conclusion before the reason, basically.

Posted By: BC_Programming
Last Edit: 19 Oct 2019 @ 03:22 PM

EmailPermalinkComments (0)
Tags
 20 Apr 2019 @ 12:57 PM 

“Dark Mode” settings have started to be a big ticket concern for the last few years. Applications and Apps have started to add “Dark Mode” Visuals as an option, and more recently, Mac OS X (Now Mac OS, because that’s not confusing when you are interested in old software/hardware!) as well as Windows 10 have introduced their own “Dark Mode” featureset in the OS.

However, I’ve found Windows 10’s implementation confusing and actually a bit disturbing.

To explain, I’ll start at the beginning.

Graphical Environments in general have held to an idea that, for the most part, standard Graphical elements were managed by the OS. For example, on the Macintosh you would create software and it would use standard buttons, listboxes, etc. and the behaviour of those is handled by the OS. Your software didn’t have to handle detecting mouse clicks, drawing the button, changing it’s appearance when it’s clicked, etc. This concept was of course shared by Windows. on Windows 3.0 and 3.1, the system had “System Colors” that defined how different elements were drawn. Windows itself would use those colours where appropriate, for things like title bars and title bar font, and Applications could merely use the setting to use the current system setting. (And respond appropriately to the broadcast message when system settings are changed to deal with those colours changing). The system’s shipped with various “Themes” which were effectively sets of those colours, and you could customize  those colours to your liking.

Windows31

Windows 3.1 Dark Mode

Up through to System 7, the Macintosh held fast to most of it’s original UI designs in terms of visuals. Originally grayscale, later support for colour did add little bits here and there, primarily for the icons, but the main User interface was largely white with black or gray lines, or with rather subtle colouring.

System7Theme

Mac OS 8 with System 7 Theme via Kaleidoscope

System 7 however, on capable systems, also added a new feature that was available as a downloadable add-on from Apple- Appearance Manager. This was effectively a “plugin”  that would take over the task of drawing standard Elements, Elements were given a 3-D appearance; buttons “popped out” instead of being black chamferboxes. Progressbars got fancy gradients, and so on. This was part of the standard install with Mac OS 8 as well. These offered a lot of customization out of the box. Even more with software like Kaleidoscope. The standard appearance provided by the appearance manager was known as “Apple Platinum” and offered a number of colour options. (Mostly, the colours affected selection colour and the colour of progress bars, from what I can tell)

ApplePlatinum

Mac OS 8 Apple Platinum Theme (default)

Not to be outdone, Windows 95 introduced 3-D theming to the Windows environment, providing a similar set of changes to the standard appearance. Unlike Appearance Manager, one could also set the “3-D Colour” which affected the colour of most elements. This facilitated the creation of what could be called “Dark” themes.

Windows_95

Windows 95 with “Dark Theme”

It wasn’t until Windows XP that Windows had a feature similar in concept to Mac OS’s Appearance manager, through the introduction of Visual Styles. Visual Styles worked in much the same way- a Visual Style defined custom images that were used to draw particular window elements,  allowing a richer and more thematic styling to be applied. With Windows XP,  in addition to the default Visual Style, there was also an Olive and Silver Theme/Visual Style that was included. A “Theme”, which previously was a set of system colours, was changed to also include the Visual Style option. Additionally, you could decide to disable Visual Styles and use the “Windows Classic” Theme, which would not use the “Luna” Windows decorator. Interestingly, With the classic Theme style, one could adjust the colour options in much the same way as one could on previous Windows releases, creating “Dark Mode” colour schemes if desired.

xpDefault

XP (Default)

xpOlive

XP (Olive)

xpSilver

XP (Silver)

xpClassic_dark

XP (Classic, “Dark”)

Around that same time frame, The Macintosh Operating System was migrated to OS X, something of a hybrid of the older Mac system and the NeXTStep Operating System. This introduced the concept of a “Composited desktop” to the mainstream. In a traditional desktop environment, it operates on a single output “image”. When you move a window, it get’s redrawn in the new location, and any revealed sections of the screen below need to be redrawn as well. A composited desktop keeps all that necessary information in memory- for example, it may hold the bitmaps that represent each window as a texture, and merely compose them together to create the final image, usually through the use of 3-D Accelerated Video hardware. With capable hardware, this approach was much faster and in general much cleaner. Internally, there was a framework for UI element drawing. However, externally, it was necessary to use third-party software to reskin the styles of the OS (Shapeshifter, for example).

Windows Vista brought this same composited desktop experience to the Windows platform, this new technology was Aero. This underlying composited desktop experience has been used up through to Windows 10. Aero has similar capabilities to Luna, in that Visual Styles can customize almost every element of the system. “Aero Glass”, which many associated with Aero, was an enhancement to allow fancy affects to be done using the 3-D Rendering that is performed on the composited information. In it’s case, providing a sort of “translucent glass” effect which blurs the text behind the “glass” areas of a window (typically, the title bar).

vista

Windows Vista

Basically, over the years, there have been a number of solutions and options for a central, system controlled set of colours and repeated thematic elements such as buttons. Which of course is what brings me finally, to why I find Windows 10’s dark mode both confusing and disturbing- it leverages none of these technologies!

The Dark Mode feature of Windows 10 is implemented effectively as an on-off flag which does not change Windows behaviour. Instead, applications all need to check this flag and operate appropriately. the libraries behind UWP Apps will perform this check and change their visual theming appropriately. That is all. Win32 applications are unaffected. To implement Dark Mode in File Explorer, for example, Microsoft developers have changed File Explorer to see the flag and use different Dark colours for all UI elements if it does.

But it makes no sense. Every piece of Windows now needs to be altered to allow for this. And even if every part of Windows has these changes made to support it, Third party applications aren’t guaranteed to support it, either. Lastly, nothing about the Dark Mode support is standard- From an application perspective, if Dark mode is on, you cannot use the Visual Style- so what should a Button look like in dark mode? A Combo box scrollbar? etc. Even the colours have no standard- it’s all up to the application.

The implementation of Dark Mode makes no sense because it should have been a new Theme with appropriate dark colours that comes with Windows which also uses a new Visual Style that changes all the visual elements to have a darker colour. If Dark Mode is on, no application should see “white” for the Window background colour and be expected to disregard it if it seems Dark mode is on and use “A dark colour” of some sort that isn’t standardized for different elements.

Posted By: BC_Programming
Last Edit: 20 Apr 2019 @ 12:57 PM

EmailPermalinkComments Off on The failures of Windows 10 “Dark Mode”
Tags
Categories: Windows
 23 Mar 2019 @ 2:15 PM 

There are a lot of components of Windows 10 that we, as users, are not “allowed” to modify. It isn’t even enough when we find a way to do so, such as by disabling services or scheduled tasks by using command prompt running under the system account. This is because when you next install updates, those settings are often reset. There are also background tasks and services intended specifically for “healing” tasks, which is a pretty friendly way to describe a  trojan downloader.

One common way to “assert” control is using the registry and the Image File Execution Options key, found as:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

By adding a Key here with the name of the executable, one can add additional execution options. The one of importance here is a string value called debugger. When you add a debugger value, Windows will basically not start the executable and will instead launch the executable listed for the “debugger” value, with the executable that was being run as a parameter.

We can use this for two purposes. The most obvious is that we can simply swap in an executable that does nothing at all, and basically prevent any executable from running. For example, if we add “C:\Windows\System32\systray.exe” as the debugger value for an executable, when the executable in question is run, instead the systray.exe stub will run, do nothing, and exit, and the executable that was being launched will not. As a quick aside- systray.exe is a stub that doesn’t actually do anything- it used to have built-in notifications icons for Windows 9x, and it remains because some software would actually check if that file existed to know whether it was running on Windows 95 or later.

The second way we can use it is to instead insert our own executable as the debugger value. Then we can log and record each invocation of any redirected program. I wanted to record the invocations of some built-in Windows executables I had disabled, so I created a simple stub program for this purpose:

IFEOSettings.cs

I Decided to separate the settings for future editing. For my usage, I just have it hard-coded to C:\\IMEO_Logs right now and create the folder beforehand. The bulk of the program of course is the entry point class:

I’ve used this for a few weeks by manually altering the Image File Execution Options to change my existing settings that redirected some executables (compattelrunner.exe, wsqmcons.exe, and a number of others) to systray.exe to instead redirect to this program- It then logs all the attempts to invoke that executable alongside details like the arguments that were passed in.

Posted By: BC_Programming
Last Edit: 23 Mar 2019 @ 02:15 PM

EmailPermalinkComments Off on Taking Control of Windows 10 with Image File Execution Options
Tags
 14 Mar 2019 @ 6:51 PM 

Alternate Title: Software Licenses and implicit trust

It is interesting to note that in many circles proprietary software is inherently considered untrustworthy. That is, of course, not for no reason- it is much more difficult to audit and verify that the software does what it is supposed to and to check for possibly security problems. However, conversely, it seems that a lot of Open Source software seems to get a sort of implicit trust applied to it. The claim is that if there isn’t somebody sifting through and auditing software, you don’t know what is in there- and, conversely, that if something is open source, we do know what is in there.

But, I would argue that the binaries are possibly more trustworthy in attempting to determine what a piece of software is doing simply by virtue of it being literally what is being executed. Even if we consider the scenario of auditing source code and building binaries ourself, we have to trust the binary of the compiler to not be injecting malicious code, too.

I’ve found that this sort of rabbit hole is something that a lot of Open Source advocates will happily woosh downwards as far as possible for proprietary software, but seem to avoid falling for Open Source software. Much of the same logic that get’s applied to justify distrust of proprietary binary code should cause distrust in areas of Open Source, but for some reason a lot of aspects of Open Source and the Free Software Community are free from the same sort of cynicism that is applied to proprietary software, even though there is no reason to think that software falling under a specific license makes it inherently more or less trustworthy. If we can effectively assume malicious motives for proprietary software developers, why do we presume the opposite for Open Source, particularly since it is now such a better target for malicious actors due to the fact that it is so often implicitly trusted?

Source code provided with a binary doesn’t mean anything because- even assuming users capable of auditing said code, there is no way to reliably and verifiably know that the source code is what was used to build the binary. Trust-gaining exercises like hashes or MD5sums can be adjusted, collided, or changed and web servers hacked to make illegitimate binary releases appear legitimate to propagate undesirable code which simply doesn’t appear in the associated source code with a supposed release (Linux Mint). Additionally, The indeterminate nature of modern compilers means that even compiling the same source more than once can often give completely different results as well, so you cannot really verify that the source matches a given binary by rebuilding the source and comparing the resulting binary to the one being verified.

Therefore, it would seem the only reasonable recourse is to only run binaries that you build yourself, from source that has been appropriately audited.

Thusly, we will want to audit the source code. And the first step is getting that source code. A naive person might think a git pull is sufficient. But no no- That is a security risk. What if GitHub is compromised to specifically deliver malicious files with that repository, hiding secret exploits deep within the source codebase? Too dangerous. Even with your careful audit, you could miss those exploits altogether.

Instead, the only reasonable way to acquire the source code to a project is to discover reliable contact details for the project maintainer and send then a PGP encrypted message requesting that they provide the source code either at a designated drop point- Which will have to be inconspicuous and under surveillance by an unaffiliated third party trusted by both of you – Or have him send a secure, asymmetrically encrypted message containing the source tarball.

Once you have the source, now you have to audit the entire codebase. Sure, you could call it quits and go "Developer says it’s clean, I trust him" fine. be a fool. be a foolish fool you fooly foolerson, because even if you know the tarball came from the developer, and you trust them- do you trust their wife? their children? their pets? Their neighbors? You shouldn’t. In fact, you shouldn’t even trust yourself. But you should, because I said you shouldn’t and you shouldn’t trust me. On the other hand, that’s exactly what I might want you to think.

"So what if I don’t trust their hamster, what’s the big deal"

Oh, of course. Mr Security suddenly decides that something is too off-the-wall.

Hamsters can be trained. Let that sink in. Now you know why you should never trust them. Sure, they look all cute running on their little cage, being pet by the developers cute 11 year old daughter, but looks can be deceiving. For all you know their daughter is a secret Microsoft agent and the hamster has been trained or brainwashed- using evil, proprietary and patent encumbered technology, no doubt, to act as a subversive undercurrent within that source repository. With full commit access to that project’s git repository, the hamster can execute remote commands issued using an undocumented wireless protocol that has no man page, which will cause it to perform all sorts of acts of terror on the git repository. Inserting NOP sleds before security code, adding JMP labels where they aren’t necessary. even adding buffer overflows by adding off-by-one errors as part of otherwise benign bugfixes.

Is it very likely? No. But it’s *possible* so cannot be ignored.

Let’s say you find issues and report them.

Now, eventually, the issues will be fixed. The lead developer might accept a pull, and claim it to fix the issue.

Don’t believe the lies. You must audit the pull yourself and find out what sinister motives underly the so-called "fix". "Oh, so you thought you could just change that if condition, did you? Well did you know that on an old version of the PowerPC compiler, this generates code that allows for a sophisticated remote execution exploit if running under Mac OS 9?" Trust nobody. No software is hamster-proof.

Posted By: BC_Programming
Last Edit: 14 Mar 2019 @ 06:51 PM

EmailPermalinkComments Off on No Software is Hamster-proof
Tags
 09 Dec 2017 @ 12:27 PM 

Winamp is a rather old program, and to some people it represents a bygone era- the late 90’s and early 2000’s in particular. However I’ve not found any “modern” software that compares. There is plenty of software- MediaMonkey, MusicBee- etc which attempts to mimic Winamp, or provides the same general capability of managing a local music library, but they either don’t support Winamp Plugins, don’t work properly with many such plugins- or, most importantly, don’t add anything.

Not adding anything is the important one here. At best, I’m getting the same experience as I do with Winamp, so I’m not gaining anything. People ask, “Why don’t you switch” and the default answer is “Why should I?” If the only reason is because what I am currently using is “outdated” and no longer cool, then maybe I should stick with it because we have something in common.

Typically, I’m losing functionality, though. With Winamp I’ve got everything setup largely how I want. More importantly, it  spans not only FLAC and MP3 Music files, but my Music Library also incorporated various Video Game Music formats for various systems, with complete audio libraries for any number of game titles that I can pull up easily. These are native formats which are much smaller  than if those tracks were encoded as MP3 or FLAC and since they are native formats they use Winamp plugins, Which provide additional features for adjusting audio capabilities. These plugins simply don’t exist or don’t work with modern software, so I’d have to relegate those video game music formats to specific, individual players if I was to switch to say “MusicBee” for my local music library.

Nowadays, even the concept of a local Audio Library is practically unheard of. People “Listen to music” by using streaming services or even just via youtube videos, and typically it is all done via a smartphone where storage space tends to be at a greater premium as well. I find that I detest playing music on my Phone (Nexus 6) simply because there is no good software for managing Music saved to the local storage, and it get’s awful battery life if used this way. This is why I use an older 16GB Sony Walkman MP3 player instead; the battery could probably playback for a good continuous 48 hours, and it is much more compact than the phone is. And even if this means an extra piece of “equipment” when I go somewhere, it means that I’m not wasting my phone’s battery life to play music.

Recently, I had the need to do something that is nearly as “outdated” as the program I elected to do it, which is burning an Audio CD. I’ve found this to be the easiest way to transfer music to my Original XBox Console to create custom soundtracks (something which seems to be unique among consoles altogether). So I popped in a CD-RW, opened winamp, clicked on the CD Recorder…. and got a BSOD. DPC_WATCHDOG_VIOLATION.

Well, not that isn’t supposed to happen. After determining it was reproducible, I looked further into it. In particular I found that within the Current Control Set information for my hardware CDROM had an LowerFilters driver specified for PxHlpa64. So, I set about searching what this was.

I found that PxHlpa64 is a Driver by “Sonic Solutions” which is used by some CD Recording software. I couldn’t find any such software that uses it installed, so I merely renamed the affected key and rebooted. The problem went away and everything was as it should be. (And I subsequently wiped out the directory containing the driver file) I suspect that I installed a program previously which used the driver file and the uninstall didn’t remove it for any of a number of reasons.

One of the advantages of having a bit of an idea what is going on with Windows (or any OS really) is that you can more intelligently attempt to solve these sorts of unexpected problems you may encounter. Since I was aware of issues involving Optical drivers and driver “Filter” settings I was able to find and fix the cause of my issues fairly quickly.

Posted By: BC_Programming
Last Edit: 09 Dec 2017 @ 12:27 PM

EmailPermalinkComments Off on Music Applications, CD Burning, and the BSOD
Tags
 07 Aug 2017 @ 6:24 PM 

A while ago, it came out that Microsoft Paint would be deprecated going forward on Windows 10, replaced, instead, with Paint 3D. There have been loads of articles, forum threads, and general griping about this across the Internet. Nonetheless, Paint is hardly the first “casualty” of Windows as it moved forward; nor is it’s loss, realistically, a big one.

A History

“Paint” existed in some form or another dating back to the original Windows release. Like many parts of Windows, it was based on an existing product, but stripped down. In this case Windows Paintbrush was effectively PC Paintbrush 1.05 for Windows but stripped down so as to not compete with the full product.

Windows 1.04

Paint on Windows 1.04

Aside from a smaller set of tools, it appears that another limitation of the included program is that it can only work with monochrome bitmaps. For the time period, that isn’t a surprising limitation though- The Apple Macintosh’s MacDraw program had a similar color limitation.

Windows /286

PAINT running on Windows /286

Windows/286 didn’t change the included PAINT program very much- I wasn’t able to find any significant differences myself, at least. it seems to have the same limitations. I wasn’t able to get Windows /386 to work however I presume PAINT is the same program between them, being that the major difference is enhancements for the 386.

Windows 3.0

Paintbrush running on Windows 3.0

It was with Windows 3.0 that PBRUSH was effectively created. While still seeming to be based largely on PC Paintbrush, the Windows 3.0 version, aside from changing the program title to “Windows Paintbrush” from “PAINT” as well as the executable, also redesigned part of the User Interface. Interestingly, this interface is more similar to the more complete PC Paintbrush product as provided on Windows /286, but of course it did not provide the full toolset of the commercial product either.

Windows 3.1

Paintbrush on Windows 3.1

PBRUSH didn’t see any significant changes from Windows 3.0. It still had a number of annoying limitations that plagued previous releases; in particular, tools couldn’t work with data outside the visible canvas. This meant you couldn’t even paste a screenshot into the program- It would be cropped. You can see this below- this is after performing a floodfill on the outer area of the above, then scrolling down- the exposed canvas was not affected by the operation.

Win 3.1 Paint floodfill failure

Windows 95

MSPaint on Windows 95

Windows 95 saw PBRUSH deprecated in favour of MSPAINT; Not just deprecated, mind you- but altogether removed; however, you could still invoke PBRUSH, due to a new “App paths” feature of Windows. This capability exists to today- Like Win95 there is no PBRUSH.EXE in Windows 10, but running PBRUSH will start MSPaint, as it has since Windows 95. The new Windows 95 version of Paint is now “Microsoft Paint” rather than “Windows Paintbrush” and sports a new executable as well. It also redesigns the interface to adhere to the new “3D” style that Windows 95 introduced, as well as making use of other Windows features that had been enhanced; for example, while you could edit colors in the older Windows Paintbrush, the program used a set of three sliders for that customization. Windows 95 added a new Custom Color dialog, which Microsoft Paint made use of for customizing the palette entries. Thanks to how that dialog worked it meant you could save several custom colors outside of the normal palette and swap between them, too. It also adds a Status bar, which was coming into it’s own with Windows 95 as a convention; This included “tip” text appearing on the left as well as other information appearing in additional panes on the status bar.

Windows 98

MSPaint on Windows 98SE

Windows 98’s release of Microsoft Paint seems to have removed the ability to load and save Custom Colour Palettes. Additionally, it also dropped the ability to save to the .PCX format, while gaining the ability to use certain installed image filters, allowing it to save to .PNG for example, if certain other software is installed.

Windows ME

MSPaint on Windows ME

The Windows ME version of MSPaint appears to be identical to the Windows 98SE Version, however, the executables are not identical- I’m not sure what difference there might be beyond the header indicating it is for a different Windows Version, though. It’s here for completeness.

Windows 2000

MSPaint on Windows 2000

Another entry for completeness as, like Windows ME, I cannot find any differences between it and the Windows 98SE release of MSPaint.

Windows XP

MSPaint on Windows XP

Windows XP introduced a few major revisions to MSPaint. First, it could acquire information from a Scanner or any TWAIN device (Such as a digital Camera). Moreover, it now had native support for JPEG, GIF, TIFF and PNG File formats, without any additional software installs.

Windows Vista

MSPaint running on Windows Vista

The WIndows Vista release of paint changes the default colour palette, has a set of new tool icons, And Reorganizes some of the UI (the Color palette is moved, for example). It changes the undo stack to 10 deep rather than 3, and saves to JPEG by default- which suggests that it was intended or expected largely to be used for acquiring and saving photos.

Windows 7

MSPaint as included in Windows 7.

Windows 7 is another major overhaul of the program, on the same level as the change from the PaintBrush program in Windows 3.1 to MSPaint in Windows 95. This redesigns the interface around the “Ribbon” concept, and adds a number of capabilities, brushes, and a few tools. It also now has anti-aliasing.

Windows 8

This version is pretty much identical to the Windows 7 release; though there are some minor adjustments to the Ribbon.

Future

Microsoft Paint is now deprecated, but this doesn’t prevent you from using it; even when it is removed from the default installation, it will still be made available as a free download from the store. You can also copy/paste a version of paint from a previous Windows 10 install to avoid dealing with an appx container file or any tracking that comes with using the Windows Store, if desired. I think the fuss over this change is a bit of an overreaction. There are plenty of other free programs that can accomplish the same tasks and while it is a bit annoying to have to download them, Windows will still include Paint 3D which should be capable of the same standard tasks people want the older Paint program for, such as screenshots.

The old PBRUSH application running on Windows 10. It’s a Miracle.

What is this witchcraft? Windows NT 3.51 was 32-bit, but was based around Windows 3.1, so it got a 32-bit version of the same old PBRUSH program from Windows 3.1. That can be copied from an NT 3.51 install and run directly on Windows 10. Pretty interesting- Though of arguably limited usefulness, beyond putting it at the end of blog posts to pad out the length for no reason.

Posted By: BC_Programming
Last Edit: 07 Aug 2017 @ 06:24 PM

EmailPermalinkComments Off on The deprecation of Microsoft Paint
Tags
 05 Apr 2017 @ 11:31 AM 

For a while now Windows 10 has had a “Game Mode” feature. I’m rather mixed on the feature myself, but generally find it strange.

I’ve never been a fan of the “Game Booster” software phenotype; it seems like it is largely snake oil fakery, and where it does have an effect, it is really just a result of the same sort of adjustments that can be made manually via services or other configuration options. Game Mode does have an advantage, here; the first is that it sort of puts those applications “out of business”, and, being built into the OS, it is a much safer implementation, and it’s  goals are less extreme. On the other hand, it does sort of legitimize the concept, which I’ve always found crazy, that such applications are in any way worth using.

I tend not to use the feature, however I can see it having benefits for some users and some systems. To me, overlay features such as the Game Bar that are used in this case feel like a sort of “chaff”; It is better than older approaches like the “Games for Windows Live” featureset, and better implemented as well, but I’ve found that- at least for now- it’s not really for me. This may be partly because I’m not a particularly heavy gamer, though- I seldom play games on my PC- nowhere near what I expected.

I also tend to enjoy older titles. Interestingly, I’ve found many older games- even going back to Win98 Games, run surprisingly well on Windows 10, most issues I’ve encountered with older titles tend to be a result of either lack of 16-bit compatibility (with much older titles) or are a result of the hardware being far in excess of what the game ever expected. A lot of older titles don’t have support for 2560×1440 for example because it is such a high resolution, requiring minor patches. Windows 10 is surprisingly backwards compatible in this regard. Even better than previous Post-Vista Windows releases, including Windows 7 which had an interesting explorer palette realization issue. that tended to cause problems with games that used 256-color modes.

Posted By: BC_Programming
Last Edit: 05 Apr 2017 @ 11:31 AM

EmailPermalinkComments Off on Windows 10 “Game Mode”
Tags
Categories: Games, Windows
 17 Mar 2017 @ 9:59 PM 

There has been some concern and even repudiation about Microsoft’s decision to not provide updates to Windows 7, 8, and 8.1 when run on hardware using a newer processor, such as the Intel Kaby Lake processors. This has been claimed by some as a marketing move to try to “force” users to use Windows 10.

Now, I’m not the greatest fan of some of the things introduced with Windows 10. At the same time, I have no modern systems- other than Virtual Machines- not running either Linux or Windows 10. So it’s more an annoyance at how much one has to do to appropriately assert one’s desired options with Windows 10.

Windows 7 and 8/8.1 have continued to be supported as per the Windows lifecycle; the change is for hardware that was literally introduced after the end of mainstream support for both operating systems. Extended support only applies to Security updates; however, supporting security updates on Windows 7 and 8/8.1 with those Processors would mean supporting the processor. The issue there is that while the newer chips likely run the same way as older chips did with the same code, there is no guarantee of that, and it would still require the software to be tested and bugfixed specifically for those newer chips, which means effectively, supporting the new processors.

The Updates cannot go out on an “as is” basis to systems with the new processors because hten any problems will incur support costs and bugfixes to those updates that will also effectively mean supporting the new processors on the older software.

Worth noting is that this doesn’t lock out enterprising users who are willing to take the risk that their entire Win7/Win8/8.1 system will stop functioning due to said updates. One can still workaround this, it just requires you to step off the beaten path even further, making it much more clear and far “safer” for Microsoft to tell you to basically piss off if you try to get support.

It’s likely this approach may have been adopted to try to prevent another repeat of the Windows XP diehards. Mind you, it hasn’t worked so far; Many people are now Windows 7 diehards to much the same capacity. But at least- from Microsoft’s perspective- they won’t be financing it.

Posted By: BC_Programming
Last Edit: 17 Mar 2017 @ 09:59 PM

EmailPermalinkComments Off on New Processors and Windows 7 and 8/8.1
Tags
 24 Nov 2016 @ 10:03 PM 

There is a seemingly common affliction affecting some users of Windows where they find that their desktop icons receive old-style focus rectangles. This seems to affect Windows Vista and later.

Dotted Focus Rectangle.

After some investigation, I found the cause to be an Accessibility setting. inside Ease of Access in Control Panel, There is a “Change how the keyboard works” option. This option takes you to another page with “Underline keyboard shortcuts and access keys”. When this option is checked, Keyboard cues are enabled. This includes the underlined text of menus and buttons- but it also includes ListView Focus Rectangles, which means with the option enabled there is a Focus rectangle shown on the desktop rather frequently.

To change this setting, toggle it and reboot.

Posted By: BC_Programming
Last Edit: 24 Nov 2016 @ 10:03 PM

EmailPermalinkComments Off on Desktop Icon Dotted Focus Rectangle Mystery
Tags
 09 Nov 2016 @ 8:30 AM 

I’ve previously written about making adjustments to the Windows Master Volume control programmatically. I alluded to the addition of possible other features such as being able to view the volume levels of other applications. I’ve gone ahead and made those changes.

The first thing to reiterate is that this makes use of a low-level .NET Wrapper for the Windows Core Audio API. This can be found here.

The first thing I decided to define was an object to represent a single Applications Volume Session info/properties. In addition, it will be provided a reference to the IAudioSessionControl interface representing that application’s Audio session, so it can be directly manipulated by adjusting the properties of the class.

Next, we need to declare a COM import, the Multimedia Device enumerator. Specifically, we need to import the class, as the Vannatech Library only provides interfaces, which we cannot instantiate:

Now that we have a starting point, we can create an enumerator method that retrieves all active audio sessions as “ApplicationVolumeInformation” instances:

A github repository with a more… complete… implementation of a working Console program can be found here.

Posted By: BC_Programming
Last Edit: 11 Nov 2016 @ 12:29 PM

EmailPermalinkComments Off on Retrieving and Setting individual Program Volume
Tags
Categories: .NET, C#, Programming, Windows

 Last 50 Posts
 Back
Change Theme...
  • Users » 47469
  • Posts/Pages » 393
  • Comments » 105

PP



    No Child Pages.

Windows optimization tips



    No Child Pages.

Soft. Picks



    No Child Pages.

VS Fixes



    No Child Pages.

PC Build 1: “FASTLORD”



    No Child Pages.