Free 0.6.1 software for linux

DWI is an experimental platform for exploring ways of making application development simpler. It is still hard to write large, complex, multi-user, data-driven (SQL-backed) applications.
It doesnt matter if your development platform is the web and Enterprise Java Beans, C# and .net or Mono, or whether its the Gnome/GTK or KDE widget set and the Linux desktop; its still just plain hard.
DWI is an effort to change this situation. DWI currently offers a simple way of developing data-driven (that is, SQL-backed) Gnome applications (designed with the Glade GUI designer).
It does this by avoiding "programming" (or at least, "traditional programming" in C. C#, perl, python or any other "traditional" language), substituting instead a configuration-file like format that defines how various GUI elements should be hooked up to various objects (such as GLib GObjects) or SQL fields and tables.
The current primary effort with DWI is to provide a number of well-documented, easy-to-understand, working examples that show how to use DWI. These examples currently include a stand-alone bug-tracker-like application, examples of integrating with existing GTK applications, and an example of hooking up a Glade-designed interface to a GLib GObject with almost no C programming at all (assuming you have a GLib GObject already handy.
DWI is a fairly simple environment for quickly creating data-driven applications, that is, graphical applications that manipulate and show info from a database. This environment differs from others in that it is focused on native GTK/Gnome support through the Glade GUI designer, and thus allows you to build user interfaces as elegant as you can make them in Glade.
At this point, this system has enough features to be adequate for creating form-editing and reporting applications. Multiple SQL database vendors are supported through ODBC or libdbi drivers. There is a simple db-driver infrastructure so its easy to support for additional SQL APIs. The system supports all of the basic Gtk widgets, and an additional half-dozen Gnome I/O widgets, such as GnomeDateEntry.
DWI is powered by an engine that has some fairly generic procedures for mapping fields, such as SQL table columns or widget values, between each other, and also between other things, such as objects, hash tables and etc. In a certain sense, the engine can be thought of as an Object-to-Relational Mapping (ORM), mapping SQL to several object systems, including Glib GObjects and QOF. This engine has been designed so that it becomes easy to add support for all kinds of new object systems: i.e. for the engine to be a generic re-mapper between not just SQL and GTK but between many different types of object systems and data sources/sinks.
Built on top of this engine is a DWI application that parses an XML-based file, the "DWI file", that describes the connections between glade widgets (or objects in general) and database tables. Currently, the only way to create DWI files is by hand. Unfortunately, this can be a fairly long and laborious process itself, especially when creating something a bit more sophisticated. In the future, we hope to have an extension to Glade, or possibly an extension to a database-browsing tool that will allow you to graphically make such connections. (Work has begun on such a tool, written in DWI itself).
The grim reality is that DWI wont ever become popular without a graphical designer. Although fairly complex apps can be readily created using DWI, it does have a non-trivial learning curve. When we say "can be created quickly", we mean "days" or "weeks", as opposed to "months" for traditional database application development cycles. Graphical RAD tools have a way of being brainlessly pleasant to use, and give the impression of an even faster development cycle, even though the learning curve is identical.
Note that the design of the XML format is sufficiently generic that it is not directly tied to Glade. It should be straightforward to adopt other ORM markups to inter-operate with the DWI engine. It is also envisioned that other GUI object systems, such as PHP, could be used with DWI, so as to create data-driven web pages. That is, Glade is currently the only GUI driver, but other drivers for other GUIs should be possible.
Enhancements:
- Changed to use automake Makefile system for easier installs; make install target now works.
- Segregate gtk and qof features to own subdirectories, so that apps which do not nead gtk do not need to link to the gtk libraries.
- Add support for QOF objects, including multiple examples of using QOF.
- Finish modularize of the SQL db drivers, so that only the required driver is actually loaded.

3dFB is a 3d File Manager / Browser. It was started in 2004 by Roy El-Rayes.
The aim of this project is to make a viable, workable, 3d file manager that is not a hog on resources and can actually be usable.
Main features:
- Mouse Movement
- Level Zoom
- Ability to show different types of information about a file by pressing tab
- Fog
- 2 Different Views
- Copy / Move / Delete File
- Fullscreen support
The current set of keys are as follows:
- w : activates mouse-move
- q : zooms to end of level
- a : zooms to middle of level
- z : zooms to front of level
- tab/ctrl-tab : switches between different information for each file
- g : turns fog on/off
- v : switches views between normal and top-down
- page-up, page-down : changes our current level
- left, right, up, down : changes your location in the 3d world
- c : copy a file
- m : move a file
- d : delete a file
- f : fullscreen
- escape : exit
- n : show names on current level
- o : show all names

Yasm is a complete rewrite of the NASM assembler under the "new" BSD License (some portions are under other licenses, see COPYING for details).
Yasm project is designed from the ground up to allow for multiple assembler syntaxes to be supported (eg, TASM, GAS, NASM etc.) in addition to multiple output object formats and even multiple instruction sets. Another primary module of the overall design is an optimizer module.
The core focus of Yasm is not the "yasm" commandline frontend; rather, it is the Libyasm library and associated LoadableModules? (see the ProgrammerReferences for documentation).
Libyasm and the modules are intended for reuse in other sorts of programs dealing with code at the assembly level (compilers, debuggers, etc). Someday, libyasm may be packaged separately from the rest of Yasm.
Key Current User-Visible Yasm major features:>
- Nearly feature-complete lexing and parsing of (preprocessed) NASM syntax?.
- AMD64 support (enabled using "BITS 64" and "-m amd64" option)
- 64-bit (and larger) integer constants allowed (including math operations).
- Internationalization support via GNU gettext.
- A simple 2-pass optimizer (its a bit better than the NASM one).
- The "real" NASM preprocessor (imported from NASMs source tree).
- Binary object file? output (NASM style).
- COFF object file? output, for use with DJGPP.
- Win32 object file? output (including Win64/AMD64 support).
- STABS debug format?.
- ELF32 and ELF64 object file output. No debugging information included at this point.
- Portability; currently compilable on:
- UNIX and compatibles (FreeBSD and Linux tested, GNU configure based autoconfiguration)
- DOS (using DJGPP)
- Windows (using Visual C++ or CygWin).
Key Internal Main features:>
- A NASM syntax parser written in yacc. This simplifies the source code and increases performance: yacc-generated parsers are almost always faster than hand-written ones. Also, yacc (and its GNU implementation, bison) is an extremely well-tested and well-documented tool.
- Architecture-specific instruction parsers hand-written for simplicity and size, as well as to make it easy to add additional architectures while retaining the same front-end syntax. The blend of yacc for syntax and a hand-written parser for instructions strikes a great balance between the strengths and weaknesses of each approach.
- A NASM syntax? lexer written in re2c. A highly efficient scanner generator (almost always faster than lex/flex), its also very embeddable due to its code generation methodology, allowing a number of re2c scanners to be used in various places in yasm without any worries about naming conflicts.
- Many of the modular interfaces at least superficially finished. This is still an area that needs a lot of work.
- A small set of portable equivalants of useful functions that are standard on some systems (detected via configure), such as the queue(3) set of functions, strdup, strcasecmp, and mergesort.
- A decent (and growing) set of assembler test input files to test the entire assembler as well as specific modules.
Important Differences from NASM:
- Yasm defaults to reading from standard input if no files are specified. When an input file is specified, Yasm behaves like NASM.
- A number of command line options are different. Run "yasm --help" for a quick command line option summary, or read the full yasm(1) manpage for detailed descriptions of all command line options.
Enhancements:
- This release adds SSE4.1 and SSE4.2 instruction support, a .set directive in the GAS parser, and allowing Mach-O custom sections.
- Bugfixes include fixes to AMD Pacifica (SVM) instructions, absolute section handling, RIP-relative cross-section references in bin output, and many others.