Build a DLL and launch that within a native executable

I’ve been watching a series called Handmade Hero, a lot, and has got me wondering on the many ways to have live previewing enabled. In the series, the code used to load a DLL file and written to the buffer is something along the lines of this:

...(char *SourceDLLName, char *TempDLLName)
    win32_game_code Result = {};

    Result.DLLLastWriteTime = Win32GetLastWriteTime(SourceDLLName);

    CopyFile(SourceDLLName, TempDLLName, FALSE);
    Result.GameCodeDLL = LoadLibraryA(TempDLLName);
        // Allocate the results

        // Render if the result is valid


(Removed much of the code for copyright reasons) Now, I can see that copying files can be done in Haxe, but can loading DLL files be done, or will I need to implement it similar to the above code and create an extern in Haxe?

It’s not impossible,
a neko application can load a neko file
and a cpp application can load a cppia file

I realised I actually made a discussion about this a while back and completely forgot about it. Now I’m a bit more curious as to how you can build a DLL file rather than EXE using the neko target, as I think I know how to do it there. CPPIA seems a bit much to my liking, but I may use it some other time - this is for experimentation mainly.

Naturally, I tried using this:

haxelib run openfl build project.xml neko -Ddll

But to no surprise, that define did not do a damn thing! :stuck_out_tongue:

To be exact you don’t build dll for haxe, it’s ndll, but that’s c++.

In neko there’s no need to do anything special, in openfl you can get the neko file in Export/os/neko/obj/ApplicationMain.n and it’s all you need to load it into another neko program.

For your swf problem could you open a separate post?

I may go down the route of using the ApplicationMain.n file to load as Module, but - and I apologise for this potentially noob question - how do I access Module in haxe.std.neko?

The haxe.std package seems to be something that you cannot access by default, unless that’s just FlashDevelop being stupid.

FlashDevelop is confused :wink:

You just need to use neko.* => neko.Module

Okay, so I attempted the following code:

private function loadModule():Dynamic
        var m = Module.readPath("game.n", ["assets/lib/"], Loader.local());
        return m.execute();

and this resulted in the following:

I know that’s a bit hard to read, but the error at the end goes something like this:

Uncaught exception: Invalid field access : __s. .. alc_cleanup: 2 devices not closed

I tried the following to resolve this:

private function loadModule():Dynamic
    var l = Loader.local();
    var m = Module.readPath("game.n", ["assets/lib/"], l);
    var d = m.execute();
    m = null;
    l = null;
    return d;

This was me thinking that maybe neko didn’t know how to close buffers or streams, so set m and l to null, but this resulted in the same error. :confused:

I don’t think the problem comes from the loading code, most likely it’s the fact that the module also contains the code to open the window, the sound manager and things like that.

I looked into it a couple of month ago for a similar problem,

After reading this:

I changed my code around to this:

private function loadModule():Dynamic
        var l = Loader.local();
        var m = Module.readPath("game.n", ["assets/lib/"], l);
        return m.exportsTable();

That seemed to return this:

{ __module => #abstract } Which I assume is normal, but now I need to somehow render it. Or is that what the execute() is supposed to do?

The initial problem was that the former code caused the neko application to crash as soon as it opened.

The execute method calls the main function of your program,
which in the case of an openfl application contains the code to open a window…

So if your launch it from an “empty” neko code it should work,
but from another openfl code it doesn’t seem to.

I may test this out in an Lime application instead, maybe it will work better! Although I’m not sure I like the idea of reopening a window for this “instantaneous” effect of reloading code. Is it possible to attach the ModuleHandle to the Lime application before executing it, so that the result is redirected not in its own window but embedded as a resource instead?

It’s one of the goals to be able to do such module approach, but it’s not done yet.

The openfl code calls lime to open the window …, so that won’t work.

You’d have to separate your code from the openfl code somehow,

or do like I did (links to my fork) and prevent openfl from doing its things. Which is not without its problems, like for events from the mouse or keyboard that you don’t get.

Not sure if its helpful, but perhaps you should look at the “HandlingInputEvents” sample for Lime, it shows you can drive an application from Lime, but add OpenFL on top for rendering.