i want to learn how to make an os in pure assembly

[bzt]

bzt, you claimed wchar_t was an MSVC thing.

Never said that. Citation needed. I'm well aware the wc capabilities of libc because I had to implement those for POSIX-UEFI. BTW I don't care, because with transparent UTF-8 conversion this works out-of-the-box in POSIX-UEFI with char arguments.

I did show you examples with links, actually. Check out my previous post.

I'm asking specifically for examples of GCC or Clang mistakenly using a 32-bit wchar_t when targeting the Windows ABI.

Haha, funny. You can't target the Windows ABI with gcc, you have to create an ELF shared library and then convert that into PE using objconv. Otherwise you'd need a non-official gcc compiler, like cygwin or mingw for example (not part of GNU gcc, those are forks).

Show me where does the C standard allow defining strcpy with wchar_t for example.

Right here:

In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. Any library facilities available to a freestanding program, other than the minimal set required by clause 4, are implementation-defined.

The wording changes a bit depending on the draft you're looking at, but all of them say it's implementation-defined. GCC and Clang make no assumptions about C standard library functions in freestanding mode, aside from the four mem* functions, so you're free to redefine strcpy however you like.

First, it does not say that (where's that clause 4 they're referencing?).
Second, I've already said this, builtins are not working as they should be, just google about issues, you'll find plenty (gcc, Clang alike). It is not my job to teach you how to google, sorry.
Third, and most importantly, I don't care what's in the doc or what you're saying as long as my compiler are complaining. And it does if I'm not using the UTF-8 wrapper. End of discussion.

Cheers,
bzt

[nexos]

Otherwise you'd need a non-official gcc compiler, like cygwin or mingw

Actually MinGW is integrated with GCC. Just run ./configure --target=x86_64-mingw32 (probably some extra options are needed as well, you could look at ReactOS)

[Octocontrabass]

Haha, funny. You can't target the Windows ABI with gcc, you have to create an ELF shared library and then convert that into PE using objconv. Otherwise you'd need a non-official gcc compiler, like cygwin or mingw for example (not part of GNU gcc, those are forks).

Okay, whatever you say. Where are your examples of "hundreds" of people who have seen GCC or Clang default to 4-byte wchar_t when targeting the Windows ABI?

First, it does not say that (where's that clause 4 they're referencing?).

Yes it does. But you can find similar text in older versions of the standard as well, if C11 is too new for you. (Clause 4 is the section titled "Conformance" starting on page 8.)

Second, I've already said this, builtins are not working as they should be, just google about issues, you'll find plenty (gcc, Clang alike). It is not my job to teach you how to google, sorry.

I'm not asking for someone else's issues, I'm asking for your issues. Please, explain to me how built-in functions do not work the way the GCC and Clang documentation says they should.

Third, and most importantly, I don't care what's in the doc or what you're saying as long as my compiler are complaining. And it does if I'm not using the UTF-8 wrapper. End of discussion.

If the compiler is complaining, it's either a bug in your code or a bug in the compiler. Don't you want to fix the bug?

[bzt]

I'll answer one more time, but first I get my popcorn

Where are your examples of "hundreds" of people who have seen GCC or Clang default to 4-byte wchar_t when targeting the Windows ABI?

I though you said UEFI was designed for any C compiler and not just for Microsoft ABI only MSVC... We got into a little contradiction, aren't we?
But to answer to your question, not targeting Windows ABI, but compiling ELF shared object and converting to PE as last step. I guess you have never ever used GNU-EFI in your entire life, otherwise you'd know. Maybe you should read about the required knowledge?

First, it does not say that (where's that clause 4 they're referencing?).

Yes it does. But you can find similar text in older versions of the standard as well, if C11 is too new for you. (Clause 4 is the section titled "Conformance" starting on page 8.)

Ok, I ask again, this time slowly so that you can understand Where does that spec list the names of functions which are minimally required? On page 8 or on any other page? (It just lists C headers, string.h not among them, yet memset is a builtin and a required minimal function in all compilers for example). Maybe you should read about the required knowledge?

I'm not asking for someone else's issues, I'm asking for your issues. Please, explain to me how built-in functions do not work the way the GCC and Clang documentation says they should.

