ebmDevMag.com home
ebm Developer's Magazine

developer's mag
main page

part 1
part 2
part 3
part 4
part 5
part 6
part 7
part 8

1 - Getting Productive: Working in the ebm Environment

One past newsgroup message pointed out how difficult the ebm development environment is. For Windows users it can be, so this column is to help us folk get comfortable with the system, and highlights tips and techniques to make creating ebm software as painless as possible.

The fact is, we ARE spoiled in Windows: likely, few programmers have worked without an IDE, or Integrated Development Environment. You edit, compile, run, debug, and view the error log, all without leaving the one program. In operating systems like Linux and its variants, programmers work closer to the metal; they compile from a command line, as well as run the program, debug, and view error logs (exceptions are the IDEs available under the X-Windows environment, which aren't relevant here). In fact, Windows and ebm program creation use virtually the same operations, which are hidden by the Windows IDE:
  • Source code is edited and saved to disk, where it is then accessible to the compiler.
  • The compiler processes the source code, creating a piece of the final program. Called an object file, it usually has an extension of .o or .obj.
  • The linker takes copies of these files and others, and binds them together into the finished program. Here things differ a little from Windows, since the destination for a Franklin file has the extension of .FXE or .SEB instead of .EXE, depending on whether the code will run on the ebm or the emulator.

Next Section

Copyright © 2001-2006 ebmDevMag.com - Legal Notice