MWEdit

[DeVaultSetter]

*pID is the address of the first char in string, *pID + 1 the address of the second char in string and so on.
With the const decl *pID is a pointer whose contents cannot be changed – once set of course. 😛
Will do. 🙂

[Spastic Hamburger]

Great, thanks. Been forever since I had to worry about pointer arithmetic 😛

Probably should grab my old C textbook that’s on the bookcase as a refresher 🙂

Edit:

`ui/ directory is done and processing. Going to update the system as a large update just landed yesterday. 🙂

Since we’re not using windows.h, it looks like we’ll need to set the architecture manually for some reason. Shouldn’t need to but I’ll add a note that _AMD64_ needs to be set in the build script for winnt.h.

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

[DeVaultSetter]

Yeah, pulling out windows.h is known to cause some pain! 😛
Just remembered too, that those iscsym functions will have to be replaced with the wide char version iswcsym if building unicode, and of course, being windows specific functions, directives apply. Sigh. What’s the cross platform equivalent of those I wonder?

[Spastic Hamburger]

We’ll get it figured out! It is weird that TCHAR is in winnt.h instead of something more sensible like tchar.h. The latter has support functions but TCHAR itself is elsewhere. Maybe I need to clean up the Windows API as well (not happening! Too much work!)? 😛

Yeah, Unicode will be a tad hairy due to inconsistent support. I remember that with BOSS, it took a ton of trial and error to determine what was Unicode compliant but support has improved immensely since then. The existing code doesn’t use the wide-character versions, either

In the main standard, we have cwctype and cctype for UTF-8. As we know from prior investigation, wchar_t is implementation defined and thus not portable. There doesn’t exist equivalents for UTF-16, I don’t think, but I’ll need to do some more digging to make sure. We’ll also want to check to see what’s supported by the in-game engine for the in-game text.

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

[Spastic Hamburger]

Unicode tracker item updated with more information courtesy of the OpenMW folks 🙂

[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 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.

[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 1 month, 2 weeks 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]

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]

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 1 month, 1 week 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]

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 1 month ago by Spastic Hamburger.

[DeVaultSetter]

Looks like it doesn’t like default_int either.
There’s a suggestion as per this post. There’s a syntax error followed by a bunch of others:

C2146: syntax error: missing ‘;’ before identifier ‘WCHAR’

Could be windows.h related as well – further investigations on-going.

[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 1 month ago by Spastic Hamburger.

[DeVaultSetter]

Looks like it isn’t seeing a main at all- give this a shot: #include main_frm.h in stdafx.h and see how it goes.

[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 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.

[DeVaultSetter]

It’s the default_int error mentioned above. It’s the very first error the compiler emits when it is “parsing” the entry point, although it’s only level 1, which can be turned off.
The second error is because windows.h is absent, #include <wchar.h> may resolve the issue. Hopefully. 🙂

[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 ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.

[DeVaultSetter]

Just paranoia, are we absolutely sure MSVC compiler is detected?

if(MSVC)
message(STATUS “MSVC compiler detected. Adding specific flags.”)
# Blah target_compile_options(MyApp PRIVATE “/EHsc”) # Enable standard C++ exception handling
elseif(${CMAKE_CXX_COMPILER_ID} MATCHES “GNU”)
message(STATUS “GNU compiler detected.”)
# Add GNU specific flags here
endif()

MSVC is supposed to define _WINDOWS internally or something – can you tell if that is working A_OK?
Edit: Sounds silly, but version checking for MSVC might go as:

if(MSVC)
message(STATUS “Microsoft Visual C++ compiler detected.”)
message(STATUS “MSVC version: ${MSVC_VERSION}”)
message(STATUS “MSVC toolset version: ${MSVC_TOOLSET_VERSION}”)

# Example: Require a minimum version
if(${MSVC_VERSION} VERSION_LESS 19.10)
message(FATAL_ERROR “MSVC version older than Visual Studio 2017 (v15) is not supported.”)
endif()

# Example: Apply specific flags for a certain version
if(${MSVC_VERSION} VERSION_GREATER_EQUAL 19.28)
# Code to handle features available in newer VS 2019 versions (16.8+)
add_definitions(…)
endif()

Just in case of an issue with _AFXDLL, also try adding the following in the mfc section maybe before the PUBLIC _AFXDLL bit:

add_definitions(-D_AFXDLL)

More paranoia – although you are sure to have covered most of this stuff: VS is configured to “Use MFC in a Shared DLL”?
Not sure – if std_afx.h is used with underscore instead of stdafx.h, it must be configured as so in VS Precompiled headers section.
Also in the stdafx.h, specify the versions of Windows required for MWEdit with _WIN32_WINNT – e.g. W10.11: 0x0A00

• This reply was modified 1 month ago by DeVaultSetter.
• This reply was modified 1 month ago by DeVaultSetter.

[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 ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.

[Author]

Posts