Use the source Luke! Clang has builtin_strlen for example, any many other string functions, see tests here, neither accepts wchar_t as argument, and there's no builtin for wclen or mbstowcs for example. Maybe you should read about the required knowledge?

If the compiler is complaining, it's either a bug in your code or a bug in the compiler. Don't you want to fix the bug?

Neither. It is perfectly normal if the compiler complains about "strcmp(wchar_t *s1, wchar_t *s1);", and it's not a bug. And I'll try to write slowly so you can comprehend: I don't care, since I've implemented UTF-8 wrapper

Cheers,
bzt

[Octocontrabass]

I though you said UEFI was designed for any C compiler and not just for Microsoft ABI only MSVC... We got into a little contradiction, aren't we?

Where did I say that?

But to answer to your question, not targeting Windows ABI, but compiling ELF shared object and converting to PE as last step. I guess you have never ever used GNU-EFI in your entire life, otherwise you'd know. Maybe you should read about the required knowledge?

We're not talking about GNU-EFI and its ugly hacks. We're talking about a cross-compiler that targets the Windows ABI.

Ok, I ask again, this time slowly so that you can understand Where does that spec list the names of functions which are minimally required? On page 8 or on any other page? (It just lists C headers, string.h not among them, yet memset is a builtin and a required minimal function in all compilers for example). Maybe you should read about the required knowledge?

There are none, so you can ignore clause 4 and focus on the rest of that sentence:

Any library facilities available to a freestanding program, other than the minimal set required by clause 4, are implementation-defined.

For implementation-defined behavior, refer to the GCC documentation.

Use the source Luke! Clang has builtin_strlen for example, any many other string functions, see tests here, neither accepts wchar_t as argument, and there's no builtin for wclen or mbstowcs for example. Maybe you should read about the required knowledge?

I still don't understand. Is the problem that you're not able to redefine the built-in functions? Or is the problem that the built-in functions you want don't exist?

It is perfectly normal if the compiler complains about "strcmp(wchar_t *s1, wchar_t *s1);", and it's not a bug.

If the compiler is complaining when you do that, it means either you're not passing "-ffreestanding" to the compiler, or you've found a compiler bug.

[Schol-R-LEA]

I would think that, if it were specifically for any one particular compiler, it would be the Intel Optimizing C++ Compiler. Especially since UEFI was originally called "Intel Boot Initiative", and was aimed at supporting the Itanium platform, not x86. I am not aware of whether MSVC ever supported Itanium (MS do not, to the best of my knowledge, use MSVC as their in-house C compiler, IIUC they have a separate and purely trade-secret toolchain for building Windows), but both IOCC and GCC certainly did.

This is just speculation, though, but quite honestly, that's all any of you seem to have, too. I can safely say that Microsoft wasn't involved in the design until after the original EFI ABI and API were developed, though, since prior to 2005 there was no UEFI Consortium - AFAICT, Intel didn't share the design until well into the development lifecycle. All the functions Bzt seems convinced are from MSVC seem to predate any involvement by Microsoft, and while that doesn't mean it wasn't influenced by MSVC, it does seem to indicate against it being something Microsoft demanded or dictated.

As for the naming, well, Intel has their own history of names of this sort, mostly dating to the period when the expected Ada to be the dominant HLL, and developed independent of Microsoft.

[alexfru]

You need to understand that making an OS requires a number of different things:
- understanding the basics of programming
- understanding the basics of CPU/computer architecture/operation
- assembly skills
- knowledge of some directly applicable hardware details (how your computer would boot your OS, how your OS would work with various computer devices such as keyboard, display, disks, etc)
- OS concepts

So, you should probably roll up your sleeves and work on those smaller things before you can put everything together knowing what you're doing and why.

i know the basics of programming basics of computer architecture/operation so what is the best source to study assembly in which it's from details and scratch

and from your own experiment how you exactly learned all of that

I learned the fundamentals of assembly programming early on when I had performance and size restrictions that I couldn't do much about in BASIC, Pascal or C. I began with Z80 (BASIC + asm), then learned 8051 (asm only, no memory for e.g. Pascal), then 80x86 (Pascal + asm and later C), then others...

