Hyperion Software is a programming group for TI graphing calculators focused on C development for the eZ80 and MC68000 based calculators. Basically, we'll do stuff for calculators witha C SDK. If you want to compile our projects yourself, you'll need GCC4TI for the 68K calcs (TIGCC also works, unless the project uses one of the patches accepted to the former but not the latter.) and the llvm based CEdev toolchain (eZ80-clang and the like). All compilation stuff, desktop applications, build scripts, etc, are intended for usage with UNIX-like operating systems. (GNU/Linux, *BSD, MacOSX, for example.) The full list can be found here. For reasons both ethical and practical, M$ Windows is not directly supported. Here's why:
1. Windows is not Free Software. This would also bar MacOS development, except it's trivial to add MacOS support once there's a working *NIX version. Certain components might require XQuartz to run, owing from the fact that the *NIX version uses it. Specifically, if I write something in C using Xlib, it'll work on GNU/Linux, BSDs, and MacOS, but not Windows. I'll write it on Linux, to work on all UNIX-like operating systems, but anyone who wants to can build it from the source can do so on a Mac.*
2. Windows breaks applications from one version to the next. This is also present in MacOS, but to a lesser extent, because Apple's pretty good at not breaking their users' stuff. Linux never breaks anything. (Or at least, that's the policy.) BSDs run just like they did years ago. So if we write software for them, we can be assured it will almost always work. This policy of supporting older software, and allowing older libraries, means software will be relevant for decades after it is written. Heck, you could compile and use the original VI editor! (Not that you'd want to; VIM is a much better choice.)
3. Developing for Windows requires... workarounds. Windows is... odd. In most UNIX-like operating systems, you have a home directory, whether it be located in /users/, /home/, or /usr/home/. Windows technically has one too, but it's mostly hidden from the user. Very little actually happens there. Windows also doesn't support the kind of file permissions that are commonplace elsewhere. And something really annoying is that any file from a Windows system has the executable bit set. This is not so much a problem with Windows as it is with NTFS, but the inability to change it is another concern.
4. I could go on and on. But here's the gist of it.
Languages:
C
ASM
*There are some hoops to jump through, however. For example, to compile "libtest.c" on GNU/Linux or a BSD, you run "gcc libtest.c -lX11" - assuming you have already installed the dev headers for xlib. On a mac, the command would be "gcc libtest.c -I /opt/X11/include -L /opt/X11/lib -lX11" - assuming you have used macports to install said headers. Of course, you could always disable SIP and put the headers in the proper place, but most people don't want to do that. Although you'll have trouble compiling anything that uses pthreads because Apple's implementation is buggy.
|
|