Category Archives: Tools and Utilities

Programming tools and various software utilities.

Disabling Automatic Closing Braces in Visual Studio Code

I really like Visual Studio Code as an editor, but it has some annoying defaults.

When working in C# (and a lot of other languages), it tries to be “helpful” by automatically adding closing braces, brackets, and parentheses when you type the opening ones.

An Automatic Closing Brace

Automatic closing brace added when typing an opening brace.

For some people, this is great. For me, no. It just doesn’t work with my typing and coding style, and ends up being something that gets in the way and I have to move or remove later.

Fortunately it’s easy to turn this off.

Go to File –> Preferences –> Settings

Search for “auto closing brackets”.

Change “Editor: Auto Closing Brackets” to “never”.

Auto Closing Brackets Setting

Turning off the auto closing brackets setting.

Problem solved. Happy coding!

Fixing Error LNK2038 In a Visual Studio Project

While building a Visual Studio C++ project in Visual Studio 2022, I received this error while linking to a library:

Error LNK2038 mismatch detected for ‘_MSC_VER’: value ‘1800’ doesn’t match value ‘1900’ in MidiPlayer.obj MIDIPlayer E:\code\MIDIPlayer\wxmsw30ud_core.lib(dlgcmn.obj)

In case you’re not familiar with this error, Visual Studio wants to link with libraries that were built with the same version of Microsoft C (same toolset) as the code you’re compiling. In older versions of Visual Studio that meant that they had been built with the same version of Visual Studio, but now that versions aren’t as tightly-coupled to Visual Studio, it’s also possible that you can get this with libraries built with the same version of Visual Studio that you’re using.

The solution is to rebuild the library with the same MSC version as your project.

For reference, here are the different MSC, MSVC, and toolset versions:

Microsoft C 6.0: _MSC_VER == 600
Microsoft C/C++ 7.0: _MSC_VER == 700
Microsoft Visual C++ 1.0: _MSC_VER == 800
Microsoft Visual C++ 2.0: _MSC_VER == 900
Microsoft Visual C++ 4.0: _MSC_VER == 1000
Microsoft Visual C++ 4.1: _MSC_VER == 1010
Microsoft Visual C++ 4.2: _MSC_VER == 1020
Microsoft Visual C++ 5.0: _MSC_VER == 1100 (Visual Studio 97)
Microsoft Visual C++ 6.0: _MSC_VER == 1200 (Visual Studio 6.0)
Microsoft Visual C++ 7.0: _MSC_VER == 1300 (Visual Studio 2002)
Microsoft Visual C++ 7.1: _MSC_VER == 1310 (Visual Studio 2003)
Microsoft Visual C++ 8.0: _MSC_VER == 1400 (Visual Studio 2005 – v80)
Microsoft Visual C++ 9.0: _MSC_VER == 1500 (Visual Studio 2008 – v90)
Microsoft Visual C++ 10.0: _MSC_VER == 1600 (Visual Studio 2010 – v100)
Microsoft Visual C++ 11.0: _MSC_VER == 1700 (Visual Studio 2012 – v110)
Microsoft Visual C++ 12.0: _MSC_VER == 1800 (Visual Studio 2013 – v120)
Microsoft Visual C++ 14.0: _MSC_VER == 1900 (Visual Studio 2015 – v140)
Microsoft Visual C++ 14.1 – 14.16: _MSC_VER == 1910 – 1916 (Visual Studio 2017 – v141)
Microsoft Visual C++ 14.2 – 14.29: _MSC_VER == 1920 – 1929 (Visual Studio 2019 – v142)
Microsoft Visual C++ 14.3: _MSC_VER == 1930 (Visual Studio 2022 – v143)

It’s interesting that starting with Visual Studio version 2017, Microsoft started incrementing the MSC version with each “micro” build change.

Telling Git To Ignore File Mode Changes

It’s possible for Git to think there have been changes to files when only permissions have changed. This is something that is pretty common if you work across multiple operating systems, and it can be annoying.

For example, running “git status” showed that two of my icon files had changed, but hadn’t edited them. Running “git diff” showed that it was just the file mode properties (permissions or “props”) that had changed.

$ git diff
diff –git a/images/samplitron_largeicon.png b/images/samplitron_largeicon.png
old mode 100644
new mode 100755
diff –git a/images/samplitron_largeicon.xcf b/images/samplitron_largeicon.xcf
old mode 100644
new mode 100755

To make Git stop treating this as a change, there’s a command you can run:

git config –global core.fileMode false

