From: mutazilah@gmail.com   
      
   On 20/03/24 01:07, Paul wrote:   
      
   > Is your hardware 64-bit capable ?   
      
   I am running Windows 10 on an x64.   
      
   Then I run Virtualbox.   
      
   I normally do development on Windows 2000, running   
   under Virtualbox. Always running 32-bit tools.   
   But sometimes producing a 64-bit executable, which   
   is then transferred to the Windows 10 host to briefly test.   
      
   Another thing I run under Virtualbox is Kylin OS.   
      
   I went with this because I bought a computer with   
   a Zhaoxin x64 processor and it came with Kylin   
   installed. I did this because I wanted to test   
   PDOS/386.   
      
   I also wanted to test Windows 10 64-bit.   
      
   This was a bit of a struggle, but ended up working   
   sufficiently well.   
      
   > You seem to emit a lot of older breadcrumbs in text, implying   
   > older equipment and environment.   
      
   My software all targets the older equipment,   
   while also running on modern equipment.   
      
   That's what I expect from my software. ie for   
   it to be upwardly compatible.   
      
   > I would have gladly selected a 64-bit OS for you,   
   > if there was a sign you could actually use it. There's   
      
   I already have one - Kylin OS.   
      
   But I wish to replace it (with a massive downgrade -   
   but still x64).   
      
   > You were, after all, screwing with Puppy, and that's a sign   
   > a person has older equipment. Nobody selects Puppy for   
   > its smooth mainstream operation. (You would use FatDog64   
   > if sampling the Puppy ecosystem, with a capable 64-bit computer.)   
      
   I was selecting Puppy (before) because I was after a   
   minimal Linux.   
      
   I can't remember if I was looking for 386-only, as my   
   software to test is mostly 386.   
      
   But I do actually have the capability to produce 64-bit   
   Linux executables on my PDOS/386 ecosystem. But they are in   
   COFF format, so require an objcopy step when arriving on   
   the x64 Linux.   
      
   I am expecting to be able to generate 64-bit ELF directly   
   in due course, and the person (author of pdld) who does   
   that work will need to be able to test it. He asked me   
   how to test his ELF executables, and I wanted to give him   
   the simplest possible answer. ie a very simple system   
   designed for developers to test. Not end users to use.   
      
   (Although at the same time I like the thought of - "hey,   
   what can we do with this C90 compiler?")   
      
   I'm not expecting an existing distribution to do what   
   I want, as I have a narrow target audience.   
      
   Anyway, I have made some progress. I am selecting Linux 6.6   
   since it is advertised as having long-term support.   
      
   On my Kylin system I have produced a bzImage with this config:   
      
      CC      arch/x86/boot/video-bios.o   
      LD      arch/x86/boot/setup.elf   
      OBJCOPY arch/x86/boot/setup.bin   
      OBJCOPY arch/x86/boot/vmlinux.bin   
      HOSTCC  arch/x86/boot/tools/build   
      BUILD   arch/x86/boot/bzImage   
   Kernel: arch/x86/boot/bzImage is ready  (#1)   
   kerravon@kerravon2-pc:~/scratch/linux-6.6.22$ make allnoconfig   
      
      
   -rwxrwxr-x   1 kerravon kerravon 3837012 Mar 20 14:23 vmlinux   
      
   kerravon@kerravon2-pc:~/scratch/linux-6.6.22$ ls -l arch/x86/boot/bzImage   
   -rw-rw-r-- 1 kerravon kerravon 1503744 Mar 20 14:24 arch/x86/boot/bzImage   
      
      
      
   But I'm not sure what this (bzImage) is.   
      
   I can tell from looking at it that it has a 55AA disk   
   signature, but as far as I can tell this is not a FAT32   
   image with a bootx64.efi, nor is it an MBR with 8086   
   code, and nor is it an ISO CD.   
      
   It could be GPT (which I'm not familiar with), but I   
   don't think so.   
      
   Regardless, I don't want to use Grub, so I am expecting   
   a bootx64.efi (PE format executable) to load this bzImage   
   into memory.   
      
   I am hoping to only have FAT32 physical disks. If an   
   ext4 or whatever is required it can be done as a ramdisk.   
   If Linux needs a plethora of files to operate it can   
   create them in its own ramdisk (which this bzImage may be   
   designed to do already).   
      
   But the Linux build process hasn't produced a bootx64.efi.   
      
   So what's the official source of one of those?   
      
   I can potentially provide my own - I do that in my UCX64   
   distribution. So the infrastructure exists. I could read   
   this bzImage file into memory, and then ... what?   
      
   Thanks. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)