[Spastic Hamburger]

Yep, changing the include order fixed it. Going to need to fix the rest of the places where it shows up. Give me a bit.

We’ll want to fix things up at some point to make sure that we don’t run into this problem again. The fix isn’t pretty but it’s a temporary solution until the refactoring is further along.

We’ll want to move the string functions to common/dl_str.h as they use symbols from that file. common/dl_base.h cannot include that file because common/dl_str.h requires symbols from common/dl_base.h in order to function. I guess I could include it at the very end of common/dl_base.h, though. Essentially, the work on the includes has exposed a couple of circular dependencies that were already in the code. This will take some time to fix. Messy, messy, messy.

I’ll update the community threads when I get the chance

• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Edit:

Ignore the post! The include order is messed up in the base file. The preexisting spaghetti code threw me for a loop earlier: it doesn’t set up the definitions until after it tries to include the files that need them in the same file that defines them. Why I didn’t see it before is beyond me. Fixing now.

End edit!

Yep, CMake is correctly setting things up properly:

Run mkdir builddir; cmake -G "Visual Studio 17 2022" -B builddir
  mkdir builddir; cmake -G "Visual Studio 17 2022" -B builddir
  shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"

    Directory: D:\a\MWEdit\MWEdit

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----           3/28/2026  7:47 AM                builddir
-- The C compiler identification is MSVC 19.44.35225.0
-- The CXX compiler identification is MSVC 19.44.35225.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for MFC
-- Looking for MFC - found
-- Could NOT find DevIL (missing: IL_LIBRARIES ILU_LIBRARIES IL_INCLUDE_DIR) 
-- Configuring done (21.0s)
-- Generating done (0.0s)
-- Build files have been written to: D:/a/MWEdit/MWEdit/builddir

And
MSBuild version 17.14.40+3e7442088 for .NET Framework

Here’s the new log file after that playing about with the conditionals: https://github.com/deathssoul/MWEdit/actions/runs/23680640909/job/68991840433

Didn’t seem to change anything.

This would be easier to diagnose using a local VS install but my system is no longer able to run Windows.

I added the _WIN32 macro to the definition list in CMake to no avail. I have no idea what’s going on. It was working before I added the includes so that operation clearly broke something.

• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Fixed it! For some reason, MSVC wasn’t bringing in tchar.h from common/dl_base.h. I added #include <tchar.h> to common/dl_str.h and the error went away. Looking at the new error log, it looks like _WIN32 isn’t being brought in from MSVC for whatever reason even though it’s a compiler level macro. That should be easy enough to fix: I’ll just add it to the definition list in the build script. Could be a bug in MSVC or whatever but we can easily deal with it 🙂

That said, we now have two options: add tchar.h to all the files (my preference as it makes things clear that we’re using the header) or leave it in common/dl_base.h. It should be noted that the latter option won’t work on non-Windows systems anyways even if it is in an OS level check due to this line:
#define _stricmp(string1, string2) stricmp(string1, string2)
stricmp() is a Windows extension to string.h and isn’t in the standard (there is a similar function in the C++ standard, std::strcmp(), that provides a slightly different comparison value so we can swap out the function easily enough temporarily) so we’ll need to rewrite all of the Unicode handling anyways for cross-platform support once we get there. We can leave it in for now but we’ll just have to remember that we’ll need to change things.

The complaints about the boolean types are because they’re in a _WIN32 check, which is broken for whatever reason. That said, those need to be swapped for the standard boolean keywords, bool, true, and false anyways (which are treated as type int so should be fine to swap in) for portability.

If that plan sounds good, I’ll start work on the fixes in the next few days 🙂

• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Where do you see the error about the missing main() function? I missed that. I never did figure out how things were working without WinMain()

It is missing the Run() function and is supposed to use the inherited one instead. I noticed it during the initial audit a year ago but I don’t think I put it on the tracker. Sorry about that. It’ll need one or the equivalent anyways for GTK support since it does things in a standard C++ way. Will look at the structure of it and will probably have questions about it 🙂

Will also try the stdafx.h file and see what happens 🙂

We knew going in that the cleanup would break most everything until completion so I’m not all that worried. Most of what’s broken is the Windows code. The rest remains intact 🙂

Though, why adding the needed includes would cause this issue is beyond me when things were working before. I’ll take another look at the previous log file from before I added the offending header and see if it has any additional insight.

• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 4 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

The syntax error may or may not be there. Oftentimes, during an error, the compiler craps out and spits out bad data after the initial error so it’s very hard to debug things all at once. C++ is a lot more type safe than C and requires that you specify the return and parameter types everywhere 🙂

I was getting that error in common/dl_str.h for the parameters so it sounded like TCHAR wasn’t being brought in for whatever reason, even though it was being set in common/dl_base.h through a Windows macro check. That’s when I tried adding the Windows header winnt.h to it to see if that fixed the issue. According to Microsoft’s list, that’s the header we want.

Sounds good. Let me know what you find out 🙂

We do have options, fortunately, but let’s see what you come up with before we start considering the other alternatives 🙂

