I've never worked with ndless so you may have to guide me or point me to some documentation.

Sorry for the delay.... 

Update: My latest commit (standard integer types) broke something. Use previous commit code...
 

Yes it is v0.61 because I mirrored the old repo. As for the new repo I don't really know how to get a diff or a patch between 0.61 and 0.7 because I have changed a lot of files (although very little changes) and if I diff with the mirror version I don't know why it diffs the whole file. I have to look at it again (probably today).

I wanted to start with GTK because I use cinnamon and qt apps don't look that well... I also thought of leaving the windows gui as is for the windows platform...

About the windows build in linux I don't know how to do it... You will have to point me again in the right direction.

Thank you very much.

As it seems there's more people interested in a Qt gui I will think about it but a lot of work must be done before that.

When you talk about windows build in linux do you mean using mingw compiler in linux?

Thanks.

I know this is not clean but I think it is better than the "prefix" solution there's in your makefile because prefix is tipically used for other things in a makefile.

You did it almost like I'd have done it, I'd just have a common section for not linux-native Makefile lines and a section for both MinGW and windows native builds.
And I'm getting a message, that "_WIN32_WINNT" would be redefined in gui-windows.c, so you may want to surround it with #ifndef.

Also you could help me finding the bug that prevents me from installing ndles 3.6 on a mingw compiled nspire_emu.
Could you add
printf("Data abort: address=%08x status=%02x pc=%08x\n", mva, status, arm.reg[15]);at the top of data_abort in emu.c and launch ndless_installer?
For me it outputs Data abort: address=0101010d status=01 pc=102fd8e4 before "Segmentation fault".

As it seems there's more people interested in a Qt gui I will think about it but a lot of work must be done before that.

The Qt GUI for linux could then be used as-is for windows as well, so not more work than removing gui-windows.c

Here's what gdb says:

Program received signal SIGSEGV, Segmentation fault.
0x004018e5 in write_word ()
(gdb)
Continuing.

Program received signal SIGSEGV, Segmentation fault.
main (argc=0, argv=0x0) at emu.c:551
551                     sched_process_pending_events();
(gdb) bt
#0  main (argc=0, argv=0x0) at emu.c:551
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
main (argc=0, argv=0x0) at emu.c:551
551                     sched_process_pending_events();
(gdb) bt
#0  main (argc=0, argv=0x0) at emu.c:551
(gdb) s
[Inferior 1 (process 1516) exited with code 030000000005]


Then it may just be my self-compiled ndless_installer which does something different then.
Could you try it on the not-mingw version with data abort printf()?

And I don't really know how to use GDB, but if I read it correctly the call to sched_process_pending_events() segfaults once before crashing the second time?

I found it: It's the call to longjmp that doesn't reach setjmp again.
But how can "restart_after_exception" get corrupted?

I found that some (older) MinGW versions have a bug that setjmp puts garbage into ebp, but the workaround -fno-omit-frame-pointer doesn't help so it's probably another bug.
Can you make a write breakpoint in gdb on restart_after_exception and longjmp in data_abort? The contents of restart_after_exceptions have to be the same as after the initial call to setjmp.

Edit: Set up a Win7 VM and compiled it. With gdb it outputs the same emu.c:551, argc = 65535, argv=something weird, and it indeed segfaults at main + 2088: call sched_process_pending_events(). As call pushes eip onto the stack ($esp), but $esp is somehow 0x10, it segfaults. That also explains why argc and argv are weird, they're stored on the stack.