MWEdit

[Spastic Hamburger]

Okay, got that minor issue fixed. Had to add this to the Meson script:

add_project_arguments('-D_AFXDLL',
                      language: 'cpp')

Now that it’s using C++20 as the standard, it’s exposed a few other real code errors that I’m working on fixing. 🙂

Got one that’s an issue with the Windows API that I’m unfamiliar with:

../Common/Time/tasktime.cpp(231): error C2664: 'MMRESULT timeSetEvent(UINT,UINT,LPTIMECALLBACK,DWORD_PTR,UINT)': cannot convert argument 3 from 'void (__cdecl *)(UINT,UINT,DWORD,DWORD,DWORD)' to 'LPTIMECALLBACK'
../Common/Time/tasktime.cpp(231): note: None of the functions with this name in scope match the target type

Here’s the line it’s crapping out on: https://github.com/deathssoul/MWEdit/blob/meson/Common/Time/tasktime.cpp#L231

After doing some looking, that file may not be needed anyways so I’ve temporarily commented it out of the build script which fixed that issue as it’s no longer trying to compile it. Still working through the updates to the code. The old project file was using the C++14 standard but C++20 is much better. Also stricter, which is why there are a lot of kinks to work out.

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

[DeVaultSetter]

Have you set up Ninja with Meson?
https://stackoverflow.com/questions/69334227/how-can-i-setup-meson-and-ninja-on-ubuntu-linux-to-produce-the-expected-a-file
It expects MFC? See:
https://stackoverflow.com/questions/75984893/how-to-include-mfc-in-a-cmake-ninja-project-build-with-visual-studio-2019
Edit: Ninja’d!

• This reply was modified 3 weeks, 1 day ago by DeVaultSetter.

[Spastic Hamburger]

I’ve temporarily turned off all of the extra warnings until we get things working.

New issue! This has to deal with the message maps that the MFC API uses. It’s complaining about bad casting even though it works in the VS project files, just not the Meson script so I suspect there’s a setting in there that may need to be transferred over as well. Any ideas on that? Here’s the error I’m looking at
Yep, the CI script is fully set up to work with Ninja and VS 🙂
meson setup --buildtype release --vsenv build
That’s where we tell it which back-end to use. I can also tell it to use MSBuild instead of Ninja but it looks like Ninja is working and the issues have to do with missing some special overrides that were done twenty years back.

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

[DeVaultSetter]

Upvoted this answer as it looks like the solution – looks like VS has been rather kind. 🙂
Wouldn’t harm to check references of LPTIMECALLBACK to see if it is used correctly.
Cool, yes, looks like bouts of teething pain between the approaching tombmilestones from up ahead! 😛

[Spastic Hamburger]

So it sounds like there’s a switch being used for MSVC to relax the casting rules for C++. Sorry, things are still coming back to me but I’m getting there. 🙂

Would be better to fix it manually, anyways, so I guess I’ll fix up the required casts for now. Was hoping to do them later but, hey, it’s all part of improving the code quality. It’ll also help with getting it ready for cross-platform support as compilers on Linux are extremely strict. 🙂

What does the message map do, anyway? The documentation I found on MSDN on the block didn’t link to an explanation of what a message block is in the context of MFC

Eventually, I hope to replace much of the time functions with those from ctime but there may still be some OS specific stuff needed. Right now, that class isn’t used in the program so it’s a likely candidate for removal at some point after we get the basic changes done for building.

We can definitely add it to the issue tracker, though. 🙂

Who knows? We may find a use for some of the miscellaneous capabilities of the common support library down the road

I’ll flip on all of the warnings after we get the build working to help us with compiling our list of stuff to fix. May be worth rerunning cppcheck and cpplint, too. Afterwards, we may want to get the stuff added to the issue tracker by warning type to help keep everything in one place. Up until now, most of the work has been related to updating the style, syntax, and infrastructure but once the build script is working, that’ll unlock capabilities that we didn’t have before. We’re definitely getting there! 🙂

I’ll update the threads tomorrow with an update on where things stand with the build script 🙂

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

[DeVaultSetter]

