Grub Error 13 with pe format kernel

[gedd]

Hi osdev world !

I try to use grub to load my own kernel wich is in pe format.
I have read the few tutorials on subject, mainly this one http://www.srenevasan.org/~kaushik/articles/pe.html
Grub load my kernel and Invariably give an error 13

Here is my code

Code: Select all

// init.cpp : définit le point d'entrée pour l'application console.
//

#include "init.h"

__declspec(naked) void __multiboot_entry__(void)
{
	__asm{
        multiboot_header:
                dd(0x1BADB002)                ; magic
                dd(1 << 16)|(1<<0)|(1<<1)     ; flags
                dd(-(0x1BADB002 + ((1 << 16)|(1<<0)|(1<<1)))) ; checksum
                dd(0x00101000)                ; header_addr
                dd(0x00101000)                ; load_addr
                dd(0x00102000)                ; load_end_addr
                dd(0x00102000)                ; bss_end_addr
                dd(0x00101030)                ; entry_addr
                dd(0x00000000)                ; mode_type
                dd(0x00000000)                ; width
                dd(0x00000000)                ; height
                dd(0x00000000)                ; depth
				

        kernel_entry:
                mov     esp,     KERNEL_STACK

                xor     ecx,     ecx
                push    ecx
                popf

                push    ebx
                push    eax
                call    main

                jmp     $
        }
}

void main(unsigned long magic, unsigned long addr)
{
        char *string = "Hello World!", *ch;
        unsigned short *vidmem = (unsigned short *) 0xB8000;
        int i;
        
        for(ch = string, i = 0; *ch; ch++, i++)
                vidmem[i] = (unsigned char) *ch | 0x0700;
}

And here is my kernel (init) map file

Code: Select all

 init

 Timestamp is 4b041946 (Wed Nov 18 16:56:54 2009)

 Preferred load address is 00100000

 Start         Length     Name                   Class
 0001:00000000 000000acH .text                   CODE
 0002:00000000 0000000dH .rdata                  DATA

  Address         Publics by Value              Rva+Base       Lib:Object

 0001:00000000       ?__multiboot_entry__@@YGXXZ 00101000 f   init.obj
 0001:00000050       _main                      00101050 f   init.obj
 0002:00000000       ??_C@_0N@GCDOMLDM@Hello?5World?$CB?$AA@ 00102000     init.obj

 entry point at        0000:00000000

 Static symbols

I have checked that multiboot header is at the begining of the kernel, it's ok

My opinion is that the header has bad values but i can be wrong.

Does anyone has an idea ?

[Combuster]

it could be the alignment, the wrong values for the a.out kludge fields.

And even if you got GRUB to accept it, there are tons of other things that might go wrong if you do not know exactly what you are doing. ELF is so much easier on beginners.

[gedd]

OK, but i'm not really a beginner in fact, so i know what i'm doing and what i have already done.
Elf on windows platform is not really much easier since you must use cygwin, cross compiler and command prompt (or eventually Eclipse).
I just want make my PE kernel to be multiboot compliant and eventually avoid bootsector and loader asm 16 bits code.
LD script has no equivalent on Visual Studio and it is much complicated

[Creature]

Elf on windows platform is not really much easier since you must use cygwin, cross compiler and command prompt (or eventually Eclipse).

Off-Topic:
Yes, it requires some time to build, yes it is a bit slower (unless using MinGW), but the positive points outweight most of the cons on Windows, IMO; ELF is very well documented (unlike PE), you have access to linker scripts and a new toolchain can easily be integrated in almost any IDE (Visual Studio, Eclipse, Code::Blocks, ...). In short, it's much easier to develop an ELF kernel for a lot of people.

On-topic:
Are you sure the offsets of the different sections are correct and that this object file is linked first (in case there is more than one object file)?

Finally, I assume all your VC++ compilation and linkage settings are perfectly fine, since the article seems to be missing some extra options. BrokenThorn also has some useful tutorials on a VC++ PE kernel if you're interested.

[gedd]

Off topic :

ELF is very well documented (unlike PE)

Sorry you loosed !
try http://www.microsoft.com/whdc/system/pl ... ECOFF.mspx
and http://en.wikipedia.org/wiki/Portable_Executable especialy external links
Argument over !
Pe on Visual studio (just install) is easier than elf on cygwin (install + compile cross compiler + integrate on your IDE)
Like elf is easier on linux with Kdevelop for instance

On-topic:

I have read and used Brokenthorn tutorials more than a year ago to develop my OS.
It seems to have been updated recently. No Grub sample but a little option decribed that can be very usefull : /STUB
So thanks you Creature !

[Creature]

Sorry you loosed !
try http://www.microsoft.com/whdc/system/pl ... ECOFF.mspx
and http://en.wikipedia.org/wiki/Portable_Executable especialy external links
Argument over !
Pe on Visual studio (just install) is easier than elf on cygwin (install + compile cross compiler + integrate on your IDE)
Like elf is easier on linux with Kdevelop for instance

Still, PE is less documented than ELF is and you'll still have an advantage when using the latter one because almost everyone on these forums uses that format (thus they know the problems they experienced with it and will be of better help to you).

