Assembler Directives without a dot - masm32

I recently started to learn MASM and was wondering why some of the Assembler Directives (like OPTION or include) don't start with a dot. Does the dot have a specific meaning or is that just due to inconsitent naming conventions?
Thanks in advance,
CloseButABanana

Related

How to deobfuscate AS3 source code?

Is there a way to de-obfuscate AS3? With de-obfuscation I mean making it compilable again. At this moment I lost some source code and only have the Flash file left. The problem I now face is that the compiler is not able to compile it as the class names contain illegal characters.
I could start manually naming all classes again however I'm not even certain if the de-compiler worked.
To compile the SWF again I use flash develop and the FlashSDK.
Regards.
This depends on how the code was obfuscated to begin with. If it was simply obfuscated by changing class/variable/function names, then you could use an IDE such as FlashDevelop which allows you to Refactor->Rename by right clicking the instance name which would rename it across the entire project. Or just do a simple find/replace using a text editor.
Knowing how the code was obfuscated is the most important thing though. Whichever program you used to obfuscate is probably going to provide you with the most information.
I would suggest, however, doing the bare minimum by removing all illegal characters first to see if it will compile.

Can I write a program in binary directly ? How can I get the computer to execute it?

I know that may seem weird and looking for troubles but I think experiencing what the ancient programmers experienced before is something interesting. So how can I execute a program written only in binary? (Suppose that I know what I am doing and not using assembly of course.)
I just want to write a series of bits like 111010111010101010101 and execute that. So how can I do that?
Use a hex editor. You'll need to find out the relevant executable format for your operating system, of course - assuming you want to use an operating system... I suppose you could always write your own bootloader and just run the code directly that way, if you want to get all hardcore.
I don't think you'll really be experiencing what programmers experienced back then though - for one thing, you won't be using punch cards, paper tape etc. For another, your context is completely different - you know what computers are like now, so it'll feel painfully primitive to you... whereas back then, it would have been bleeding edge and exciting just on those grounds.
Use a hex editor, write your bits and save it as an executable file (either just with the file extension .exe in Windows or with chmod a+x filename in Linux).
The problem is: You'd also have to write all the OS-specific stuff in binary format, and you'll have to have a table that translates from assembler code to binary stuff.
Why not, if you want to experience low-level programming, give D.E. Knuth's assembler MMIX a try?
It really depends on the platform you are using. But that's sort of irrelevant based on your proposed purpose. The earliest programmers of modern computers as you think of them did not program in binary -- they programmed in assembly.
You will learn nothing trying to program in binary for a specific Operating System and specific CPU type using a hex editor.
If you want to find out how pre-assembly programmers worked (with plain binary data), look up Punch Cards.
.
Use a hex editor to create your file, be sure to use a format that the loader of your respective OS understands and then double click it.
most assemblers (MMIX assembler for instance see www.mmix.cs.hm.edu) dont care if
you write instructions or data.
So instead of wirting
Main ADD $0,$0,3
SUB $1,$0,4
...
you can write
Main TETRA #21000003
TETRA #25010004
...
So this way you can assemble your program by hand and then have the assembler transform it in a form the loader needs. Then you execute it. Normaly you use hex notatition not binary because keeping track of so many digits is difficult. You can also use decimal, but the charts that tell you which instructions have which codes are typically in hex notation.
Good luck! I had to do things like this when I started programming computers. Everybody was glad to have an assembler or even a compiler then.
Martin
Or he is just writing some malicious code.
I've seen some funny methods that use a AVR as a keyboard emulator, open some simple text editor, write the code that's in the AVR eeprom memory, and pipe it to "debug" (in windows systems), and run it. It's a good way to escape some restrictions too ;)
I imagine that by interacting directly with hardware you could write in binary. To flip the proper binary bits, you could use a magnetized needle on your disk drive. Or butterflies.

Cannot decide a proper namespace for 'Character'