• This reply was modified 2 months ago by Spastic Hamburger.

[Spastic Hamburger]

Something’s broken with the TCHAR implementation: https://github.com/deathssoul/MWEdit/actions/runs/23533305041/job/68502145150

It started by complaining about the TCHAR typedef in common/dl_str.h not being a type so I added the winnt.h header to it since the typedef wasn’t being picked up from common/dl_base.h (probably being overridden somewhere in the spaghetti code) and then it started complaining about the system header itself.

I’ll set it aside for right now but any ideas? It was building before so one of the overrides is borked. I could try narrowing it down by removing the redefinition from common/dl_base.h or even making it a global typedef in a new namespace and adjusting the type in the project (will take a while but should fix it).

That said, we do have a task item to switch over to proper Unicode handling anyways but I’m not exactly ready to tackle the conversion between character encodings as OpenMW differs from regular Morrowind

• This reply was modified 2 months ago by Spastic Hamburger.

[Spastic Hamburger]

game/morrowind/sub_name_fix.h is currently set up to only be a typedef to CEsmSubName. That’ll need to be investigated to see if the disabled code needs to be used at all. If not, we can remove the file and remove the includes and symbols referencing it.

[Spastic Hamburger]

Yeah, we’ve been really dry too. Several of our creeks have completely dried up!

The critters certainly looks happy! 😀

In Futurama, we have Parade Day!

The International Day of Forests doesn’t get much press over here: we mostly do Arbor Day and Earth Day.

Wasn’t aware of World Frog Day. I have noticed a decrease in the ribbits around here in recent years. They used to get loud!

And some interesting discoveries in the quantum world just came in: https://phys.org/news/2026-03-blur-reverse-quantum.html

Haven’t had a chance to read the full paper yet but definitely need to make the time for it

[Spastic Hamburger]

There are also foilboards in addition to jet boards. They look a bit top-heavy!

My favorite is the VW Bug with a jet engine: https://www.craigslist.org/about/best/sfo/7241823593.html

Bring your own wings, though!

Feel like going out in the snow in style? Take a Snow Cat!

Lots of automobile related posts in the “Best of…” list. How about a smoker if you get hungry?

This looks like it’ll definitely liven up a good shopping trip but definitely not safe 😛

[Spastic Hamburger]

Things are moving right along. I hit the game/morrowind/ directory the other day so we’ll be able to do another test build soon. Once the push is done, we’ll see if anything else needs to be fixed to get things working without using the windows.h header.

Any luck with getting VS up and running?

It’s possible things will build on MinGW now (or at least soon if they don’t already) so that’s something worth testing at some point. I’ve checked off everything that was on the list, at least. Further investigation revealed that the markers that I thought were generated code markers were in fact markers telling you that that code was stuff generated by the Class Wizard and they’re needed to properly use the Class Wizard. Since we’re working with the code instead, we’ll be able to remove those artifacts without issues (I think) and make the code more readable with less clutter in the way.

I’ve also added notes about non-standard extensions that we’ll want to swap out for portable functions. I’ve also already swapped out a few of them where they were relatively simple.

I’m also exhausted 😛

• This reply was modified 2 months, 1 week ago by Spastic Hamburger.

[Spastic Hamburger]

I once had the idea of playing a roar on a speaker system by the front door for fun, triggered by a motion sensor. Never did follow through with it 😛

[Spastic Hamburger]

I’m partial to grey or aluminum cases myself. They’re really good about not being obtrusive. While nice to have a window to read the error codes on the motherboard without having to open things up, I’m not overly picky about such a feature 😛

Haven’t seen that feature on a microwave before. Mine just blows the circuit when it goes too long and it’s from 2015 or 2016 😛

Looks like keyboards are moving towards magnetic switches from membrane and mechanical. I wonder how they’ll compare in terms of comfort. My mechanical SteelSeries keyboard is very pleasant to use.

[Spastic Hamburger]

Most of the debug functions in common will go away as they longer serve a purpose. All they do is test the existing functions to make sure they work with set data. Looks like they were used for checking to make sure the code was correct during initial development. Since they only check pre-defined data instead of checking for current, they’ll either be rewritten or removed. That and they add a lot of reads and writes to the drive for no gain.

[Spastic Hamburger]

Yeah, I wasn’t able to come up with much either. For some of the other problems, there were some open issues but no feedback on them.

Thanks, will try that soon. 🙂

Also going to try messing with the Proton settings to see if that helps when I’m not so tired. Don’t want to risk messing anything up!

[Spastic Hamburger]

Some interesting insight here regarding the RGB trend: https://news.ycombinator.com/item?id=47375085

Personally, I avoid it when possible as it tacks on about 10 to 20 USD for each item that uses it for a feature I’ll never see. My keyboard lives in a tray, my mouse is always covered (why it needs lighting when your hand covers it is beyond me), my case is solid…. 😛

• This reply was modified 2 months, 1 week ago by Spastic Hamburger.

[Spastic Hamburger]

