I assumed @Victorel-Petrovich wouldn’t mind it being moved

True

Personally, when I am doing a lot of print-based debugging, I write wrapper functions or #define macros that encapsulate all the formatting into the string, and then call the proper output function with that string, so that I can just have a single line of code for each inline debug print, and I let the complications of definining a dummy buffer variable and the sprintf formatting elsewhere.

But really, none of these questions are specific to debugging Notepad++, and is really a generic C/C++ “best way to debug without a debugger, without a console, or similar restriction” question.

But when you have several tens of outputs to write in every function you test

Hmm, no idea why that’s a problem…

I think if this is how you’re considering debugging Notepad++ changes you might make…it is going to wear you down fast and you’ll give up trying to make changes.

It’s just a matter of (in very simple terms):
char buf[1024];
sprintf(buf, “test”);
OutputDebugString(buf);

But when you have several tens of outputs to write in every function you test… :/

So printf() is easier to use (at least for most practical cases, IMO), and already familiar.

Really, only because you already have the “console” approach in your rearview mirror.

If someone didn’t have that, OutputDebugString is easier.

It’s just a matter of (in very simple terms):

char buf[1024];
sprintf(buf, “test”);
OutputDebugString(buf);

Everywhere I read (including 2 ref-s above , and at microsoft) they say OutputDebugString() is for when the app is run from / has a debugger .

… but it is not limited to be used only by debuggers. Applications like debugview from sysinternals tools can be used to get this output.

or a pythons script like

import ctypes
from ctypes.wintypes import HANDLE, DWORD, BOOL, LPVOID, LPCWSTR, LPHANDLE
import mmap
import struct
import os
from Npp import console
console.show()

kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

CreateEventW = kernel32.CreateEventW
CreateEventW.argtypes = [LPVOID, BOOL, BOOL, LPCWSTR]
CreateEventW.restype = HANDLE

SetEvent = kernel32.SetEvent
SetEvent.argtypes = [HANDLE]
SetEvent.restype = BOOL

WaitForSingleObject = kernel32.WaitForSingleObject
WaitForSingleObject.argtypes = [HANDLE, DWORD]
WaitForSingleObject.restype = DWORD

WaitForMultipleObjects = kernel32.WaitForMultipleObjects
WaitForMultipleObjects.argtypes = [DWORD, LPHANDLE, BOOL, DWORD]
WaitForMultipleObjects.restype = DWORD

CloseHandle = kernel32.CloseHandle
CloseHandle.argtypes = [HANDLE]
CloseHandle.restype = BOOL

BUFFER_READY = kernel32.CreateEventW(None, 0, 0, 'DBWIN_BUFFER_READY')
DATA_READY = kernel32.CreateEventW(None, 0, 0, 'DBWIN_DATA_READY')
STOP_DBG_LOOP = kernel32.CreateEventW(None, 0, 0, 'STOP_DBG_LOOP')

HANDLES = (HANDLE * 2)(DATA_READY, STOP_DBG_LOOP)
buffer = mmap.mmap(0, 4096, "DBWIN_BUFFER", mmap.ACCESS_WRITE)
CURRENT_NPP_ID = os.getpid()

# Call SetEvent(STOP_DBG_LOOP) to stop the loop,
# either with a second script or by calling from the PS console

while True:
    SetEvent(BUFFER_READY)
    result = WaitForMultipleObjects(2, HANDLES, False, 0xFFFFFFFF)
    if result == 1:  # STOP_DBG_LOOP received
        break
    elif result == 0:
        buffer.seek(0)
        process_id, = struct.unpack("L", buffer.read(4))
        data = buffer.read(4092)
        if CURRENT_NPP_ID != process_id:  # to prevent seeing PS's own debug strings.
            if b"\0" in data:
                data = data[:data.index(b"\0")]
            print("Process:[{0}] {1}".format(process_id, data.decode().strip()))
    else:
        print('ooppss: {}'.format(result))
        break

CloseHandle(BUFFER_READY)
CloseHandle(DATA_READY)
CloseHandle(STOP_DBG_LOOP)
print('done')

Everywhere I read (including 2 ref-s above , and at microsoft) they say OutputDebugString() is for when the app is run from / has a debugger .

But, it’s similar, and apparently what you have going now works, so…

Indeed.

OutputDebugString() is where I’d go with it, rather than going to the trouble of getting a console. But, it’s similar, and apparently what you have going now works, so…

Instead, I was curious about was whether it was possible to make the printf results appear in the console cmd.exe from where I run the Npp .exe. I thought since this is debug version, maybe some compilation settings are possible to allow that. But that’s just a curiosity; above setup seems to work well.

The extra code you’re inserting into the N++ binary may end up introducing bugs instead of detecting the ones already there.

I think it’s obvious / common sense that one doesn’t leave any “extra” (unnecessary) code in a PR.

I seriously doubt how useful it’s going to be

Very useful; I already tested some of my assumptions.

But maybe it’s possible better way, of specifying somewhere say in “appveyor.yml” that printing to a regular/parent console is allowed for a “debug” version…

You can achieve what you’re asking with conditional compilation.

TL;DR

#ifdef _DEBUG
  // . . . print to console . . .
#endif

This guards a block of code at build time by checking for a preprocessor definition that should only be set in the debug configuration.

Now, as much as I admire the inventiveness of your ad hoc approach, I seriously doubt how useful it’s going to be. The extra code you’re inserting into the N++ binary may end up introducing bugs instead of detecting the ones already there.

If your adverse/unable to get Visual Studio up and running, the N++ source code is still compatible with the MinGW toolchain, which comes with a Makefile processor and the GNU Debugger utility. (At the time of writing, Windows Vista is the oldest OS that can run notepad++.exe images built with MinGW).

Once you have the tools installed and can build N++ all by yourself, attaching the debugger should be as easy as entering: > gdb r C:\<path>\<to>\notepad++.exe. There’s an extensive suite of command line options for stepping through code, inspecting variables, etc.