Now when you run “git status” or “git diff”, file mode changes will be ignored.

Fixing Error MSB3843 in a Visual Studio Project

I updated my DrumPads code project to the latest version of Visual Studio 2022 and received this error when trying to build:

Error MSB3843 Project “DrumPads” targets platform “Windows”, but references SDK “Visual C++ 2015-2019 Runtime for Universal Windows Platform Apps v14.0” which targets platform “UAP”. C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets

I’m not sure whether the project was actually set to be UAP, or whether the migration set something to that.

Visual Studio Solution Explorer Showing "Universal Windows"

Solution Explorer Showing “Universal Windows”

To fix the error, I edited the DrumPads.vcxproj file manually. In the PropertyGroup sections for the build configurations I changed this:

<PropertyGroup Condition=”‘$(Configuration)|$(Platform)’==’Release|Win32′” Label=”Configuration”>
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<WholeProgramOptimization>true</WholeProgramOptimization>
<CharacterSet>Unicode</CharacterSet>
<PlatformToolset>v143</PlatformToolset
<WindowsAppContainer>true</WindowsAppContainer>
</PropertyGroup>

I removed the line <WindowsAppContainer>true</WindowsAppContainer> entries from all of the configurations and reloaded the project. It no longer showed up as “Universal Windows” and I was able to build without the error.

Solution Explorer Without "Universal Windows"

Solution Explorer Without “Universal Windows”

Changing the Remote URL for a Git Repository

Maybe the repository has been moved, or maybe you have an old repository that was checked out with username and password authentication, and you can’t push to it anymore because GitHub requires ssh authentication now. That was true in my case, since I was going back to work on code I hadn’t touched for a few years.

Although you could just re-check-out the repository, that is unnecessary, and can be annoying if you have changes that you want to push.

Changing the remote URL for a git repository is a simple thing to do, but it’s not necessarily obvious. It’s done using the “git remote” command.

To display the URL of the remote repository:

git remote get-url origin

https://github.com/xangis/SigmaTizm
To change this to a new URL:
git remote set-url origin git@github.com:Xangis/Sigmatizm.git
With this one-line change I was able to continue working as normal without needing to re-check-out the repository.

Windows Software by Lambda Centauri

I’ve written a lot of apps for Windows (and other) PCs. Originally I published everything as Zeta Centauri, but it was a weird combination of audio apps and utilities that didn’t mesh well with audio apps (calculators, word processing, image viewer, browser). I’ve launched a new website for the utility apps to keep them separate from the audio apps.

Check it out here: https://lambdacentauri.com

Updating a wxWidgets project for Visual Studio 2019

I recently resurrected a dormant code project and went through the process of converting a wxWidgets 3.0 project to wxWidgets 3.1 and updaing from Visual Studio 2010 to Visual Studio 2019.

Include Directories

Here are the things I had to change to make things build and run:

Change “Platform Toolset” to Visual Studio 2019 in General configuration properties.

Change include and library directories from wxWidgets 3.0.2 to 3.1.4 in VC++ Directories and update the include path for modern Visual Studio. The change to $(IncludePath) does a lot of magic things that will save a lot of trouble. Failure to update that will cause common includes like stdafx.h to be missing.

Change include from:
E:\lib\wxWidgets-3.0.2\include;$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)include;$(FrameworkSDKDir)\include
to:
E:\lib\wxWidgets-3.1.4\include;$(IncludePath)

Code

The only code changes I had to make were to remove wxADJUST_MINSIZE anywhere it showed up.

Libraries

This is for the debug version of the project. Remove the “d” for libraries in the release version (i.e. wxbase31ud_core.lib => wxbase31u_core.lib).

These libraries showed up as missing:

comctl32.lib
rpcrt4.lib
uuid.lib
kernel32.lib

Adding C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x86 to the linker directories fixed this.

msvcprtd.lib

Adding C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\lib\x86 to the linker directories fixed this.

ucrtd.lib

Adding C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x86 to the linker directories fixed this.

wxregexu.lib

Adding that to the library list fixed it.

I suspected there was something similar to $(IncludePath) I could add to the library paths to make those resolve, but I wasn’t sure. So I tried $(LibraryPath). And it worked. Magic!

So do that instead of adding those individual directories.

Change library path from:
E:\lib\wxWidgets-3.0.2\include;$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)include;$(FrameworkSDKDir)\include
to:
E:\lib\wxWidgets-3.1.4\include;$(IncludePath)