Before I got into OS dev, I'd been studying misc programming topics, anything interesting I could learn more about (including algorithms and file formats) and playing with PC devices, learning how various DOS utilities and games did this or that cool thing. I think it took some eight years to arrive to C and OS dev from knowing nearly nothing about programming. Then I read Tanenbaum's MINIX book, wrote some protected mode examples/tutorials, etc.

IOW, there was no particular plan or anticipation, I just learned lots of things out of curiosity and they happened to have become the perfect foundation for OS dev. Assembly programming was covered well before OS dev.

You can improve your asm skills independently of OS dev. Or rather, you may be doing some asm coding and reading a book on OS design in parallel without combining the two things initially.

[bzt]

Especially since UEFI was originally called "Intel Boot Initiative", and was aimed at supporting the Itanium platform

Exactly, just like the first 64 bit Windows: https://news.microsoft.com/2000/07/12/m ... processor/ (release date mid-2000, before EFI)

I can safely say that Microsoft wasn't involved in the design until after the original EFI ABI and API were developed

I don't know what makes you think that's "safe to say", when the Intel's EFI specification (release date 2002, 3 years before UEFI) mentions Microsoft's involvement literally, on Page ii, section "Acknowledgements":

Code: Select all

this specification were developed in close consultation with Microsoft

and

Code: Select all

Microsoft has made significant contributions to the interface definitions presented here

In fact, it was more than a close consultation, because key components like the EFI executable format and the EFI ESP spec (release date Dec 2000, 5 years before UEFI) were published directly by Microsoft., not by Intel at all.

Cheers,
bzt

[nexos]

There isn't anything wrong with Microsoft contributing to the spec. After all, they are the software giant. Why do you think that bad? Who else is there, the FSF? I wouldn't consult the FSF if they were the only software company in the whole world....

[bzt]

@nexos: for your information, I've reported you for trolling.

Have a nice day,
bzt

[iansjack]

And you wonder why you keep getting banned.

Accusing someone of trolling when they are merely stating an opinion different to yours is worse than trolling.

You deserve another ban for that post - possibly a permanent one as you demonstrate that you are just not able to relate to other users in a civilized manner.

[Rukog]

Ok so I can give you my 2 cents since I am doing that rn.

Learning asm without knowledge of other languages is a pure nightmare, you would need to do the compiler job in addition of the software programming aspect (manage registers (not) used, stack, code/data alignment, label management ect)

Ive made the mistake a decade ago of writing in assembly with only assembly knowledge.

And the language I am talking about isn't C, because C will not help you making a better asm code, or just the basic but not enough for complex software as an OS.

The language I am referring is OOP language, C# was my first experience and I was surprised how improvement Ive done in my asm coding ability.

The basic example of how OOP knowledge is important, is the label management aka name mangling for compiler.

It's super important if you want to structure your code, because no compiler will help you in that, you have to do this job from scratch.

NASM do have a nice local label management, it's basic but it does a good job.

Also yes, never fall in the trap of writing macro that try to mimic HAL features, it will just disgust you of assembly.

[nexos]

And you wonder why you keep getting banned.

Accusing someone of trolling when they are merely stating an opinion different to yours is worse than trolling.

You deserve another ban for that post - possibly a permanent one as you demonstrate that you are just not able to relate to other users in a civilized manner.

Thanks for responding in a way that is much more civilized then how I wanted to respond to bzt and his, well, political comment.
@Rukog - writing an OS in assembly gives me shivers! I have to say, I admire people with the ability to write pure ASM OSes.

[Rukog]

@Rukog - writing an OS in assembly gives me shivers! I have to say, I admire people with the ability to write pure ASM OSes.

Yep tough task to do, else Ive changed my mind about that recently and I will use C# for the dev of drivers, GUI and some complex stuff but will try to keep asm for some OS part for the nostalgia purpose

[bzt]

Accusing someone of trolling when they are merely stating an opinion different to yours is worse than trolling.

Look who is talking. I've reported you too.

I said EFI was influenced by Microsoft. Someone questioned that, so I provided evidence with links to the spec. Nexos' and your response too was about nothing else than trying to provoke fight, so yes, you're trolls, without a doubt. Period.

Have a nice day!
bzt