Hi all,
I'm developing ike
Ike is an OO lang which transpiles to Lua 5.4,
a graphic toolkit based on Ultimate++ framework and an Ide.
Ike works only for Win32/64, at now.
The translation is transparent to the user, who sees only Ike code.

Ide implements also a still rudimental debugger.
One nice feature is the possibility of recompile classes at runtime
and see living objects changing their behavior immediately, without
the needing to restart the system.

Maybe someone of you may find my sw interesting
because there is also some support for Fasm, via fasm.dll.

In the ide you can write asm code, compile it at runtime
and call. There is also some example on how to build Lua
modules in assembler and link them in the vm on the flight,
so that asm functions can be called natively by Ike
(that is... by Lua).

This version is 32 bits (so you can code only in "use32" mode),
but the 64 bits is available if someone needs it.
Binaries and sources:
https://drive.google.com/file/d/1qmW_XsiiubCvBcAgLkYghjWzCzDfsdcB/view?usp=sharing


(sadly, recentely I hosted some virus, in my PC.
Now I should be clean, but please check my binaries
with an av before loading).

Regards
Paolo

Interesting project. I think Lua and fasm complement each other well.
(Funny, "Ike" is my brother's name. )

Hi bitRAKE,
ike derives from IDE, with hacKing in place of Development.

If you want to integrate with Lua from C/C++ or asm, you must pass through Lua APIs, that are a set of functions with which you can read/write data in/from Lua's vm.

I always thought that passing through Lua's API was an inefficient way of dealing with vm.
Playing with asm I realized how I was wrong: LAPI are very optimized. Rarely asm code run faster. The maximum gain I realized is asm code that runs about 50% faster than Lua-interpreted. In many cases the speed is the same.

With asm you can not make miracles, in terms of speed.
But in some situations you can do even better than C in an easyer way. For eaxmple with continuations, that are very simple if implemented in asm.

Hi
Tried it under w10x64
All paths in latin (d:/dev/)

No gui?

I don't think projects like AsmJit are looking for miracles, but to reduce the cost of dynamics. Code generation at runtime can also grant flexibility - adapting algorithms to different calling conventions and configurations. Embedding both Lua and fasm would be half the size of AsmJit.

C knows nothing of the machine and furthermore has a very specific execution model. [If performance is the goal:] If one is not able to think outside of that model then there is no point in dropping to asm in most cases, imho.

I'm trying to find the right manifest for win10...
another attempt is here

https://drive.google.com/file/d/1A8YFAIeWwIs3X9f7Qk4YtlRliUMqHnLK/view?usp=sharing

Can you check it for me?
This version does not link fasm, nor tcc. When I find the way to open my gui in win10 then I'll pack all the rest.

Now I have added TCC and Capstone support.

One thing I would try is allowing the extension of ike's parser with new syntaxes, at runtime. I designed it from the beginning with the idea of an extensible parser (ie: keywords can be added/removed at runtime, they are nod hardcoded, and the algo for parsing expression is based on Pratt algo, which allow to modify the logic at runtime.

failed
ike.log:

did you tested the 004 rel?
https://drive.google.com/file/d/1A8YFAIeWwIs3X9f7Qk4YtlRliUMqHnLK/view?usp=sharing


I hate windows 10

the last manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
name="Microsoft.Windows.ike.exe"
processorArchitecture="x86"
version="5.1.0.0"
type="win32"/>
<description>ike - development tools</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<!-- Identify the application security requirements. -->
<!-- level can be "asInvoker", "highestAvailable", or "requireAdministrator" -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

with this rc:

101 ICON "ike2.ico"
1 24 "ike.manifest"

any suggestion will be highly appreciated

I did
I dislike official too, lite patched,debloated used (i would stay with xp still)
I must say ssd is the reason i had to migrate

I was an happy xp user until one year ago...

the 004 does not works, because its statically linked with fasm/tcc, but the dlls are missing

the 005 should fix this

https://drive.google.com/file/d/1-xIrWr0l34rv-tc1NOZ-k4El-QbtZId3/view?usp=sharing

...does gui will open?

Why do you stick to manifesting
Controls used?

Could you post compiler options?
I'm not familiar with sigwin(?)
Forum member should help

v5 - failed under xp.sp3 comp mode
i face same problems running my faforite apps which worked good under xp os (i'm ro reinstall now!!!!)

post you compiler [linking] params

failed under XP?
...that's a very bad news.

I don't know the exact linking options, because I'm using the ide of ultimate++, which hides the details of its compiling machinery. And I don't know how to see them.

because in order make an exe working in windows10 it's mandatory to include a manifest file in the exe's resources or as an external file.

(and being me totally ignorant I tryed to copy some manifest and adapt it to my program)

there are apps, written in fasm, by me with no manifest and they work

in general it is wrong, as we do not concentrate on your app, win10shit instead

in effect its my hypothesis that all depends from the wrong manifest.
I just verified that in the Win10 of one of my friends Ike started, compiled its initial files and then exited, when instead it should open the gui.

It could be something else...
I'm very frustrated.