X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Received: by 10.224.205.138 with SMTP id fq10mr5073155qab.1.1369503470660; Sat, 25 May 2013 10:37:50 -0700 (PDT) X-Received: by 10.49.87.70 with SMTP id v6mr1516203qez.25.1369503470646; Sat, 25 May 2013 10:37:50 -0700 (PDT) Newsgroups: comp.os.msdos.djgpp Date: Sat, 25 May 2013 10:37:50 -0700 (PDT) In-Reply-To: <90dceebd-8d81-4433-8932-9bce42bddb97@googlegroups.com> Complaints-To: groups-abuse AT google DOT com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO NNTP-Posting-Host: 65.13.115.246 References: <1137560452 DOT 398133 DOT 301490 AT g14g2000cwa DOT googlegroups DOT com> <0ed77a97-aec8-4fde-8124-707ca9cffad1 AT googlegroups DOT com> <28c2ff16-6cef-46c3-8f52-f67b320b5c04 AT googlegroups DOT com> <68c3dec5-8fd4-4eb0-888d-3949d879a33c AT googlegroups DOT com> <90dceebd-8d81-4433-8932-9bce42bddb97 AT googlegroups DOT com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8c20b7ec-d307-4f25-9e63-15d700b0265b@googlegroups.com> Subject: Re: Adding 64-bit file support to DJGPP From: rugxulo AT gmail DOT com Injection-Date: Sat, 25 May 2013 17:37:50 +0000 Content-Type: text/plain; charset=ISO-8859-1 Bytes: 4290 Lines: 63 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hi, On Saturday, May 25, 2013 10:56:19 AM UTC-5, Georg Potthast wrote: > > The 64bit hardware does no longer support V86 mode. This mode was > intended to allow 32 bit operating systems to run 16 bit > applications, i.e. DOS applications. It officially and natively supports V86 only in legacy mode. You can't really use 64-bit long mode and 16-bit real mode at the same time (without later VT-X). > Now the hardware has to be able to support 32 bit operating systems > in 64 bit mode, like Windows XP. For this VT-X has been implemented > which allows to emmulate a 32 bit PC in 64 bit mode. This is used by > VirtualPC and friends. Last I heard, WinXP Mode didn't need VT-X anymore (unlike Hyper-V). But doesn't VPC only emulate a Pentium 2? And it's not great on graphical support, hence why MS doesn't recommend it for home users (games?). > Writing a Hypervisor that uses VT-X is really a lot of development > since you have to virtualise just about anything. I evaluated an > alternative Hypervisor just to see how much is left to implement to > make it usable. Well, we're stuck between a rock and a hard place. Best to just use an existing emulator or hypervisor than roll our own, probably. FreeBSD is (also) working on their own, bhyve, but for now it only is targeted at FreeBSD itself. > DJ Delorie is right to suggest MinGW as an alternative. As long as > you do not access the hardware directly it is really easy to port a > DJGPP program to MinGW. MinGW isn't too bad, but I'd really suggest OpenWatcom instead. > Otherwise I think that a robust alternative is to put your DJGPP > application together with FreeDOS on a disk image and package that > together with a command line version of Qemu for Windows which is > about 13 MB compressed. When the user starts your package he/she > will start Qemu with FreeDOS starting your application. This is what they did back in the day for certain installs of PuppyLinux. IIRC, they stuck to old QEMU 0.8.2 (possibly for Win9x compatibility). > I only need a 2 MB FreeDOS distro to run my DJGPP applications. Many > of the Qemu files in the 13 MB package you do not need. So the > entire package will probably add up to compressed 15 MB which is > less than most Windows applications. QEMU has been changing so much lately, though I'm not sure if Win32 host is a priority for them. IIRC they even want to merge with KVM. Latest release is 1.5.0. > Am Freitag, 24. Mai 2013 16:55:18 UTC+2 schrieb RayeR: > >> Well, I see there's already GCC for UEFI targets. So much more >> interesting would be to write some V86 monitor that switch from >> PM to V86 and allow running existing DOS programs. It would trap >> INT calls and translate it to UEFI calls. But I belive it's hard >> task, maybe complicated like Japhet's Jemmex...