Hi there, As many of you know this is the official create an ASM IDE year! j/k (So said Iczelion) I like the fact that we are going to end up with 20 choices of developement environments, however the only problem I see in the future is everyone's workspace/project file formats will be different so you'll download an assembler lesson/tutorial/example and won't have the tools to use it! I hereby propose that we as the assembler community promote a file format standard for the ASM IDE's, this way users have the option of using whichever editor they prefer. We already have standards for *.rc, *.asm, *.hpp and several others, so they should already be compatable with that, but we should pick an extension for the workspace files and project files. A workspace file would simply include a list of project files and some extra information like the original ASM IDe used to create it and some extra variable space for whatever that IDE want to use it for (Like Toolbar visible state, and all those others...) The project file format would basically list source files that project uses as well as the settings for that project like compiler options, etc... Anyone other than me think this would be a good thing to promote the assembler community? Post your ideas, maybe someone would like to start a homepage for the official file format standard? See ya, Ben
Posted on 2001-02-23 19:17:00 by cyberben
An excellent idea. This way we at least can share projects across the multitude of IDE's. I would guess any IDE not conforming will tend to wither away (unless it's other features are so compelling that IT ALONE becomes the defacto standard). So, here's my thoughs on where I was heading Source: All source files shall be unmodified ascii text files. Period, no exceptions, no "commented stuff so it's hiddin from the compiler" info. Projects: All Project files shall be ascii text files with the following attributes: 1) They shall follow the standard .ini file format. Thus all information shall be readable, and editable in any text editor. 2) The Project file itself shall have an extension of (to be determined). 3) A project shall consist of a collection of Source files. 4) As a minimum, each Source file shall have it's filename defined. 5) An optional Source filepath param is allowed. If NULL or not included, the same path as the Project file shall be assumed. 6) An optional Author field is allowed. 7) An optional Comment field is allowed. 8) An optional Date Created field is allowed. 9) An optional Last Date Changed field is allowed. 10) An optional Build Rule field is allowed. 11) An optional Link rule for the resulting build products. 12) (Edited addition) An optional Folder (or catagory) feild is allowed. Workspaces: All Workspace files shall be ascii text files. Workspace files conform to the same specfications as Project files, with the following additions: 1) The Workspace file itself shall have an extension of (to be determined) 2) In addition to a file collection, they shall also hold a collection of Project files. Note this means that a Workspace may contain several Projects and also several files unattached to any Project. Projects are self-contained files, IE, they exist outside the Workspace, such that a Project may be loaded independent of it's workspace. Thus, several independently built projects may be collected into various Workspaces to build large projects from smaller chunks of code. As to the visual aspects of the IDE, these might be so varied as to be a complete mess for standardzation. For example, it is silly to define a feild for StatusBar visibility as it assumes the IDE has a StatusBar. It also limits one to a single StatusBar. The goal is to build projects. Controlling the IDE to reset itself as one left it should be purely a function of the IDE itself (and not the Workspaces and Projects). If it is assosciated with these files, don't try to standardize it. Anyone else? :-) This message was edited by Ernie, on 2/23/2001 8:53:14 PM This message was edited by Ernie, on 2/24/2001 8:25:37 AM
Posted on 2001-02-23 20:51:00 by Ernie
Maybe it should have a section, which would be mandatory, where the IDE writes some standard info about the project (Author, IDE Name, etc...). Then comes the section which of course contains the source files, inc's (if necesary). Then the section containing the building rules for each file, and for the whole project (linking, resources, etc...); this section could be optional if the building rules where standard (whatever that is). In addition to the "standard" sections there could be an IDE-specific section, which could be used to save proyect-specific options (toolbars, fonts, colors, whatever). But for compatibility's sake (that's the whole idea) any IDE should ignore those sections that it doesn't understand instead of halting on them (much like the C/C++ #pragma's). This would help to keep the IDE looks for a specific project within the project (and not using yet another file), but at the same time it won't get in the way of the "standarized" project files. One last thing, the IDE should _never_ assume the path it resides in. I say this because the one I use (VisualASM....it's great so far) did that in the last version I installed (now I just decompress it from a zip I made), it assumed C:\VisualASM, even when it was installed elsewhere, and that was what was written to the project file. Something similar applies to the Workspaces files, a section, a section an some IDE-specific section. As usual, the IDE should ignore those sections that it doesn't understand. Right now I can't even think in writing an IDE myself, but maybe I can before end of this year, to take advantage of the "YAIDE (Year of the Assembler IDE)" =). Bye... This message was edited by GogetaSSJ4, on 2/23/2001 11:17:30 PM
Posted on 2001-02-23 23:14:00 by GogetaSSJ4
A standard for project files sounds like a good idea. I think we should all chat on irc efnet sometime to work this out... but then you come into conflict of ideas... lets take a tally of all people creating an IDE... and we could have some kind of vote that could last for a week, that members could view the format and vote... or perhaps we could all come to an agreement on something. My format is as follows: AUTHOR=Jon Richardson NAME=yousuck OPERATING SYSTEM=Windows LAST SAVED= <--- isn't really needed, you can get the file time CREATED= <-----| ACTIVE=Release CONFIG1=Release CONFIG2=Debug FILE1=C:\WINDOWS\Desktop\AsmStudio\Projects\yousuck\WordEdit.asm FILE2=C:\WINDOWS\Desktop\AsmStudio\Projects\yousuck\WordEdit.inc FILE3=C:\WINDOWS\Desktop\AsmStudio\Projects\yousuck\MRUFiles.asm FILE4=C:\WINDOWS\Desktop\AsmStudio\Projects\yousuck\3dframes.asm FILE5=redit.ASM FILE6=C:\WINDOWS\Desktop\AsmStudio\Projects\yousuck\System32.asm for the file part, the ones without the path are in the project directory. Any more ideas on standards? Jon Richardson
Posted on 2001-02-24 18:04:00 by Jon Richardson
Don't forget to ignore unknown sections. I'm sure there will be different features in each IDE: this is like HTML: you work only with the tags you know and ignore the ones you don't.
Posted on 2001-02-24 19:11:00 by Iczelion
Yuppers. Iczelion has got it! My ASM webpage is just being put together now and should be up by mid next week. I'll host a small page with the ASM IDE file format standrds. Thanks for your guys' ideas and support for the idea! I'll post when the site is up next week with a beta version of the standards then we can hash it out from there... See ya, Ben
Posted on 2001-02-24 20:01:00 by cyberben
Is anyone integrating a dialog editor within their IDE? This might be an area where a stand alone dialog editor in a dll might be a better choice. I feel there are probably more varied tastes in ones Project manager/editor than in Dialog editors?? This way one can pick (or build) their ide but have a standard Dialog editor. I know from experience that a Dilaog Editor is a much more daunting task than and editor/project manager. James
Posted on 2001-02-24 21:07:00 by jcfuller
Do we at least have a consensus on the file format? .ini files for everyone? (BTW, I'm putting my GUI persistent stuff in the registry, NOT the project files. That should be proprietary to each app)
Posted on 2001-02-24 21:32:00 by Ernie
I agree that there should be a standard. I think .INI files are a great idea. That's what I'm currently using in my IDE. I do not like to pollute the registry any more than necessary. Plus, they are simple to modify from any outside editor. Having only certain sections within the INI files be standard is the way to go. This will give enough freedom, at least for me, to include proprietary information. The visual dialog designer (form designer) uses a binary format for speed; but, saves dialog information in text files. Later, the .RC script will be the end result. :) This message was edited by Thomas Jaeger, on 2/25/2001 11:18:57 AM
Posted on 2001-02-25 11:17:00 by rainbird
use XML for the file format it allows for all of the above better then ini
Posted on 2001-02-25 11:35:00 by SGML
Well I checked out XML at wotsit.org (which actually links to the page of the people who document that standard) but I don't like it. It's more like HTML, we don't want to have all that complexity of HTML, just simple headers with sub sections. I think INI files are the way to go. Thanks fo rthe suggestion anyhow. See ya, Ben PS Anyone else want to check out ini files go here: Wotsit.org and search for XML.
Posted on 2001-02-25 16:13:00 by cyberben
XML is ugly, it adds too much complication and overhead without any real benefits. Not using the registry is a really good thing. IMHO, the registry is overused, and considering it's locked in memory, I tend to dislike apps that store a lot of information there. Clearly the format has to be easy-to-read-and-edit text, but does it *have* to be INI file? The disadvantage of INI is that it is limited to "property=value", you can't just have a section of filenames without having to resort to "file00=filename", "file01=filename", and so on. This isn't a very big problem, but it does look ugly :). In any case, the format has to be tight and well defined (so all IDEs can parse all other IDEs workspace files). Make the format generic enough to be used by other IDEs than asm IDEs as well, and something good might happen.
Posted on 2001-02-26 04:11:00 by f0dder
Sections for each IDE, as well as general requirements. The IDE could have a choice to load the envirnoment settings for itself as well as supporting other IDE settings. bitRAKE


path='C:\MASM32\Projects\Hello World\'

file1='Hello World.asm'
file2='C:\MASM32\Projects\Hello World\Menu.asm'

created=November 12, 1984


Posted on 2001-02-26 15:48:00 by bitRAKE
The problem with the ... idea, is that after we have 20 IDE's in circulation using this standard, lets say I use an IDE for a project, and then some other IDE has functionality I need, so I load it up with that... then a few other IDE's the same thing, then I have a bloated project file with info that may or may not be relevant to my primary IDE... solution to that is manually edit them out, don't open it in another IDE, deal with it, or provide an option to not write IDE specific info (which I doubt people will provide)... If it can be made to be generic enough to make every IDE happy, then some control will be lost. I like the idea personally, but I also see it becoming a problem. My IDE for one, would have a hard time with it. Mine is just an IDE with a few files explaining what assembly is, or C, or whatever language/syntax. No "one" project file can cover all. Or maybe it's just me. Regardless, I still see it becoming a problem at some point. If people are happy with it, it will still be spoken of to have "limitations". The standard at some point will have to keep expanding to meet needs, or stop to retain compatibility, or IDE's go their seperate way. _Shawn
Posted on 2001-02-26 16:03:00 by _Shawn
I thought that this idea would allow both compatiblity and expansion, but I guess you missed that :P bitRAKE
Posted on 2001-02-26 21:24:00 by bitRAKE
Shawn Bullock: You must not have read the entire thing. 1.) You wouldn't store ALL of your IDE's info in these files, just the project organization stuff. 2.) Even if we had a section and you had 20 of those sections in your project, let's say each IDE add 10 values under it's bracket, each 50 characaters long the entire project wouldn't increase by much over 1kb!! That's nothing compared to some of the large source files and resources. The windows include alone is many times this! Wait for the hosting web page to go up (soon I hope) then we will gather ideas better than these long postings... See ya, Ben
Posted on 2001-02-26 22:08:00 by cyberben
ini files are old and not very extendable. XML as posted above is harder but very moldable without loosing integrity. I would not give up on XML yet if I were you. It has many advantages over flaky HTML.
Posted on 2001-02-27 02:10:00 by Hiroshimator
Argh. Forgot to fill in my username, so I'll just have to write all this up again. Let's see if I can remember it. (Using notepad now). INI-style config is limited. It's fine when you only need to specify simple things like filename and so on. But what when you need more complicated things, like storing build rules? The INI file solution would (as I can imagine it) be pretty ugly, since you need some object/property multi-level stuff...

