From: james.harris.1@gmail.com   
      
   On 06/01/2022 17:54, muta...@gmail.com wrote:   
   > On Thursday, January 6, 2022 at 2:40:30 AM UTC+11, James Harris wrote:   
   >   
   >> After a long absence from OS development I recently returned to it - and   
   >> it feels great to be doing this stuff again!!! The reason for the   
   >> absence (other than life!) was that I was developing a language to write   
   >> the OS in.   
   >   
   > What's wrong with C?   
      
   That's a good question to ask in comp.lang.misc. There's a guy there who   
   has compiled a very good list. I agree with the points he had on his   
   list when I last looked at it though that was some time ago.   
      
   That said, for writing an operating system the flaws in C are nothing   
   major. I decided to produce my own language to make OS writing easier   
   but found out that I could do a lot of what I wanted the OS for by using   
   my own language.   
      
   That said, I would definitely not recommend anyone go down the course   
   that I did unless he is a genius! Producing a 'good' language has been   
   far more difficult than I expected.   
      
   ...   
      
   > In either case, I always load to a fixed address, so I   
   > may as well produce a flat binary, so that is what I   
   > am likely to do.   
      
   That makes sense. I chose to allow the code to run from different   
   locations so that option is not open to me.   
      
   >   
   >> Elf and PE have the opposite problem. Either of them should be easy to   
   >> create but how would one invoke the image? Options:   
   >>   
   >> 2a. Extract the executable part (how?) for inclusion in the loadable image.   
   >   
   > You will need the same logic as a loader. Public domain   
   > code is available here for both:   
   >   
   > https://sourceforge.net/p/pdos/gitcode/ci/master/tree/bios/exeload.c   
      
   Thanks for the link. I see in its exeloadLoadPE function the following.   
      
        if ((coff_hdr.Characteristics & IMAGE_FILE_RELOCS_STRIPPED) != 0)   
        {   
            printf("only relocatable executables supported\n");   
            return (2);   
        }   
      
   and I think that's what's happening here. The linker or something else   
   is stripping out the relocs. ATM I cannot imagine why it would do such a   
   thing.   
      
   Assuming I can fix the link process I can also see some useful   
   calculations in the page you mention such as   
      
      rel_block = exeStart + data_dir->VirtualAddress   
      
   such calcs may be simple but they confirm what needs to be done and are   
   easier to read than the specs!   
      
   >   
   >> 2b. Include the whole executable file, including the headers, and write   
   >> some asm code to parse the headers and jump to the executable part of it.   
   >   
   > Why can't you write 16-bit C code to do that instead   
   > of assembler? That's what I do. If I had my time again   
   > I would write it using the huge memory model of   
   > Watcom C instead.   
      
   If you mean you'd become dependent on a particular compiler then I'd   
   suggest that that's a trap. I thought you wrote in C89. Your same source   
   should be compilable by ANY compatible compiler.   
      
   As for me, by the time I need to relocate the PE or Elf file I will be   
   in 32-bit mode so I can, thankfully, avoid different 16-bit memory models.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)