My FirstOS

[DavidCooper]

I don't see how MASM32 forbids developing operating systems. It forbids developing "software for Non-Microsoft Operating Systems". I am not doing that. I am not developing software thats runs in an operating system, therefore I am not developing software that runs in a non-Microsoft operating system. (Since a non-MS OS is an OS.) The only thing I can see that would be restricting me is using MASM32 for developing software for my operating system.

What name did you give this thread? Looks as if everything you've been doing here is specifically for an OS that isn't Microsoft's. If you're using MASM rather than MASM32, that shouldn't be a problem though.

[gerryg400]

I don't see how MASM32 forbids developing operating systems. It forbids developing "software for Non-Microsoft Operating Systems". I am not doing that. I am not developing software thats runs in an operating system, therefore I am not developing software that runs in a non-Microsoft operating system. (Since a non-MS OS is an OS.) The only thing I can see that would be restricting me is using MASM32 for developing software for my operating system.

You bootloader is " software for Non-Microsoft Operating Systems. ". I think MS will will strike down upon thee with great vengeance and furious anger. Check with your lawyer.

[kendfrey]

I am using MASM32.
I think I see your interpretation of the license. You are saying my bootloader is software for FirstOS, because it was designed "for" FirstOS.
I read "software for a non-Microsoft OS" as meaning "an application (or other code) that would run on an operating system that was not made by Microsoft". My OS does not fall under that category, since it does not run on an OS, it is the OS.
Oh, well, maybe yet another reason to use something else.
I will stop using MASM32, I think. Any recommended assemblers?

[JAAman]

You bootloader is " software for Non-Microsoft Operating Systems. ". I think MS will will strike down upon thee with great vengeance and furious anger. Check with your lawyer.

wrong... MS has nothing at all to do with MASM32, and wont care one little bit if you violate its license or not...

you will never find such restrictions on MS tools... MASM, VS, VC++, etc, all are fully usable (although unpopular choices) for OSdev

I will stop using MASM32, I think. Any recommended assemblers?

MASM -- this is basically what you are using now (MASM32 uses MASM, MASM32 is not an assembler, its an add-on for MASM) which is a free download from microsoft website, or included free with all versions (including the free express edition) of Visual Studio -- note however, that commercial use is forbidden for free versions -- but this probably wont bother you

NASM, -- is probably the most popular assembler (and thus will be the most well understood and will likely get the most help with it should you have trouble)

FASM -- heavily advocated by certain people here on this forum

YASM -- dont know much about this one, but iirc it was a splinter off from NASM

AS -- this is the assembler used by GCC


at the risk of intense flaming, i would recommend NASM (although, if you are using GCC, AS is a valid alternative, though not one i would choose)

[DavidCooper]

NASM seems to be mentioned here a fair bit (http://www.nasm.us/), but you should wait until you get more replies before you decide. The wiki has pages about GNU as (GAS), FASM, NASM and YASM, so read them all while you're waiting.

[NickJohnson]

I personally use NASM, but that is mostly because I haven't tried anything else. If your OS is going to be mostly in some high level language like C (mine is), the choice of assembler is pretty unimportant as long as it works, so you might as well go with the most popular one (i.e. NASM). If you are going to be writing everything in assembly, however, then it would be wise to do some research.

[piranha]

I think MS will will strike down upon thee with great vengeance and furious anger.

And I will strike down upon the thee with great vengeance and furious lawsuits, those who would attempt to make a non-MS bootloader! And you will know my name is Microsoft!
*Gun shots*

But yeah, I don't think they'll care much unless the bootloader becomes big...also, why make it specifically non-MS? Also, Windows has it's own bootloader. So it doesn't really matter.

-JL

[Chandra]

Any recommended assemblers?

I use NASM for my booloader and GNU Assembler(GAS) for assembly stuffs in my kernel. However, I'd recommend NASM because it follows Intel sytax and you won't have further problem with the Manual and Assembler compatibility.

[Combuster]

YASM -- dont know much about this one, but iirc it was a splinter off from NASM

Far from it. It's essentially the most modern assembler design out there which happens to support NASM syntax as a feature (most of the fandom comes from the fact that it beat NASM to 64-bit support by at least a year, and that it can be used as the GCC backend as if it were GAS without the GPL. The binaries differ by a factor 10 in size though). I originally switched to YASM because of crashbugs in NASM.

I have the habit of mentioning NASM/YASM as an equivalent pair because in general practical use it just works that way, and either is a excellent choice of intel-syntax assembler. It is also the best understood and supported syntax dialect on the forums. I personally recommend YASM for its higher quality and overcapacity which you might end up using later, but will most assuredly not complain if you stick to grandpa NASM like the established (and sometimes, poorly informed) majority.

FASM is a typical case of YMMV and has its specific uses, but has a record to really confuse people when the pseudo-ops gets interpreted as NASM syntax which thereafter make no sense (if you post FASM code, mention it!).

GAS is for the ones that delight in talking swedish</troll> and the fact that you can't use the processor manuals as a reference making it an especially bad choice for beginners. If GAS is the right choice, you'll know it. When in doubt, don't.

I would not recommend any of the others, and I think this thread's predecessor is an excellent example as to why.



tl;dr: get YASM.

[rdos]

I'll stick to assemblers that are compatible with MASM/TASM, and thus won't bother with NASM or GAS, since they are not really Intel-syntax compatible, and also will not even warn when they misinterpret MASM/TASM syntax for something completely different. BTW, I use WASM today, but started out with MASM, then TASM.

[Brendan]

Hi,

What I'm about to say is just my opinion, based on my experiences with assemblers in the past. Different people have different opinions and different experiences, and in no way is this post meant to reflect "the one true way" or anything like that.

First, I'd deliberately avoid MASM (and TASM when used in "MASM mode"), and any other assembler that exhibits context sensitive behaviour (A86/A386, WASM, JWASM). For example, for something like "mov eax,foo" MASM may generate different instructions depending on how "foo" was defined. One of the greatest advantages of assembly language is that the source code directly and unambiguously represents the resulting machine code (and the disassembly you'll see when debugging); and this context sensitive behaviour destroys that advantage (and can lead to unnecessary confusion because you can't know what some lines of source code actually do without searching for other information that may be in other source files).

If you're using inline assembly you have to use whatever makes your compiler happy. Given the "avoid MASM" restriction, this may mean switching to a different compiler in some cases (but you can't port a closed source compiler to your OS later anyway, so switching to something like GCC or CLANG would probably be an advantage anyway).