Message maps in MFC are covered here:
https://stackoverflow.com/questions/49383622/an-explanation-of-message-maps
In a nutshell MFC does away with the message switches and makes them typed. Probably a good idea for many, here the tendency was to stay with the “native” C++ stuff. 😛
Sounds good – ctime looks nice, the hard bit will be to figure out what David’s plan with time actually was. Other than spending much of it away from Morrowind. 😛

[Spastic Hamburger]

Thanks. 🙂

Ultimately, they’ll be swapped out when we switch GUI toolkits but we can revisit things then 🙂

Looked at it more closely and ON_WM_TIMER() is supposed to map to an UINT_PTR while the code is trying to use just UINT. Probably a change in MFC signatures at some point over the last couple of decades. That fixed that error when I changed the type. Got some more, which isn’t unexpected. It was able to work through 92 files this time so we’re definitely getting closer. There will be more const types to correct but I’ll let it point me to them so I don’t have to go on a treasure hunt 🙂

Yeah, I’m not entirely sure what all of the stuff in Common is for. It could be for other projects totally unrelated to the community as I haven’t seen it used anywhere else. With the time stuff, he’s using it to profile stuff in debug mode and in general in the script compiler but those all use dl_time instead. Lately, he’s pretty focused on admin duties at UESP but does update the Edit code from time to time for compatibility. He even added some stuff to it for Starfield in a separate repository. 🙂

Edit:

We’re getting some pointer truncation warnings in project/mwrecordmap.h that are annoying to see in the log so I’ll look at fixing them up at some point. Just tired of seeing them 😛

Still working through compatibility errors. It’s also caught some missing includes, which is nice. Once it’s building, I’ll clean things up a tad before squashing the commits and merging 🙂

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

[Spastic Hamburger]

Okay, almost got it. Now we’re left with some linking logs after the obvious source issues have been taken care of:

[198/198] "link" @MWEdit.exe.rsp
FAILED: [code=1120] MWEdit.exe 
"link" @MWEdit.exe.rsp
project_EsmUtils.cpp.obj : error LNK2005: "void __cdecl FindMWRegistryPath(void)" (?FindMWRegistryPath@@YAXXZ) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "char const * __cdecl GetMWDataPath(void)" (?GetMWDataPath@@YAPEBDXZ) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "void __cdecl SetMWDataPath(char const *)" (?SetMWDataPath@@YAXPEBD@Z) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > l_MWDataPath" (?l_MWDataPath@@3V?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@A) already defined in esm_EsmWinUtils.cpp.obj
project_EsmIconFrame.cpp.obj : error LNK2019: unresolved external symbol __imp_ilutWinLoadImage referenced in function "public: void __cdecl CEsmIconFrame::SetEsmIcon(char const *,bool)" (?SetEsmIcon@CEsmIconFrame@@QEAAXPEBD_N@Z)
project_MWEdit.cpp.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function "public: virtual int __cdecl CMWEditApp::InitInstance(void)" (?InitInstance@CMWEditApp@@UEAAHXZ)
..\IL\DevIL.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
..\IL\ILU.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
..\IL\ILUT.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
MWEdit.exe : fatal error LNK1120: 2 unresolved externals

Will take a look at those later. The DevIL errors are expected as the repo bundles in the 32-bit DLLs when we’re using 64-bit. Not entirely sure how to go about that. I may need to tell the CI to build the 64-bit version of DevIL. The rest, I’m not sure about at the moment. Will need to look at them later. It sounds like it’s missing an include guard, though

Edit:

Just realized what the duplicates are about: just that, they’re defined several times. Made a mental note a while ago but it didn’t click until just now. If they’re the same, we’ll remove one. Later on, namespaces will keep this sort of thing from happening again. Will fix when I’m back to the computer

Not sure about the other two, those look like issues with the image library. Will take a closer look

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

[Spastic Hamburger]

Okay, esm/EsmWinUtils contains only a few things and they’re duplicates of those in project/EsmUtils. The latter is used more often so I’ve commented out the stuff in the former. Not going to delete it just yet as we may change up the structure once things are working but I’ll go ahead and add the two files to the dead code review issue.

