Sami Vaarala

Also setting `DUK_COMPILING_DUKTAPE` for non-duktape.c sources is similarly not intended - it is only intended for compiling Duktape itself and forcing it here may be fragile.

One approach would be to intentionally expose the visibility symbols as part of the documented API so that calling code could rely on them with versioning guarantees. That would eliminate...

Looking at the definition of `DUK_EXTERNAL_DECL` the main issue when compiling on Windows is that the necessary `__declspec()` is different depending on whether you're compiling the library (export) or the...

Also, any library that wants to use a certain header file both when compiling the library itself (export) and the calling code (import) will need to distinguish the compilation context...

> That's why I re-used existing macros. But your concerns are valid if you want to keep separation between the core and extensions. Separate macros would definitely be a cleaner...

All Duktape/C functions are "constructable" from script point of view, but you can reject such calls explicitly using https://duktape.org/api.html#duk_is_constructor_call: ```c if (duk_is_constructor_call(ctx)) { duk_type_error(ctx, "not constructable"); } ```

Internally each function actually does have a separate CONSTRUCTABLE flag, and there are some internally created functions which are not constructable. But the C check quoted above produces roughly the...

As for being able to create the instance from C code, you could use a structure such as this: ```c static void push_new_instance(duk_context *ctx) { /* Push and initialize instance;...

Could you try evaluating: ``` instance.toString === Object.prototype.toString ``` If this is true, then the inheritance chain (internal prototype) is still wrong. You can also check what the prototype object...

@kirill-782 Any update on this?