Join us on Discord!
You can help CodeWalrus stay online by donating here.

.exe to ASM?

Started by xMarminq_, December 28, 2016, 06:40:00 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

novenary

The C language and standard library were created for developing Unix, and Windows has never provided a sane environment for it. The point was more to make development more efficient while remaining easily portable across CPU architectures than operating systems (though nothing really hinders that, with some effort you can port stuff over if you know your way around the windows API).

Hayleia

Quote from: Streetwalrus on January 01, 2017, 05:43:50 AM
The C language and standard library were created for developing Unix, and Windows has never provided a sane environment for it.
Would the Ubuntu for Windows thing fulfill that purpose?
(True question here, I still use Win8.1 for games and Linux for dev so I have no idea what that thing does).

Scipi

There are quite a few hurdles you are going to run into if you want to port scratch programs in this manner. For one, your scratch exe will be in a different type of assembly (x86-64) than what the TI-83/84+ uses (Z80). You will have to end up learning both assembly languages and manually translating between the two, which is not an easy task. Additionally, a lot of the time tools like Scratch will link in their own runtimes into the exe. You will have to either port this stuff over as well, which would require deep knowledge of the calculator's hardware to do. You might as well make a scratch interpreter at that point. Moreover, if there's any optimization or obfuscation, it could become very difficult to understand the code you are trying to port (I speak from direct experience with this, this kind of stuff is my job ;)). It's much easier and much, much more worthwhile to learn Axe, Z80, or C and rewrite the programs with those. I cannot recommend this enough.

If you want to know of some tools to do this kind of stuff anyways to learn or play around with, there are a few really useful tools that I can point you to. Free ones that I know of are:
Ollydbg
x64dbg

These primarily debug a running program so you can reverse via dynamic analysis.

If you have funds, an excellent tool I use for work is IDA Pro. This also comes with the Hexrays decompiler.

There is also Medusa, which is like a free version of IDA. Not sure how good it is, however. These are static analysis tools, though. They don't require the binary to be executing.
  • Calculators owned: TI-83+, Nspire, Nspire CX, Casio Prizm




novenary

#33
Quote from: Hayleia on January 01, 2017, 08:33:01 AM
Quote from: Streetwalrus on January 01, 2017, 05:43:50 AM
The C language and standard library were created for developing Unix, and Windows has never provided a sane environment for it.
Would the Ubuntu for Windows thing fulfill that purpose?
(True question here, I still use Win8.1 for games and Linux for dev so I have no idea what that thing does).
Technically it does the same thing as msys or cygwin, essentially wine in reverse, but it's probably tightly integrated into the kernel and it's binary-compatible with Linux so you can run any distro in it, while the former two require specific builds.
One big problem with all three is the lack of a decent X11 implementation so don't expect miracles when it comes to GUI applications.

As far as the reverse engineering part goes, I'll side with scipi here, I design and reverse engineer hardware and software so I deal with assembly a lot, I've also patched a steam game once to fix a crash and it was all but easy. It gets worse when your application is c++ because that ramps complexity up quite a bit.

Dream of Omnimaga

Quote from: Streetwalrus on January 01, 2017, 05:43:50 AM
The C language and standard library were created for developing Unix, and Windows has never provided a sane environment for it. The point was more to make development more efficient while remaining easily portable across CPU architectures than operating systems (though nothing really hinders that, with some effort you can port stuff over if you know your way around the windows API).
Well, it seems this Windows problem was solved by @MateoConLechuga then, as the tools he made to develop C programs seems quite easy to use for everyone who tried them overall. But yeah, if someone doesn't want to restrict himself only to TI-84+CE development then I assume they aren't that practical :P

As for assembly, one thing to keep in mind is that even between two platforms with the same CPU, ASM code can still be different. For example, on the TI-83, you used ROM Calls instead of BCalls and the syntax to call them was different compared to the TI-83+/84+. It often also depends of the hardware (eg the LCD)
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

Well we were talking about programming *for* Windows, on Windows, not targeting other platforms. In the case of the CE, the target environment is completely non standard (custom stdlib, and not entirely compliant compiler), but it doesn't matter because it's an embedded system anyway. There are things I could be picky about but not today. :P

mazhat

18kB for a shape is pretty big,
also aren't scratch programs dependent on a scratch environment?
  • Calculators owned: TI-83Plus, TI-84Plus
  • Consoles, mobile devices and vintage computers owned: Samsung TAB A (Cheap), DSI, Rasperry PI 3
Sketti

Dream of Omnimaga

Mazhat they can be exported to Flash and tools can export SWF files to exe's but the latter tools look shady.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

mazhat

Ah, I see, I had no idea.
I would just stick to all of your recommendations, and just build programs in C or ASM :)

Or make a custom "compiler" for ASM if you know input/output streams, and the z80 opcode :D
  • Calculators owned: TI-83Plus, TI-84Plus
  • Consoles, mobile devices and vintage computers owned: Samsung TAB A (Cheap), DSI, Rasperry PI 3
Sketti

c4ooo

This is pointless - you won't understand the outputted x86 without a lot of practise, and without labels, understanding something of that size would be impossible for *anyone*. Plus, i would guess that the .exe file contains a Scratch interpreter along with the Scratch code save file - so the actual Scratch code most likely doesn't even run natively on the CPU. (Thats a guess but that's how i would implement something like that) ;)

Quote from: Streetwalrus on December 29, 2016, 03:15:58 PM
Quote from: p4nix on December 29, 2016, 02:03:39 PM
Also, if you want to get started with C programming, you might want to use linux since it is much easier to set up, at least in my opinion.
MS only supports c++ in msvc, actual c support sucks. I'd recommend against using anything like cygwin/msys/bash for windows, just use Linux and it'll go smoothly.
The C toolchain for the CE calc isn't hard to set up and doesnt need msvc/cygwin/msys/bash, at least iirc.

Quote from: DJ Omnimaga on December 28, 2016, 09:23:35 PM
I remember for the TI-83 Plus there was a BASIC to ASM converter and the ASM result was even larger in size actually.
Equivalent Asm code will commonly be bigger than equivalent TI-BASIC code; TI-BASIC uses tokens (1 or 2 bytes per token) while ASM is 1 byte per *instruction*. By "equivalent" i mean behaving 100% the same - using the a-z vars and all; but i don't know if the converter did this.

Dream of Omnimaga

I should check how large the exe version of Wal-Rush! Scratch Edition is. It had some bizzare behavior, though: When the game was running, if I minimized it or put it in the background to do other stuff on Windows, PrintScreen and the clipboard stopped working entirely. It was kinda scary that such SWF to EXE converter had so much control on my computer but it isn't JWinslow's fault, as I am sure that legit SWF to EXE converters cost a lot of money.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Powered by EzPortal