Compile fixes

[csware]

Ref. issue #178

[ProgerXP]

Thank you for this. We will review it.

@cshnik Review it too and comment if something is off. The end goal is to make it compiling on any combination of x86/x64/Release/Debug, including tests (all projects in the solution), and using more uptodate settings than came from Notepad2. And it should still run on XP x86 SP3/x64 SP2.

[cshnik]

In my tests _M_IX86, _M_AMD64 macroses are excess and does not affect the build process. These are Microsoft-specific predefined macroses: https://msdn.microsoft.com/en-us/library/b0084kay.aspx. I assume we can completely get rid of them.

[csware]

I kept it as this was also explicitly set in the old version. Won't hurt.

[cshnik]

_M_IX86 macro caused x64 build to fail. In your configurations it was replaced with _M_AMD64. However there is also a direct alternative _M_IX86 (x86) for x64: _M_X64.
Are there any thoughts why should we retain any of these in renovated configurations?

[csware]

_M_IX86 is not set for x64 builds (it was, but now it isn't any more)!

[csware]

_M_AMD64 is used in version.h

[cshnik]

_M_IX86/_M_AMD64 are the predefined compiler macros which should not be explicitly defined in the project options. File version.h is used to define data shown on the binary details tab and in the application's about dialog; currently, "x64"-postfix depends on the _M_AMD64 macro.
The actual problem here is that resource compiler (RC) know nothing about the compiler provided macros which in its turn requires to directly define _M_AMD64 in the project to allow RC generate correct data.
Since your fixes for x64 are already large I offer to include an additional fix for this case to make project smooth and clear.

1. Get rid of compiler flags _M_IX86/_M_AMD64
2. Add _WIN64 definition for x64 configurations
3. Adjust version.h: replace _M_AMD64 with _WIN64

Does it sound reasonable?

[csware]

_WIN64 is also automatically added by the compiler, so no need for this to add manually.

[cshnik]

_WIN64 is also automatically added by the compiler, so no need for this to add manually.

The actual problem here is that resource compiler (RC) know nothing about the compiler provided macros which in its turn requires to directly define _WIN64 in the project to allow RC generate correct data.

[csware]

Ah, I see, your point 2 was for the resource compiler and not the PreprocessorDefinitions

[csware]

Why still support WIndows XP? XP ran out of support several years ago, it's kinda dangerous to run it.

[ProgerXP]

Why still support WIndows XP? XP ran out of support several years ago, it's kinda dangerous to run it.

Running an unpatched (that's what you mean by unsupported?) OS may or may not be more dangerous than running latest Win7/8/10, it depends on the user. It's like saying that having antivirus installed will protect you from all threats (so far they have failed in preventing even major epidemics).

Then again, the POS version of XP is supported until next year (or maybe they have prolonged it again?). And security there is probably even more important to MS then security of its desktop OSes so I get it should be still providing all the security patches...

Speaking seriously though, I still reasons to support XP: there is a good number of people running it on older machines (it still has a decent Firefox version available, among other software), and second, XP may be used in virtual environment. (Third, VS 2017 still has support for XP, which is unbelievable and speaks for itself.)

And anyway, the program was written for XP and I see no reasons to drop XP support. It's up to the user if he wants to run it or not, it doesn't make the program itself more vulnerable.

[cshnik]

@ProgerXP PR is ready for merge.

[csware]

XP support in VS2017 is kinda broken.

[cshnik]

XP support in VS2017 is kinda broken.

I've checked test builds Debug/Release x86/x64 on clean Windows XP x64 and the only problem is Release x64 crashed when calling Open file dialog. I suppose this issue can be fixed separately from this PR.

[cshnik]

the only problem is Release x64 crashed when calling Open file dialog

The bug is in n2e_SubclassOpenDialog():

SetProp(hwnd, PROPERTY_ORIGINAL_WINDOW_PROC, (HANDLE)SetWindowLongPtr(hwnd, GWLP_WNDPROC, (long)n2e_OpenDialogWndProc));

should be replaced with:

SetProp(hwnd, PROPERTY_ORIGINAL_WINDOW_PROC, (HANDLE)SetWindowLongPtr(hwnd, GWLP_WNDPROC, (LONG_PTR)n2e_OpenDialogWndProc));

[ProgerXP]

Let's leave alone the wdk folder. It isn't the cause for failed compilation as far as I understand. Even if it's outdated, it should be written so in the README rather than removed so that people don't start questioning its absence here, go looking for wdk in the original project and/or we can get to update it at some point in time.

I am ready to merge this when wdkbuild/Notepad2.mak and wdkbuild/make.cmd are restored.

_CRT_SECURE_NO_WARNINGS

What does this definition do (it's in Notepad2 too)? Do we have unsafe operations that need silencing?

[ProgerXP]

@cshnik

The bug is in n2e_SubclassOpenDialog():

Was this fix part of this pull? If not was this committed to master?

[csware]

What does this definition do (it's in Notepad2 too)? Do we have unsafe operations that need silencing?

Yes, there are many.

The bug is in n2e_SubclassOpenDialog():

This is also in the PR.

Let's leave alone the wdk folder. It isn't the cause for failed compilation as far as I understand.

When you compile using that file it will fail. I don't understand why you want to keep it. It makes thinks just more complicated for people.

[ProgerXP]

When you compile using that file it will fail. I don't understand why you want to keep it. It makes thinks just more complicated for people.

Using sln/vcxproj from this repo without changes won't cause problems, right? Then updating or removing wdkbuild is a different issue from this PR.

We went a good length to preserve the structure of the original project so that it is a drop-in replacement not just in runtime but in the sources. If whoever needed wdkbuild still needs it, he'll find it here. But the docs should be updated, this is true.

[csware]

What's the advantage of keeping the original sources intact? - There are already lots of changes in them. - Besides this, there is the version history.

if whoever needed wdkbuild still needs it, he'll find it here.

Do you think there are lots of other developers who work on this project? if they still use wdkbuild then they must have already modified it...

Using sln/vcxproj from this repo without changes won't cause problems, right?

Sorry, don't understand.

[ProgerXP]

Using sln/vcxproj from this repo without changes won't cause problems, right?

Sorry, don't understand.

If we keep wdkbuild files, they won't cause any issues with compilation unless you actually try to use them, right? Because our default project settings don't reference them.

[csware]

If we keep wdkbuild files, they won't cause any issues with compilation unless you actually try to use them, right? Because our default project settings don't reference them.

But why to keep them? Even if you document somewhere, people will not see it and try...

[ProgerXP]

Do we at least agree that manipulations on wdkbuild are not vital for fixing our immediate compilation issues and so are part of another issue or PR?

[csware]

I put it into this issue as compiling using wdkbuild will fail.