As I mentioned elsewhere, PopOS was updated the other week with COSMIC and Wayland as the defaults. Things haven’t exactly been going swimmingly. There are a few bugs in the combination, such as screen flickering after the display gets blanked by the power settings. The fix is to log out and back in again. Additionally, mouse scrolling in the pager doesn’t work properly in the terminal emulator and the overrides are ignored.

Those are relatively minor, however. The biggest issue I’m noticing is that I can’t get games working right. The Witcher doesn’t load properly at all and Workers and Resources runs but not in fullscreen and the mouse only maintains focus for about 75% of the interior of the window, making it unplayable regardless. No Man’s Sky doesn’t load at all from what I can tell.

I’ll need to poke at things later on, see if there’s a way to get things working properly.

• This reply was modified 2 months, 1 week ago by Spastic Hamburger.

[Spastic Hamburger]

I’m going to set common/dl_base.h aside for now as it’s hard to tell if the string macros are coming from Microsoft’s string library or the standard as they lack the leading underscore. I’ll take another look at them after I’ve gone through the rest of the files.

[Spastic Hamburger]

I’m working on contacting the xEdit folks for information. As with most of these projects, discussion has, unfortunately, moved almost exclusively to Discord. Would prefer a more public platform but I’ll copy the information here once I get it

I wish I didn’t need to use Discord like this: it’s getting to be a bit much to manage. 🙁

Probably going to pare it down once I get information. Trying to keep track of everything going on with the various chat servers is driving me nuts!

• This reply was modified 2 months, 2 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Wonderful! If I ever get to New York, The Met is high on the list of places to visit. 🙂

We’ve had a few cases of flesh-eating bacteria here. Not many, admittedly, but enough to warrant some concern.

Had this come in the other day: https://www.theregister.com/2026/03/08/neurons_doom/

[Spastic Hamburger]

common/file/gen_find is written to be partially cross-platform. It does have _WIN32 checks for some of it but it still breaks on non-Windows platforms as the required typedef is itself in a check. I’ve made a note of the problem in the code.

Several functions in common/string/sstring.h have no prototype, just definitions. Most of these are duplicated in windows/win_util and defined in there. The CSString:: versions aren’t used from what I can tell so we can likely remove them from the header to clean it up. That’ll be done once I’ve checked each function to make sure we can excise them.

Many things in common are aliases to stuff in the Windows API with the exact same name so we’ll definitely want to namespace these to prevent confusion. I’ve tried to clean up what I accidentally though was from the Windows API but were in reality aliases but there’s a good chance I missed some stuff.

Edit:

Fixed a few bugs in common/string/sstring.cc. There were some misnamed variables that didn’t match the prototype and, instead, referenced the typedefs. All fixed now 🙂

A lot of the string stuff is weird so I fully expect it to croak, if not on build, then on certain extended characters. It’ll be better once the string library has been rewritten to modern compliance. That doesn’t necessarily require the Unicode tracker item to be done but does require consistency in the code.

Also, one task that needs to be accomplished at some point is rearranging the source files to match the order of the headers.

Edit 2:

common/time/task_time.cc has more DOS code that needs to be removed. It uses weird macros, though, so those will need to be untangled first to make sure it’s done correctly.

Doesn’t look like that file or symbols are used in the project anyways so I’ll go ahead and tag them for removal. Going to clean them up first, anyways, just in case they’re needed after all but the grep came up empty:

~/projects/MWEdit$ git grep --files-with-matches  "TaskTimer"
common/time/task_time.cc
common/time/task_time.h

common/utility/profile can likely be marked for removal:

~/projects/MWEdit$ git grep "ProfileLog"
common/utility/profile.cc:      CLogFile ProfileLog;
common/utility/profile.cc:      //boolean  OpenLog = ProfileLog.Open("profile.log");
common/utility/profile.h:extern CLogFile ProfileLog;
~/projects/MWEdit$ git grep "profile_t"
common/utility/profile.cc:      extern profile_t *g_pLastStaticProfile = NULL;
common/utility/profile.h:       profile_t ProfName = {{0ul}, {0ul}, {0ul}, 0.0, {0ul}, 0.0, {0ul}};
common/utility/profile.h:       static profile_t ProfName = {{0ul}, {0ul}, {0ul}, 0.0, {0ul}, 0.0, {0ul}}; \
common/utility/profile.h:} profile_t;
common/utility/profile.h:extern profile_t *g_pLastStaticProfile;
common/utility/profile.h:       profile_t &m_rProfile; /* Referenced profile object */
common/utility/profile.h:       CProfileEndFunc(profile_t &Profile) : m_rProfile(Profile) { ; }

• This reply was modified 2 months, 2 weeks ago by Spastic Hamburger.
• This reply was modified 2 months, 2 weeks ago by Spastic Hamburger.
• This reply was modified 2 months, 2 weeks ago by Spastic Hamburger.
• This reply was modified 2 months, 2 weeks ago by Spastic Hamburger.
• This reply was modified 2 months, 2 weeks ago by Spastic Hamburger.
• This reply was modified 2 months, 2 weeks ago by Spastic Hamburger.
• This reply was modified 2 months, 2 weeks ago by Spastic Hamburger.

[Author]

Posts