Not sure about the other errors right now with the unresolved symbols in the image library (the grep results say that they’re all there) but I’ll need to take a look at them another day. I need a bit of a break 🙂

Looks like those unresolved symbols are the last errors to sort out, though

Edit:

Looks like we may need to add the DLLs to the build script.

Meson doesn’t have a clean way of linking to provided libraries. That’s going to be a tad annoying in the future. Will keep investigating to see what the best way of doing it is. It’ll get figured out. May just go better when I’m not so tired 🙂

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

[Spastic Hamburger]

Still banging about. There’s not much about how to link an included binary. When I thought I figured that out, Meson then complained that it wasn’t running under a VS environment even though it was running in a VS environment….

So I changed the backend to use VS as an experiment and then Python crapped out with missing file errors. You can see that one here.

At this point, I think I need to file a bug report and see what the Meson devs have to say.

Edit:

Opened.

In the meantime, progress is pretty much stalled

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

[Spastic Hamburger]

Progress on MWEdit is currently on hold as I wait to see if the Meson devs can help with the issues. If we can’t get Meson working, I’ll go ahead and use CMake. It isn’t as user friendly but it’s more mature so it should work better. I’ll give them a good week or so to get back to me before I start re-learning how to use CMake

[DeVaultSetter]

Might be an idea to include the meson.log in the issue as done here. There’s a couple of other issues similar: Regenerate build.ninja fails on Windows when using MSVC and Fail to find ninja when meson install with VS15 environment.

[Spastic Hamburger]

So that error is now gone even though it was showing up all the time the other day and I didn’t change anything in the build script. Meson didn’t get an update either. Looks like an obscure parsing bug.

No idea how to upload the log. Added the upload commands to the action file but apparently it stops the run at the first error so I’m unable to generate it from the CI.

Edit:

Got the log file. Was looking in the wrong spot. And got it uploaded. I’ll review it shortly!

End Edit

Now we’re back to figuring out how to link DLLs to the executable in the build script. There’s zero documentation on this and nothing I’ve found online works 🙁

With CMake, it’s as simple as this. I have yet to determine how to do it in Meson….Will get back to seeing if I can dig up the answer. If I can’t figure it out, we’ll probably need to switch to CMake as at least I know I can likely get it working in it. I’m starting to get a bit frustrated with trying to make Meson work

As near as I can tell, the Meson script is properly set up. :/

There may be something else going on. It looks like the other DLLs are being linked. At least, I think so. It’s complaining about those two specific symbols for some reason. Currently investigating and doing some trial and error. It’s also possible that the more stringent compilation commands are breaking something due to some bad DLL data. In which case, we’d need to rebuild the DevIL libraries. Unfortunately, NimrodPSI didn’t include any documentation or build scripts for those changes. We may need to totally overhaul how the build system uses DevIL. We’ll need to change things anyways for better 64-bit support

For reference, here are the errors:

[198/198] "link" @MWEdit.exe.rsp
FAILED: [code=1120] MWEdit.exe 
"link" @MWEdit.exe.rsp
project_EsmIconFrame.cpp.obj : error LNK2019: unresolved external symbol __imp_ilutWinLoadImage referenced in function "public: void __cdecl CEsmIconFrame::SetEsmIcon(char const *,bool)" (?SetEsmIcon@CEsmIconFrame@@QEAAXPEBD_N@Z)
project_MWEdit.cpp.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function "public: virtual int __cdecl CMWEditApp::InitInstance(void)" (?InitInstance@CMWEditApp@@UEAAHXZ)
D:\a\MWEdit\MWEdit\IL\DevIL.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ilu.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ilu-l.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ILUT.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
MWEdit.exe : fatal error LNK1120: 2 unresolved externals

And here are the grep results for those two symbols:

$ grep --recursive --line-number "ilutWinLoadImage"
IL/ilut.h:212:		ILAPI HBITMAP ILAPIENTRY ilutWinLoadImage(const ILstring FileName, HDC hDC);
grep: IL/ILUT.exp: binary file matches
grep: IL/ILUT.dll: binary file matches
grep: IL/ILUT.lib: binary file matches
project/EsmIconFrame.cpp:142:		hBMP = ilutWinLoadImage(FileBuffer, pDC->GetSafeHdc());
project/EsmIconFrame.cpp:144:		hBMP = ilutWinLoadImage((char *const)pFilename, pDC->GetSafeHdc());