If you're not using inline assembly, then GNU AS is a pain in the neck. The pre-processor is inadequate for anything complex and it's "Intel syntax" mode has quirks. AT&T syntax is verbose, confusing and doesn't mirror what you'll see in Intel or AMD manuals. It also has difficulty with a few "tricky" things (like mixing 16-bit, 32-bit and 64-bit code in the same binary). I've also had problems with the quality of the error messages (but I've heard that's improved since). Basically AS is great for a back-end for a compiler (in the same way that an arse is a great back-end for a horse ).

TASM is not open source and you can't port it to your OS later, so strike it off your list.

I haven't used FASM much. It seems fine and does work correctly (as far as I know). However, if you ever see the source code for FASM you will puke your guts up (it's an unmaintainable/uncommented disaster, and I can't help wondering when it's going to fall to pieces).

That leaves NASM and YASM (in "Intel syntax" mode). These both use exactly the same pre-processor, the same syntax, etc; and you can freely switch between them with little or no problems at all. This is a good thing (it means your code isn't locked in to a specific assembler and you won't be screwed if there's ever any problem and you want to switch).


Cheers,

Brendan

[rdos]

First, I'd deliberately avoid MASM (and TASM when used in "MASM mode"), and any other assembler that exhibits context sensitive behaviour (A86/A386, WASM, JWASM). For example, for something like "mov eax,foo" MASM may generate different instructions depending on how "foo" was defined.

That is a problem that is easily handled with coding-rules. Whenever a memory location is referenced, ALWAYS add the segment-register used in addressing. That would be "mov eax,ds:foo", which the assembler always genererates the same code for. When the intention is to reference foo as an offset, ALWAYS use the "offset" operator, which would be "mov eax,OFFSET foo". Never, ever, rely on "assume" directives. If foo is a numerical value, define it with "=" and use it as a constant like this: "mov eax,foo". Once these coding rules are followed, there is no problem with MASM/TASM/WASM mode.

If you're using inline assembly you have to use whatever makes your compiler happy. Given the "avoid MASM" restriction, this may mean switching to a different compiler in some cases (but you can't port a closed source compiler to your OS later anyway, so switching to something like GCC or CLANG would probably be an advantage anyway).

Not possible. I'm not aware of any non-MASM inline syntax C compiler that can handle segmentation.

TASM is not open source and you can't port it to your OS later, so strike it off your list.

WASM is, and it is largely MASM/TASM compatible.

That leaves NASM and YASM (in "Intel syntax" mode). These both use exactly the same pre-processor, the same syntax, etc; and you can freely switch between them with little or no problems at all. This is a good thing (it means your code isn't locked in to a specific assembler and you won't be screwed if there's ever any problem and you want to switch).

How about switching MASM/TASM/WASM compatible code to NASM? Previously, this was no possible since when using the above syntax, NASM would misinterpret it as "mov eax,OFFSET foo", which in many cases was not correct. Adding the above rules does not help much in porting either.

I would have prefered a new syntax, where only constants defined with "=" could be referenced with "mov eax,foo", and where all references to a structure member / EQU define / segment variable would require either explicit use of a segment-register when referencing it as a variable, or would require offset references with "OFFSET" operator. Adding brackets (NASM-style) could be an option, but segment-register should still be required. Even simple things like "mov eax,[ebx]" should be invalid and should be "mov eax,ds:[ebx]. Then the assume operator would have to go, as it would serve no function. Code written for this syntax would be clean and portable.

Another construct has to do with string operations. It would be required to always give segment-registers like this: "movs dword ptr es:[edi],fs:[esi]". Some assemblers (notably WASM) doesn't check the operands properly if not done like this, and might produce unexpected code.

The assembler would know itself when the segment override is default behavior, and would then not generate an override. Coders should not need to bother with that issue.

[Casm]

Also note that MASM license explicitly forbids to use it for OSdev.

No it doesn't. That applies to all the stuff which comes bundled with MASM32. Microsoft couldn't care less what we use there assembler for; I doubt if they are expecting any of our OS's to be competition for them.

[Coty]

What you CANNOT do with the MASM32 Project.

1. The MASM32 Project is not an item of trade or commerce. It cannot be either purchased or sold.
2. The MASM32 Project cannot be re-licenced or made subordinate to any other form of licence.
3. None of its components or source code are redistributable.
4. You cannot use the MASM32 Project to write software for Non-Microsoft Operating Systems.
5. You cannot use the MASM32 Project to write any form of illegal software.
6. The project does not authorise the use of the Microsoft Trademark in your software or claims that your software is certified by Microsoft.

I would think this means you can't use it for OS Dev... At the very least it means you can't write software for your OS with it...

[SDS]

What you CANNOT do with the MASM32 Project.
...
4. You cannot use the MASM32 Project to write software for Non-Microsoft Operating Systems.
...

I would think this means you can't use it for OS Dev... At the very least it means you can't write software for your OS with it...

Somebody has failed to read the other posts above. MASM != MASM32.