x64dbg
x64dbg copied to clipboard
x64dbg
Any ETA for 4.0 release?
What would you like to be added: A new release! So that would be whatever that is on the master branch.
Why is this needed:
Node LTS is currently on 12.20.0. I believe the node which nexe supports in its latest official release for 3.3.7 is only up until 12.16.2.
So there is a gap between 12.16.2 to 12.20.0 and I believe this gap is only going to get bigger as the node community releases more minor updates.
@aral thanks for your input. Neither you nor nvm got the LTS version wrong. Apologise for not getting my sentence right.
What I am trying to say is. There is currently a gap between 12.16.2 to 12.20.0 which nexe will not compile. I thought I will ask to see if there will be a new release anytime soon since the last official one was a few years back. And I think, maybe, with a new release that will fill that gap. Meaning it will work if I am running 12.20.0.
I will do over the holidays, @calebboyd. Last I checked there was something breaking my build of Site.js and I didn’t have time to look into it so I’m still running on my fork. Will test and file any issues if necessary :)
@aral Merry xmas! Thank for looking into it.
@calebboyd I haven't. I was struggling to install it because I thought nexe@next was actually nexe@nexe, next vs nexe hahaha
Merry xmas to you as well. Thanks for the support. I'll take a look later.
Moved v4 to "latest" on npm. Because of the way node has changed its boot architecture and embedding methodology - nexe v5 is going to be a rewrite and will drop support for Node 10 or lower.
Trying to figure out an approach for fast AND signable builds will also be the primary focus of v5.
Hey @calebboyd -- Signed builds (MacOS & Windows) is what we are looking for as well. But is it safe to assume it will be a while before that comes out since you mentioned v5 is going to be a rewrite?
Yeah, There are combinations of benefits.
Current implementation can achieve fast + unsignable builds or
slow (and cumbersome) + signable builds with flakey "patches"
I could either - improve the ergonomics of the slow and cumbersome builds w/ patches.
Or figure out a way to make the "fast builds" signable. Which has me going down the path of modifying already linked binaries (not a simple append) for each platform, which is so far, non-trivial.
I don't know if it helps but node-packer uses a mechanism that allows the builds to be signable. It patches the node.js C code extensively to use SquashFS and what not, but the end result used to be quite promising - small builds, signable and it included everything in your project without mentioning what resources you wanted to add. We have been using this successfully using a version built on top of Node 10.15 (one of the forks). But the original developer stopped supporting the project for lack of time and thus Node 12/14 support is not available at all. He did some work a few months back, but it's not working correctly.
If nexe could do what node-packer did, it would be a big step forward. If only I knew enough C, I would have tried maintaining or porting some of that functionality from node-packer to nexe.
Signing the binaries is non-negotiable for us since we embed the binary in an electron app, which cannot be notarized without signing the included binaries. Without this, we are dead in water.
I was wondering, with the signable slow (and cumbersome) builds created by nexe, can it include resources like shell scripts in the final binary? And can you point out to me, how exactly should I go about trying to build it (build=true, mangle=false)?
Yeah the approach that node-packer uses is effectively one level deeper on the file system 'hacks' that nexe performs. I don't have bandwidth to maintain something on that level - so arriving at a solution that builds on discretely solved problems would be most effective.
That makes sense. I only mentioned it since you mentioned rewrite for v5 and that signable binaries are a priority focus. I am sure it needs plenty of time to maintain such a complex tool and I appreciate your work which makes lives much. easier for folks like me. 👍
On an unrelated note, I noticed in the nexe documentation that with mangle as false there would be an 'Invalid binary' error. This means even the signable binaries (created with slow and cumbersome build to process) cannot be executed. Is this correct? If yes, there is really no point in creating a signable binary which cannot be executed.
If this is not correct, would it be possible for you to guide me a bit on how to create a signable binary. Just a small start should be enough. I can build on that from there.
Much appreciated!
One final question for the day @calebboyd 😄 --
Do you have any idea on what is being talked about here? - https://github.com/nexe/nexe/issues/494#issuecomment-754493802
My limited understanding tells me that nexe code is being modified somehow to put the custom node.js code/files in a different data file, without impacting the original node binary. And then let nexe use that data file somehow. It's not a single binary as there would be 2 files, but that is very much acceptable considering the current alternatives.
But even if I am right, I don't know how to make any use of that -- creating a separate data file using a different custom filesystem and then let nexe use that during execution!
Hello all 👋 I wanted to check in on the stability of 4.0.0-beta.17? I have a production application needing a newer node version than 12.16.2 due to security concerns and wasn't sure what to make of the current beta. I see it's marked as latest on NPM and at iteration 17, but it's also says beta in its name. So just looking for a bit of guidance, thanks!
The largest changes in 4 have to do with build time dependency resolution. If you don't have any issues bundling your application there are very few differences from 3.X