Update all the libraries from wx 3.0 versions to wx 3.1 versions:

wxmsw30ud_core.lib => wxmsw31ud_core.lib
wxbase30ud.lib => wxbase31ud.lib
wxmsw30ud_adv.lib => wxmsw31ud_adv.lib
wxmsw30ud_html.lib => wxmsw31ud_html.lib
wxmsw30ud_xrc.lib => wxmsw31ud_xrc.lib
wxbase30ud_net.lib => wxbase31ud_net.lib
wxbase30ud_xml.lib => wxbase31ud_xml.lib

After these changes I was able to build and run my old project, which was originally written for wxWidgets 2.8 and then ported to wxWidgets 3.0.

ModernMUD Source Now on Github

As dumb as the name might be, I decided to go with “ModernMUD”.

The source code is available on Github under the BSD license:

https://github.com/Xangis/ModernMUD

There’s a lot more to be done with documentation, but the XML comments are decent enough to make IntelliSense useful. I’ll probably be posting more about invidiual sections of the source, particularly the clients (all four of them!), in the near future.

If you’d like to chip in, or use the code to build your own MUD, you are more than welcome to do so.

I Am Addicted To Github

Until recently, the only code I’ve released as open source has been the Magma MUD codebase.

In the process of posting the Magma source on Github, I kind of got hooked on posting code online. Since then I’ve posted the source for a handful of applications, a mix of Linux and Windows desktop apps. A 12-day commit streak so far, yay!

I’m also considering open-sourcing the Basternae 3 codebase. The main things that make it easier to work with than old-timey C-based MUDs are the use of C#, which has amazing exception handling and debugging capabilities (no more attaching gdb to a core dump), and speaks XML natively, so data files are Human-readable, portable, fairly robust, and extensible. The editor is also getting to be pretty good.

To open source Bast3, I’d need to write a lot more documentation, and I’d need to “genericize” a lot of things that are specific to Basternae. It’d be a lot of work, but I think it’d be a fun project. The source is already in a private repository on Github, but that’s the easy part.

Using MonoDevelop

I’ve almost always used both Windows and Linux, but I stopped using Windows a few months ago.  One of the things that only runs on a Windows machine is Visual Studio.  The Basternae code was compiled on a Windows machine and then uploaded to the Linux host.

Without access to that, it was time to try using MonoDevelop.

MonoDevelop
It was able to load the Visual Studio solution, with some exceptions:  The client WPF project didn’t load, nor did the abandoned Silverlight project.  I could probably install more packages to make WPF work, I’m not sure yet.

I noticed that the compiler works differently for some things, like terminal characters.  The ECHO_ON and ECHO_OFF sequences broke logging in, but some weird prompt formatting that’s been around for a while just fixed itself.  It will be interesting to see what other diffferences turn up.  Even though C# is supposed to work the same on all platforms, I suspect that it might work better when both the build and run machines have the same operating system.

Win32 Visual Styles

Nothing to do with Basternae, this is just a reminder to myself how to enable the visual styles for controls available in Windows XP and newer in a WIN32 project in Visual Studio 2010.  Had to do this at work and it’s a little tough to look up.

1. Edit Project settings.
2. Under Linker->Manifest File edit “Additional Manifest Dependencies” and add:

type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*';%(AdditionalManifestDependencies)

Suddenly Win32 controls will stop looking like they’re from Windows 3.1.  The modern control styles were introduced in ComCtl32.dll version 6, and Windows apps use version 5 by default unless you tell them not to.

C#: Compiling For 32-bit Systems on 64-bit

I recently upgraded from 32-bit Vista to 64-bit Windows 7.  I may be one of the only people who didn’t have anything bad to say about Vista.  For me it was a huge step up from Windows XP, but since I have 6GB of RAM in my system it’s a little silly to run a 32-bit OS.

I understand the differences between 32-bit and 64-bit C++ code behavior quite well, but I really haven’t spent any time digging into the differences between 32-bit and 64-bit .NET IL code.  Apparently it’s all quite a bit simpler in managed code.

Just right-click on a project, click properties, click on the build tab, and then select “x86” under “Platform Target”.

Visual Studio 2010

Three months ago I switched from Visual Studio 2008 to Visual Studio 2010 as my main development environment.  Functionally it’s the same as it’s always been, but there are two things about it I consider great improvements.

First, the UI:  It looks so a lot better and cleaner than earlier versions.  It’s not that older versions were ugly, but it has a cleaner look and is much easier on the eye.

