1. Home
  2. Plugin Development
  3. Help to porting SourceCookifier for 64bit

Help to porting SourceCookifier for 64bit

  • ArkadiuszMichalski

    Could anyone try port the SourceCookifier plugin for the 64-bit version of Notepad ++? Here is homepage and source.
    Personally, I do not have knowledge about C ++ and learning it would take forever to be able to do it. So if there is someone brave who has the time and desire I would be grateful (and certainly not only me because this plugin is very good).

    @andrecool-68 Maybe you would try? In the same way as for the Preview Plugin? I wonder how much work it takes to compile it into a working form.

    0
  • andrecool-68

    I am a professional house builder (retired) …not a programmer)))

    2
  • Michael Vincent

    SourceCookifier is written in C# not C++. I know little of either, but have Visual Studio 2017 Community install and after a bit of hacking was able to get SourceCookifier to compile as 64-bit. However, it gives the old “This ANSI plugin is not compatible with your UNICODE N++” …

    This is weird because the isUnicode() sub is present and it returns true. Not sure if there’s a compiler flag missing or something.

    Anyone who knows C# care to weigh in?

    2 Ekopalypse 1 Reply
  • Ekopalypse

    @Michael-Vincent

    Out of curiosity I gave it a try.
    Besides creating a x64 configuration I had to edit NppPlugin.DllExport.targets file.
    LibToolPath needs to be set to the path of lib.exe, for me this was
    LibToolPath="$(DevEnvDir)\..\..\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64"
    and the SdkPath needs to be set to find ildasm.exe which for me was
    SdkPath="C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64"

    After those changes I was able to build a 64bit version but didn’t do any functional tests as I’m not using this plugin but maybe this enough for you to get started.

    1
  • Michael Vincent

    Thanks, I needed to do those things as well to get it to compile. The issue is Notepad++ thinks the output DLL is ANSI, not UNICODE. I can’t find an “OutputUnicodeDLL” or some such switch in the C# project files or the MSVC 2017 Community IDE even after much Google-ing.

    0 Ekopalypse 1 Reply
  • Ekopalypse

    @Michael-Vincent

    I haven’t had this issue

    2 Meta Chuh 1 Reply
  • Michael Vincent

    Interesting! So if I figure out why it seems I’m outputting ANSI, it should work.

    0
  • Meta Chuh

    @Ekopalypse

    i guess the easiest thing for the op would be if you upload and publish your sourcecookifier x64 unicode test build. eg at your github repo (binary only) or anywhere else.

    0 Ekopalypse 1 Reply
  • Ekopalypse

    @Meta-Chuh

    but that would bring me into a position which I don’t really like,
    namely doing some kind of maintenance - it is not really python :-D

    1
  • Alan Kilborn

    @Meta-Chuh said:

    upload and publish your sourcecookifier x64 unicode test build. eg at your github repo (binary only)

    @Ekopalypse said:

    but that would bring me into a position which I don’t really like, namely doing some kind of maintenance

    Why bin only? One presumes the (source) code fork is already there. And there are plenty of “dead” forks around (so why would you feel obligated to do maintenance).

    2 Ekopalypse 1 Reply
  • Ekopalypse

    @Alan-Kilborn

    but if you upload something and offer a solution you will be automatically
    the primary person to contact if something doesn’t work as expected as you have
    provided that plugin/source code.

    0 Alan Kilborn 1 Reply
  • Alan Kilborn

    @Ekopalypse

    Ha. Nah. All you did was fork something and play around with it. Plenty of examples of people doing that on github. Only if you go so far as to take real ownership do you get into the situation you talk about. :)

    0
  • Michael Vincent

    @Ekopalypse

    Agree - that’s what I’ve been doing with un-maintained N++ plugins. Fork, it improve for me and post if others want it. I don’t plan on trying to include it in the nppPluginList which I think would be the real “taking ownership” thing.

    2 Alan Kilborn 1 Reply
  • Alan Kilborn

    @Michael-Vincent said:

    …include it in the nppPluginList which I think would be the real “taking ownership” thing.

    Well, you could go that far if you wanted to, and (I’d say) if you got the original author’s permission…but it is up to you.

    Downside to not doing this: How would others know about the existence of these plugins (the “column” one especially I look forward to trying out).

    1
  • Michael Vincent

    @Ekopalypse What version of the Microsoft SDK are you using to compile? Is it version 7? What version of Visual Studio Community?

    I’m using VS Comm 2017 and version 10 of the SDK (v10.0A). I’m getting weird errors and overflows when trying to run the successfully build DLL in N++. Wondering if the supplied DLL in DLLExport are geared for an older version of Visual Studio and / or SDK?

    2
  • Michael Vincent

    More troubling, the same set of tools / versions on Windows 7 actually works for me - my successful build actually runs in N++ without crashing it. But copy that good DLL to Windows 10 and save errors. I wonder if there’s a redistributable that I have on Windows 7 and not on 10? I just don’t know/ understand C#.

    2 Ekopalypse 1 Reply
  • Ekopalypse

    @Michael-Vincent

    Yes, I’m using Win7 as well and I was using VS 2017 community edition and SDK 7.
    Unfortunately I don’t have Win10 - so cannot confirm your findings.

    1
Log in to reply