November 06, 2017
On Sunday, 5 November 2017 at 20:28:38 UTC, Walter Bright wrote:
> Is that an issue with the CPU, or the operating system?
>

Since you *can* install a 32-bit o/s on a 64-bit cpu, logic would suggest that it's a combination of both. Which turns out to be the case.

Nice blog about it here:

https://www.xylos.com/blog/en/2012/04/legacy-16-bit-applications-on-64-bit-operating-systems/

btw. I believe Windows Nano Server drops the wow64 subsystem, and so no longer even supports '32bit' applications. It's 64bit all the way with Nano.

November 05, 2017
On 11/5/2017 6:44 PM, codephantom wrote:
> https://www.xylos.com/blog/en/2012/04/legacy-16-bit-applications-on-64-bit-operating-systems/ 

Thanks for the link. I didn't know that, this clears it up!
November 05, 2017
On 11/5/2017 8:51 PM, Walter Bright wrote:
> On 11/5/2017 6:44 PM, codephantom wrote:
>> https://www.xylos.com/blog/en/2012/04/legacy-16-bit-applications-on-64-bit-operating-systems/ 
> 
> 
> Thanks for the link. I didn't know that, this clears it up!

Interestingly, all I actually need to test the 16 bit code generation is an 8088 emulator with some of the DOS API interrupts supported. The CPU is simple enough that should be easy :-)
November 06, 2017
On Monday, 6 November 2017 at 04:56:53 UTC, Walter Bright wrote:
> Interestingly, all I actually need to test the 16 bit code generation is an 8088 emulator with some of the DOS API interrupts supported. The CPU is simple enough that should be easy :-)

I still have 'actual' pc's here at home, from the 90's, running MS-DOS.

So, don't listen to the naysayers...there is actually a market (small as it is) for 'DMD for MS-DOS'.

Then I can finally retire Borland C++ 3.1 ... may it rest in peace.

November 06, 2017
On 11/5/2017 10:37 PM, codephantom wrote:
> On Monday, 6 November 2017 at 04:56:53 UTC, Walter Bright wrote:
>> Interestingly, all I actually need to test the 16 bit code generation is an 8088 emulator with some of the DOS API interrupts supported. The CPU is simple enough that should be easy :-)
> 
> I still have 'actual' pc's here at home, from the 90's, running MS-DOS.

I have some too, and I tried to fire them up a couple years ago. None of them would. Probably bad capacitors.


> So, don't listen to the naysayers...there is actually a market (small as it is) for 'DMD for MS-DOS'.

I know.
November 06, 2017
On Sunday, 5 November 2017 at 20:28:38 UTC, Walter Bright wrote:
> On 11/5/2017 3:13 AM, Patrick Schluter wrote:
>> On Sunday, 5 November 2017 at 09:17:37 UTC, Walter Bright wrote:
>>> I run dmd regularly on an XP box, but that just means dmd itself runs on XP. (I converted the front end of DMC++ to D, using DMD in -betterC mode, and XP is the last operating system that supports DOS programs. XP has the DOS DMC++ test suite on it.)
>>>
>> I don't think that's true. It's a 32bit/64bit division, not a Windows version thing. A 32 bits installation can run 16 bits and 32 bits programs, a 64 bits version can run natively 32 bits and 64 bits programs. None can run all 3 modes natively.
>
> Is that an issue with the CPU, or the operating system?

CPU officially V86 is not supported in 64 bit mode. But I read a long time ago in c't that it was technically possible to invoke V86 mode when running 32 bit code in loing mode, but that it was quite tricky and required quite some planning to do in all cases (page table tricks [1]). Microsoft decided to not do these kind of tricks and allows only V86 mode in 32 bits installations.
Furthermore, neither AMD not Intel really document that it is possible and it could be that future version of the CPU will not allow for it (the issue with VME mode in Ryzen seem to show that the manufacturers test these exotic legacy modes less and less [2][3]).