environment {
  "project" = "d:\src\proj\crackme2";	// project root
  "MASM" = "c:\masm";			// path to masm install

buildrule {				// define a buildrule
  name = "masm";			// used to reference later on
  command = "$(MASM)\bin\ml.exe $(MASMOPTS) %1";	// the commandline. $() are expanded...

folders {
  folder {
    parent = root;
    name = "ASM files";
  folder {
    parent = root;
    name = "Resources";

files {					// a list of files
  buildrule = "masm";			// the rule used to build
  folder = "ASM files";			// used to structure your project view

  file {				// a single file entry
    name = "cpucore.asm";
    open = false;			// is this file open in the editor view?

What do you think? Sure, this looks a lot more complicated than INI files... and it is. But it's a very strict & logical format, and a lot easier to parse than XML. If you see a keyword you don't understand, you skip from the opening brace to the closing brace. An unknown property (or equation, if you want) is skipped on a line-basis (logical line (semicolon-separated)). To make an approach like this work, there will have to be an agreement on standard "objects". "files" is probably the most important one :). "folders" and "buildrule" are very very very helpful, but not critical to the function of the IDE, if it handles these things by looking at filetypes. "environment" is also probably a good thing to have, for general environment stuff :). What do you think?
Posted on 2001-02-27 04:12:00 by f0dder
BitRake, CyberBen, no, I did not miss something. INI files, themselves, are genarally inflexible. It might provide Compatibility to a very limited level, but I don't think it'll allow expansion very well... not without having strict rules to follow. Something if which, I think only a few poeple will support (I could be wrong) in the long run. Yes, you could say Name=main.asm Path=C:\masm32\my projects\test\ Build=.... .... Yes, it'll work, Windows has built-in functionality for working with it, but I don't see it as having any flexibility. Something everyone has to agree on, and my ideals of a particular might be different. Then I've broken compatibility or sacrificed my ideals for sake of compatibility or I define it twice, both way, to make everyone happy. I like fodders idea. I actually started using INI files for my project format, but as far as I've come along (not that anyone has seen :( ) I've encountered too many limitations and concerns that are causing me to rethink my project file format. If the spec was simple and clear enough, I might support it. But as it stands, everytime I use INI files, I encounter too many limits once I start expanding my scope and requiring more flexibility. _Shawn
Posted on 2001-02-27 10:52:00 by _Shawn
well that's where XML is supposed to take over. You don't have to write a parser for it, they already exist and it's extendable while still able to enforce a certain data-format I'm nagging about this, but this situation is exactly what XML is for.
Posted on 2001-02-27 12:15:00 by Hiroshimator