Next, C++ Development:  For the last few versions of VS, C++ developers have pretty much been shafted — no real feature improvements for the most part with all the love going to C#.  C++ received a major boost, gaining just-in-time compilation and error-detection intellisense almost exactly like C# has always had.  It doesn’t sound like a big deal, but it is excellent for speeding up the code-compile-fix cycle.

Only a small portion of Basternae code is in C++, just the client and the Basternae 2 to 3 zone converter, but it is a lot more pleasant to write with Visual Studio 2010.

This project started on Visual Studio 2003, so now we’ve been through four versions.

Basternae Code Now Stored With Assembla

Code versioning is a good thing. You can rollback changes that make things worse, compare current code to past code, keep backups, and access your code from almost anywhere. It also helps make sure that every machine being used for development is kept current and that changes aren’t easily overwritten. Any serious development should have a source code repository, especially if that development is done on more than one system or by more than one person. I’m only one person, but I used three different dev systems.

I’ve tried to set up a Subversion code repository at home twice. Both times it was on an extra laptop and both times the laptop’s hard drive died within a month of setting up the repository. I didn’t lose the code (every development machine is technically a code backup), but it was pretty frustrating.

The other day I signed up with Assembla for my audio software development and it’s been so useful that I’ve added the Basternae code too.

I’m debating whether to start using the Trac issue tracking system with Basternae 3. It works well for the Zeta Centauri projects, but the workflow here is far more organic and to-do-list based than issue-and-ticket based. I suspect the verdict will be “no” on Trac and I’ll keep using my got-it-done.com website to track Basternae.

A Better To-Do List: Got-It-Done.com

If you’ve explored this blog much in the past you would have noticed that I had a “to do list” published.  It wasn’t well-sorted, and not all that easy to edit.

Since much of what I do in life is todo-list-driven, I’ve always tended to fill post-its and notebook pages with lists of things I need to get done, lists of ideas, tasks, etc.  While I’m at work, I’ll think of things I need to do and jot them down on whatever scrap of paper is handy.  It helps me stay focused, but I tend to have quite a clutter of papers on my desk.

The perfect solution for me to get rid of some of the clutter and make these lists available to me in more places than just my desk is an online solution.  There are already a solid handful of sites you can use to do that, but I’m far too hardcore for my own good.

Instead, since I wanted to get more familiar with the Django web framework and the jQuery JavaScript library, I built my own online task management application.  It was fun, challenging, and immediately useful.  I’ve moved the Basternae to-do-list to it and make use of it for everyday organization.

It’s free to create an account, so feel free to try it if it’s something you might find useful.  Here’s a screenshot of it in action:

Got-It-Done Task List Screenshot

Check it out at http://got-it-done.com.  It’s pretty beta, so feel free to offer suggestions and/or let me know if you have any errors.

ReSharper 4.5: It’s Finally Awesome

The two of you who have been following this blog regularly probably know that I’ve tried demos of JetBrains ReSharper versions 3 and 4 in the past.  The verdict was that they were pretty neat, but far too slow to be of any practical use.

Today I downloaded the trial version of ReSharper 4.5.  The big improvement they claim to have made is a significant speed increase.  After trying it out, I believe it.  They claim speed increases of about 25-40% depending on the type of project you’re working on, but that’s an understatement.  I’m using the same hardware I used for the previous test a year ago (yeah I need an upgrade, but that’s not something I care to address right now).   I haven’t used stopwatch tests, but it feels like ReSharper 4.5 is easily two to three times faster than ReSharper 4.0.

It’s now totally worth using — it has all of the benefits without any of the drawbacks the previous versions had.  Good work, JetBrains.

Accepted Into Microsoft BizSpark

Microsoft has this neat little program, BizSpark, that gives a company free access to pretty much all of their products for three years for a total of $100.  The idea is that if they can get startups hooked on Microsoft operating systems, databases, and development tools, then if the companies are still alive after three years they’ll become thriving, paying customers.

Seems like a smart idea to me.  After all, startups generally have to be run “on the cheap”, so most of them turn to Linux and open source solutions.  BizSpark is keeping Microsoft competitive, helping out startups, and is an all-around good thing.

So, my company, Zeta Centauri, Inc., was just accepted into the BizSpark program and I now have access to all these neat development tools, including Visual Studio 2008 Team Suite (which is $10k retail).  It’s still downloading, but I’m sure I’ll have to post about some of the bells and whistles that come with it.  I’ve never worked with anything above Visual Studio Professional.   With any luck these new and shiny tools will help me build something awesome.