And:

$ grep --recursive --line-number "ilInit"
grep: IL/DevIL.exp: binary file matches
IL/il.h:528:ILAPI ILvoid ILAPIENTRY ilInit(ILvoid);
grep: IL/DevIL.dll: binary file matches
grep: IL/DevIL.lib: binary file matches
project/MWEdit.cpp:320:	ilInit();

If we were to enable Unicode support, that would change the first error slightly. ILstring becomes a wchar when _UNICODE is defined:

#ifdef _UNICODE
	#ifndef _WIN32_WCE
		#include <wchar.h>
	#endif
typedef wchar_t *ILstring;
#else
typedef char *ILstring;
#endif //_UNICODE

TCHAR is a typedef of wchar, as I recall, so things may work differently.

Regarding the second symbol, I’m not sure. ilInit() looks like it’s being used properly.

I’ll try reaching out to NimrodPSI via email to see if they can shed any light on the DLLs they built.

The Meson log is also complaining about the install script but we’ll worry about that later. That’s minor in the scheme of things. Worst case scenario, we simply write a shell script or something.

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

[Spastic Hamburger]

Okay, I’ve reached out to NimrodPSI. If they’re unable to assist, I’ll go ahead and work on a CMake script so that we can at least rule that out of the equation.

[DeVaultSetter]

These are the DevIL dll’s discussed back here? The ~2016 version had a different build method which might be better. Just start a new VS project and compile it might be a thing, ensuring all the functions in exports check out.
Another idea is ResIL, looks like it is still being updated with support. 🙂

[Spastic Hamburger]

Yep, those are the ones. The issue lies with the shared library .lib files. Yeah, will try switching to ResIL at some point. We’ll want to make sure everything is updated, anyways. I don’t know if Meson has an option to do this (will check later) but CMake has a command to download files, which could be helpful.

Unfortunately, I no longer have a Windows install so everything is being done via the CI. At least, on my end. I dropped Windows a few weeks back as it didn’t like my fan controller so I’ve only got access to Linux now.

• This reply was modified 1 week, 6 days ago by Spastic Hamburger.

[DeVaultSetter]

Linux may have a problem with dll’s? See for example:
https://stackoverflow.com/questions/2538635/possible-to-use-a-dll-on-linux

[Spastic Hamburger]

Linux shouldn’t be affecting the build as the CI is set to run Windows Server 2025

[DeVaultSetter]

Oh cool, so NimrodPSI used Meson to build DeviL at some stage? The DeviL docs do say:

CMake is used to handle building DevIL across multiple platforms.

See README.cmake for details.

See what you mean – I’d rebuild them all to x64 machine, else there’s a world of pain ahead. 🙂

• This reply was modified 1 week, 6 days ago by DeVaultSetter.

[Spastic Hamburger]

I’m actually not sure how they built the libraries since they didn’t provide any documentation on it. From the looks of things, they intended the build setup to be immutable and assumed 32-bit, which was a bit unusual in 2020. For context, I dropped 32-bit support for BOSS back around 2015 or so. Hopefully they respond to my email 🙂

For decoupling the bundled libraries, we could take a look at the list of included tools here. The Linux script will be much easier for me to manage when we get there but, for now, we should be able to use the included Git command to download everything. As for how to handle checking out stable versions, that’ll require some thinking. Could probably use a dependencies file that we parse or something but ResIL appears to just use a main branch. I’ll need to clone the repository to see if it may just be a limitation with the Sourceforge interface

Oh, neat. They provide a MacOS image so we’ll be able to build for Mac without paying the developer fees. Won’t be able to host it in the App Store without an account but users should still be able to use it

• This reply was modified 1 week, 6 days ago by Spastic Hamburger.
• This reply was modified 1 week, 6 days ago by Spastic Hamburger.
• This reply was modified 1 week, 6 days ago by Spastic Hamburger.

[Author]

Posts