From: nowhere@never.at   
      
   On 17/11/2023 17:04, Scott Lurndal wrote:   
   > wolfgang kern  writes:   
   >> On 16/11/2023 17:18, James Harris wrote:   
   >>> On 16/11/2023 06:53, wolfgang kern wrote:   
   >>>> On 15/11/2023 15:43, James Harris wrote:   
   >>>>> On Wednesday, 11 February 2015 at 11:23:53 UTC, James Harris wrote:   
   >>>>>> "wolfgang kern"  wrote in message   
   >>>>>> news:mba6dr$29p$2...@speranza.aioe.org...   
   >>>>   
   >>>>> Hello, again, Wolfgang et al.   
   >>>>   
   >>>> Hi James,   
   >>>>    time passed by but we are still alive, me at least particular.   
   >>>> interesting that old posts are archived for that long.   
   >>>   
   >>> Google bought Deja and has lengthy archives of a.o.d with, fortunately,   
   >>> the ability still to respond to old threads.   
   >>>   
   >>> I hope Google will keep them indefinitely; there has been some great   
   >>> content on this newsgroup over the years and I still refer back to it   
   >>> from time to time.   
   >>>   
   >>>> but this whole story became obsolete now because of UEFI.   
   >>>   
   >>> UEFI is needed for some machines but there are lots which still boot via   
   >>> the BIOS.   
   >>>   
   >>> If you want to boot a UEFI-only PC you don't personally have to use   
   >>> UEFI. You could use someone else's bootloader. Grub is perhaps best known.   
   >>>   
   >>> I am no fan of Grub but AISI ideally one's OS could be booted from BIOS,   
   >>> PXE, Grub, UEFI, etc.   
   >>   
   >> I don't like LILO nor GRUB, I want to have my own code running :)   
   >>   
   >>   
   >>>> I would restart my OS on UEFI if I find someone who can translate all   
   >>>> the in the UEFI-docs ...   
   >>>   
   >>> Yes, the UEFI docs are massive. And IMO the contents are obscure even   
   >>> for a C programmer!   
   >>   
   >> true.   
   >>   
   >>>> I never will learn C anyway, but perhaps only short key hints are   
   >>>> enough to let me see how structs and parameter size/type look in reality.   
   >>>   
   >>> Is there an existing thread on it? I don't see one.   
   >>   
   >> There were a few lines on it in other threads, but no there isn't a   
   >> UEFI->HEX thread yet.   
   >>   
   >>> A few months ago, as I wanted to support UEFI boot via my own bootloader   
   >>> I looked into it - and found it horrendously complicated. To make   
   >>> matters worse my test environment was hugely uninformative. Most of the   
   >>> time I couldn't even tell whether my code had been booted or not.   
   >>>   
   >>> I did, however, eventually get it working. As a result I have a Hello   
   >>> World UEFI program written in assembly. I can share the details if you   
   >>> like but it needs a thread of its own.   
   >>>   
   >>> I also got working a program which went further along the boot process.   
   >>> It interrogated the file system and successfully found a kernel file to   
   >>> load. That's in C but it's enough to help show how to convert to asm.   
   >>   
   >> I'd appreciate you for any hint on this conversion, but nothing in C.   
   >>   
   >>> At that point I'd done enough to convince me I could get it working so I   
   >>> moved on to other things but if you are interested I could dig it out.   
   >>> Like you, I don't want to have a C version. It was only to help me get   
   >>> started. Longer term I would have the UEFI bootloader in pure asm or in   
   >>> asm and my own language.   
   >>>   
   >>> UEFI can be mastered!   
   >>   
   >> Yes I think that too, even enduring by lots of obstacles.   
   >> I don't want a copy of your code, all I need is info:   
   >>   
   >> how would C-declarations/parameter-structs look on my HEX-dump.   
   >> is there any easy short worded hint available for conversion ?   
   >   
   > 'char' -> 8 bit datum   
   > 'short' -> 16 bit datum   
   > 'int'  -> 32 bit datum   
   > 'long' -> 64-bit datum (x86_64 linux)   
   > 'long' -> 32-bit datum (x86_64 windows)   
   > 'long long' -> 64-bit datum (x86_64 linux and windows)   
   >   
   > Types are generally aligned on natural boundaries.   
   >   
   > ' variable:1'  1-bit datum.   Packed in the same word as   
   > prior and subsequent bit-width declarations, overflowing into next word.   
   >   
   > 'struct' is a "record" of data, with the members aligned   
   > on natural boundaries (unless the compiler is instructed to   
   > pack the data).   
   >   
   > In 64-bit modes, parameters are passed in registers   
   > (rdi, rsi, rdx, rcx, r8, r9 in that order) and spill   
   > to the stack for more than 6 parameters.   
   >   
   > In 32-bit modes see the Intel x86/x86_64 ABI document   
   > for how parameters are passed to functions, although   
   > windows and unix have somewhat different conventions   
   > here.   
      
   THANKS, I copy this right now into my UEFI questionary.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)