>
>> I know with certainty that Windows 8.1 32 bits installation could still run DOS and Windows 16 bits apps. I haven't seen evidence to the contrary for Windows 10.
>> Windows XP was the last version that was installed massively in 32 bits mode.
>>  From Vista on, the proportion of 32 bits installations (and thus losing 16 bits support) dwindeled.
>
> Windows 7  64 bit will not run 16 bit programs. Try it and you get a dialog box "Unsupported 16-Bit Application". I haven't tried Win 7 32, but some googling around shows you are correct.

The 64 bit versions (not the Home editions) do support 16 bit but only by using full fledged virtual machine "Virtual PC", but it's like running on a separate machine.

[1]: https://groups.google.com/forum/#!msg/comp.lang.asm.x86/wfK2LjhCqjw/XoeBgYWyv5EJ
[2]: http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/
[3]: http://www.os2museum.com/wp/vme-fixed-on-amd-ryzen/
November 06, 2017
On 11/2/17 12:25 AM, Andrei Alexandrescu wrote:
>  From the recent PR-related discussion I gather that FreeBSD 12 has made some breaking changes to file primitives such as stat.
> 
> Do binaries built for pre-v12 crash on v12? If that's the case we should have two distinct build platforms, FreeBSD "legacy" and FreeBSD 12. They would be selected statically.
> 
> IF older binaries don't crash, what mechanism is FreeBSD 12 using to identify old API calls?

Thanks to all who answered. From what I gathered from the two on-topic responses, it seems binary compatibility is not provided across major versions. Like Walter, I'd be in favor of supporting the latest only.

Going slightly off-topic (ironically as will become obvious in a second), a sign of maturity in our community would be to use forum discussions as a catalyst and driver for work on new and existing projects. This thread seems to suggest we could improve on that, seeing that the majority of answers are off-topic and there is very little factual information or work items once this thread lives its course.

I've been asked why I have reduced my presence in this forum - and politely told it's being missed :o) - and the simple answer is I've noticed the forum discussions produce few results outside the forum. I'm still looking for the perfect formula that combines good forum engagement with palpable work.


Thanks,

Andrei
November 06, 2017
On 11/6/2017 7:44 AM, Patrick Schluter wrote:
> The 64 bit versions (not the Home editions) do support 16 bit but only by using full fledged virtual machine "Virtual PC", but it's like running on a separate machine.

When my XP machine finally dies I'm tempted to write that emulator :-) It would be very simple.
November 07, 2017
On Monday, 6 November 2017 at 22:25:48 UTC, Andrei Alexandrescu wrote:
> I've been asked why I have reduced my presence in this forum - and politely told it's being missed :o) - and the simple answer is I've noticed the forum discussions produce few results outside the forum. I'm still looking for the perfect formula that combines good forum engagement with palpable work.
>
>
> Thanks,
>
> Andrei

Well.. all I can say..is be careful.

If you make this forum like the FreeBSD forums, then people will stop engaging, and there goes your community....(i.e go off topic in those forums and see what happens to you).

Disussions lead to discusions..lead to discussions...that's normal human behaviour.

Unexpected (OT) results can be useful for the D community too...

Perhaps some way to mark our thread as OT would be good. Then one could filter out OT discussion. But any attempt to stop OT discussion will come back and bite the community I believe. Humans' like discussing things too.

This thread did lead to some unintended outcomes, like me finding that gdc will compile code that dmd and ldc will not - apparentaly a bug in gdc, but a bug that I actually like. It lead (I hope) to a greater understanding of the importance of FreeBSD and the need for D to pro-actively support it (remember FreeBSD really is the only mature open source alternative to gpl Linux - but it gets treated as a second class citizen by far too many (e.g. the latested LDC release anouncement provides binaries for all platforms except FreeBSD??).

And most importantly, OT discussion in this thread may lead to a DMD for DOS! Now tell me that wasn't worth some OT discussion ;-)


November 06, 2017
On 11/6/2017 4:30 PM, codephantom wrote:
> It lead (I hope) to a greater understanding of the importance of FreeBSD and the need for D to pro-actively support it (remember FreeBSD really is the only mature open source alternative to gpl Linux - but it gets treated as a second class citizen by far too many

The FreeBSD port came from me having a soft spot for it :-) and also because Jan Knepper, our server provider, runs our web sites on a FreeBSD server.