I am building a game engine, and I am actually having a very difficult time placing what kind of namespace to put Character under. This may be the single dumbest question I've ever posted on StackOverflow, but it's driving me nuts.
What would you guys do?
I don't really have any other namespaces yet defined. Characters have Sheets (Layout), which reference Traits (Statistics), etc. Everything is just kind of dumped into the root namespace right now.
Go with Characters.
It's simple and to the point. You'll end up including lots of classes in it that describe player and non player characters, attributes, abilities, and so on, but they all refer to characters. Your base class for characters will likely be something like Character, so the naming collision is avoided.
And the guideline to avoid plurality in namespaces is just a guideline. There are cases where deviation is warranted (I'm looking at you, System.Windows.Forms).

Are functions declared before or after calling them?

I was looking through someone's code one day and I was annoyed how they declared all their functions first and then later called them below. I guess I'm use to Visual Studio's automatically generated functions, that are made after you call them- and I was wondering, which way do you prefer? Or is there a standard on these kind of things?
I'm not sure what you mean by this. In C and C++, a function must be declared before it is called, otherwise the compiler won't know how to verify your arguments and return values.
I don't think it matters as the functions are all loaded into memory before execution begins. It's mostly a matter of style.
Personally I put miscellaneous functions that aren't part of a class definitions at the bottom of my code so it's easier to read.
That's just my $0.02 though.
Whatever Visual Studio do automatically can be considered a Microsoft standard. Not always the best standard, but a standard anyway =)

What are common conventions for using namespaces in Clojure?

I'm having trouble finding good advice and common practices for the use of namespaces in Clojure. I realize that namespaces are not the same as Java packages so I'm trying to tease out the conventions in Clojure, which seem surprisingly hard to determine.
I think I have a pretty good idea how to split functions into clj files and even roughly how I'd want to organize those files into directories. But beyond that I'm having trouble finding the mechanics for my dev environment. Some inter-related questions:
Do I use the same uniqueness conventions for Clojure namespaces as I would normally use for Java packages? [ie backwards-company-domain.project.subsystem]
Should I save my files in a directory structure that matches my namespaces? [ala Java]
If I have multiple namespaces, do I need to compile all of my code into a jar and add it to my classpath to make it accessible?
Should each namespace compile to one jar? Or should I create a single jar that contains clj code from many namespaces?
Thanks...
I guess it's ok if you think it helps, but many Clojure projects don't do so -- cf. Compojure (using a top-level compojure ns and various compojure.* ns's for specific functionality), Ring, Leiningen... Clojure itself uses clojure.* (and clojure.contrib.* for contrib libraries), but that's a special case, I suppose.
Yes! You absolutely must do so, or else Clojure won't be able to find your namespaces. Also note that you musn't use the underscore in namespace names or the hyphen in filenames and wherever you use a hyphen in a namespace name, you must use an underscore in the filename (so that the ns my.cool-project is defined in a file called cool_project.clj in a directory called my).
You need to make sure all your stuff is on the classpath, but it doesn't matter if it's in a jar, multiple jars, a mixture of jars and directories on the filesystem... As long as it obeys the correct naming conventions (your point no. 2) you should be fine.
However, do not compile things ahead-of-time if there's no particular reason to do so -- this may prevent your code from being portable across various versions of Clojure without providing any benefits besides a slightly improved loading time.
You'll still need to use AOT compilation sometimes, notably in some Java interop scenarios -- the documentation of the relevant functions / macros always mentions that. There are examples of things requiring AOT in clojure.contrib; I've never needed it, so I can't provide much in the way of details.
I'd say you should use jars for functional units of code. E.g. Compojure and Ring get packaged as single jars containing many namespaces which together compose the whole package. Also, clojure.contrib is notably packaged as a single jar with multiple unrelated libraries; but that again may be a special case.
On the other hand, a single jar containing all of your project's code together with its dependencies might occasionally be useful for deployment. Check out the Leiningen build tool and its 'uberjar' facility if you think that sort of thing may be useful to you.
Strictly speaking, not necessary, though many Java projects have dropped that convention as well, especially for internal projects or private APIs. Do avoid single-segment namespaces though, which would result in classfiles being generated in the default package.
Yes.
Regarding 3 & 4, packaging and AOT compilation are entirely orthogonal to the question of namespace conventions.