Vincent Parrett

I would try using MadExcept or Eurekalog for capturing unhandled exceptions - in my experience they produce far more reliable and useful information than JCL.

I ended up using c# for the project - https://www.finalbuilder.com/signotaur - delphi just lacked the technologies I wanted to use for the project and I didn't want to spend so much time just getting the plumbing working.

Thanks to the help of @Keesver and @pmcgee I now have quickjs-ng building with MINGW in WSL for Win32 and Win64. It would have been nice to get them building with native windows tooling but alas that's just too hard due to how the project is setup (ifdef hell). My next challenge will be to get his automated on our CI servers (server 2019) which currently do not have wsl installed. I added a windows resource file (winver.rc) so I can set the version number. #include <windows.h> 1 VERSIONINFO FILEVERSION 1,0,0,0 PRODUCTVERSION 1,0,0,0 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x40004L FILETYPE 0x2L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904b0" BEGIN VALUE "FileDescription", "QuickJS NG" VALUE "FileVersion", "1.0.0.0" VALUE "ProductName", "QuickJS NG" VALUE "Comment", "Compiled by VSoft Technologies Pty Ltd" END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END END FWIW - this is the makefile I ended up with - just provide the ARCH on the command line, e.g make -f Makefile_win ARCH=64 Makefile_win ARCH ?= 32 ifeq ($(ARCH),32) CC = i686-w64-mingw32-gcc CFLAGS = -O2 -fPIC -Wall -D_GNU_SOURCE -DCONFIG_VERSION=\"V16\" LDFLAGS = -static -shared RC_COMPILER = i686-w64-mingw32-windres --preprocessor=i686-w64-mingw32-gcc --preprocessor-arg=-E --preprocessor-arg=-xc-header --preprocessor-arg=-DRC_INVOKED RC_FLAGS = --target=pe-i386 else CC = x86_64-w64-mingw32-gcc CFLAGS = -O2 -fPIC -Wall -D_GNU_SOURCE -DCONFIG_VERSION=\"V16\" LDFLAGS = -static -shared RC_COMPILER = x86_64-w64-mingw32-windres RC_FLAGS = endif OUT_DIR = Win$(ARCH) RC_FILE = winver.rc RES_FILE = $(OUT_DIR)/winver.o SRC = quickjs.c libunicode.c libregexp.c cutils.c libbf.c quickjs-libc.c OBJS = $(patsubst %.c,$(OUT_DIR)/%.o,$(SRC)) TARGET = $(OUT_DIR)/quickjs-ng$(ARCH).dll all: $(OUT_DIR) $(TARGET) $(OUT_DIR): mkdir -p $(OUT_DIR) $(OUT_DIR)/%.o: %.c | $(OUT_DIR) $(CC) $(CFLAGS) -c $< -o $@ $(RES_FILE): $(RC_FILE) | $(OUT_DIR) $(RC_COMPILER)$(RC_FLAGS) -i $(RC_FILE) -o $(RES_FILE) $(TARGET): $(OBJS) $(RES_FILE) $(CC) $(LDFLAGS) -o $@ $^ clean: rm -rf win$(ARCH) Thanks again for all the help.

@Keesver thanks, this looks promising. Another dev was able to get it compiling with CBuilder Win64x - however my immediate need is Win32 - any idea what changes need to be made to get quickjs-ng compiling for Win32? I'm also keen to take some changes from https://github.com/koush/quickjs to enable debugging at some point.

Yes, ActiveScripting has been abandoned by Microsoft - which would be fine if they just made sure it continued to work for a while, but they recently completely broke it - https://www.finalbuilder.com/resources/blogs/finalbuilder-and-automise-on-windows-11-24h2 We have a ton of existing javascript, as do our customers (each action has events customers can write scripts on), so it's not simply a a case of swapping out scripting languages. I did look at p4d a while ago but ran into issues - I don't remember the specifics (something around threading - finalbuilder is multi threaded). It's on my todo list to look at again when time permits. We currently have iron python support, but have been telling customers not to use it for some time due to memory issues. Swapping that out for for P4D might sound like a no brainer but Iron Python allows people to use .net framework classes. What ever happens, we're going to have some unhappy customers. Tech debt sucks!

I'm looking to replace MS ActiveScripting in FinalBuilder.

Kindof - there are a bunch of "forks" of quickjs out there - QuickJS-Windows-Build is one - but it's very out of date and I couldn't get it to build.

Hi All I'm looking at getting QuickJS working in Delphi. Sadly my C skills are not at the level needed to get anything to build in CBuilder or Visual Studio these days - it's not the same language I used 30+ years ago. There are a bunch of forks of this project, and I am pretty sure I have tried them all but have yet to get a completely successful build - probably because I don't know what I am doing. Ideally I'd like to be able to generate Win32/Win64 object files that I can link into delphi, or if that isn't feasible then a dll that I can load. Prefer C++ Builder but failing that Visual Studo 2022 is also an option. The C code apears to be written for GCC and supports Win32 via MINGW. I am willing to sponsor someone to work on this if needed. DM me if interested. Timeframe is asap!

Interesting, similar to my old library (except that I handle stderr) - I will have to study it further as I have been considering using job objects since seeing a talk on them at DelphiSummit (I have looked at them in the past but never implemented them).

I'm also using a 4K buffer, but in my testing a larger buffer size makes no discernible difference to performance.

@Kas Ob. not sure what hardware he is using but on my 5900X ssd system I am seeing 16-17s for both his library and mine.

This is interesting - I have my own process library that uses IOCP for reading stdout/stderr and I thought it was fast (it's a lot faster than my old library that uses threads) - but in a quick test your library has pretty much identical performance. That makes me consider switching to overlapped io and avoiding the extra complexity with IOCP. My approach is similar to yours, my library does not convert stdout to strings by default. It was inspired by this library, which has a nice abstraction over the IO side of things. https://github.com/Tyrrrz/CliWrap Not sure if I will end up publishing my lib, I have become rather disallusioned with the whole open source side of things - but that's another story.

Intercepting functions for unit testing is a terrible idea. A better option would be to create abstractions and a concrete implementation (ie actually calls UuidCreate), that abstraction can be easily mocked using Delphi Mocks or Spring4D for uinit tests. The same applies to code that relies on things like Now or NowUTC - e.g - https://github.com/VSoftTechnologies/VSoft.System.TimeProvider

With Signtool Yes, however with Signotaur you do not.

FinalBuilder is an Automated Build tool which supports Delphi 3 - 12.3 and C++Builder 3 - 12.3, along with many other tools. Version 8.5 adds a new Password Variable type, stronger encryption and new actions to interact with the Windows Credential Manager. https://www.finalbuilder.com/resources/blogs/finalbuilder-85-and-automise-55-release