Also remember that the VC++ compiler is not natively available (not referring to WINE, which apparently supports only the command line version) on Linux/Unix/... systems (VC++ compiler), so if you were to ever switch, or there were to be more project members (which coincidentally happen to be on a Linux system), they can't (or would need a workaround) to participate in development.

Besides, I'm not sure (I'm no native English speaker), but doesn't this:

Microsoft will grant a royalty-free license, under reasonable and non-discriminatory terms and conditions, to any Microsoft patent claims (if any exist) that Microsoft deems necessary for the limited purpose of implementing and complying with the required portions of this specification only in the software development tools known as compilers, linkers, and assemblers targeting Microsoft Windows.

mean that you can only use the specification to create executables targeting Windows, or am I wrong?

[gravaera]

I read the specification a while ago, and I do remember it also providing for the creation of PE parsers/loaders on non Windows environments for the purpose of supporting windows drivers within the foreign environment. Apart from that, there is a long, tedious legal prologue which pretty much tries to use scare tactics to tell you not to use the PE format outside of Windows.

Pretty stupid, seeing as PE is nothing that innovative, and I wouldn't much call it intellectual property, seeing as it's not that deeply intellectual. Also, I don't get why they'd go to so much trouble to protect essentially a wrapper around binary code. Honestly...

Of course, everyone has the right to protect his competitive advantage, but I think the restrictions on PE, for example, or MASM (as I've found out based on a recent thread where neon and several other members discussed it), are really unnecessary, and extend into the domain of pure pettiness. It is their right, of course, but you don't have to exercise every single right bestowed upon you.

[Creature]

I read the specification a while ago, and I do remember it also providing for the creation of PE parsers/loaders on non Windows environments for the purpose of supporting windows drivers within the foreign environment. Apart from that, there is a long, tedious legal prologue which pretty much tries to use scare tactics to tell you not to use the PE format outside of Windows.

Pretty stupid, seeing as PE is nothing that innovative, and I wouldn't much call it intellectual property, seeing as it's not that deeply intellectual. Also, I don't get why they'd go to so much trouble to protect essentially a wrapper around binary code. Honestly...

Of course, everyone has the right to protect his competitive advantage, but I think the restrictions on PE, for example, or MASM (as I've found out based on a recent thread where neon and several other members discussed it), are really unnecessary, and extend into the domain of pure pettiness. It is their right, of course, but you don't have to exercise every single right bestowed upon you.

You are right. Still, suppose that you've worked on a PE kernel for 5 years, you've released it and it's pretty mature (and the use of PE outside Windows is indeed illegal). There is a chance that Microsoft will force you to take your project down. Thus, all your hard work is pretty much useless. You'll need to rewrite almost everything to support another format.

[neon]

Hello,

(and the use of PE outside Windows is indeed illegal)

If its illegal, what about ReactOS? I havnt seen them running into any legal issues and they have been in development for a very long time.

I do agree that ELF documentation is more available then PE. I personally do not think you should choose a file format or tool chain because everyone else uses it however. Maybe for a small (new OS developer) OS, but not for a real OS.

[Owen]

WINE would probably be a better example

[gedd]

Hello,

Creature wrote:
(and the use of PE outside Windows is indeed illegal)
If its illegal, what about ReactOS? I havnt seen them running into any legal issues and they have been in development for a very long time.

And what about Mono, i remember you that all .net assemblies are in PE format

[quok]

Hello,

Creature wrote:
(and the use of PE outside Windows is indeed illegal)
If its illegal, what about ReactOS? I havnt seen them running into any legal issues and they have been in development for a very long time.

And what about Mono, i remember you that all .net assemblies are in PE format

And EFI binaries are all PE format as well. Too tired to look and see if the format is covered in the EFI specs, but I'm reasonably sure that it's not just mentioned as an aside.

[Kevin]

LD script has no equivalent on Visual Studio and it is much complicated

Not having an equivalent for linker scripts cleary is a disadvantage (I haven't checked if it's true for VS). For example, how are you going to ensure that the multiboot header will always be in the first 8k as your kernel grows?

[gedd]

And EFI binaries are all PE format as well. Too tired to look and see if the format is covered in the EFI specs, but I'm reasonably sure that it's not just mentioned as an aside.

yes it's a way i'm exploring and if you are interesting on it, VirtualBox 3.1.0 Beta can create EFI compatible virtual machine

[Creature]

Hello,

(and the use of PE outside Windows is indeed illegal)

If its illegal, what about ReactOS? I havnt seen them running into any legal issues and they have been in development for a very long time.

I do agree that ELF documentation is more available then PE. I personally do not think you should choose a file format or tool chain because everyone else uses it however. Maybe for a small (new OS developer) OS, but not for a real OS.

True. But not being sued anymore doesn't mean that it's not illegal. Still, my intention was to say "if it's illegal". Microsoft has been on ReactOS' tail for quite some time and would probably grasp any opportunity at suing them, so that would lead to conclude that it's not illegal. Though, the license seems to say different (which was my original question).