www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What is the FreeBSD situation?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
 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,

Andrei
Nov 01
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, November 02, 2017 00:25:26 Andrei Alexandrescu via Digitalmars-
d 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?
Technically speaking, with how FreeBSD deals with its API/ABI, it promises compatibility across major releases but not minor ones, so _any_ time you go up a major version, there's a risk of breakage (though I don't know how often APIs get changed in practice). In that respect, the fact that we've been doing FreeBSD releases that don't target a particular version of FreeBSD is kind of crazy, though for the most part, I think that the API and ABI have not changed sufficiently in the areas that matter to dmd or Phobos for it to be a big issue, though occasionally, fixes have had to be made because something worked on one version of FreeBSD but not another. But we don't currently have a way to version code for a particular version of FreeBSD even if we wanted to. So, while we could do separate builds for different versions of FreeBSD (and thus handle ABI changes), the source code would have to be the same. AFAIK, the closest that we can currently come to versioning the source code based on the version of FreeBSD is to check the uname at runtime and run different code depending on the version, but that obviously doesn't work in all situations. Right now, what we have mostly works on FreeBSD 10.x and 11.x (it looks like 64-bit has a dmd test failure, and 32-bit has a Phobos test failure) as well as older versions of 12-to-be (that's what I run locally, since that's what TrueOS is based on), but several months ago, FreeBSD did make changes to stat and related functions so that inodes are 64-bit, and that obviously changed the API. They did a lot of work to make that compatible so that programs didn't just break, but the compatibility stuff that they did was for C/C++, and we don't use C/C++ headers; we duplicate their declarations in D. So, we have to do work of some kind to be compatible, and I'm not familiar enough with the details to know what needs doing. The related bug report is https://issues.dlang.org/show_bug.cgi?id=17596 and some work has been done to figure out what needs doing including a suggested way to wrap the API changes at least until we're only supporting FreeBSD 12+ (which is quite a ways off, since it hasn't even been released yet). I don't know exactly what the situation with that currently is. I keep hoping that it will be sorted out by December, since that's when the next TrueOS update happens, and then it'll be based on a new enough version of FreeBSD 12 that D will break if I upgrade, but I haven't had time to look into it, and clearly those who looked into it previously haven't finished doing whatever needs doing. - Jonathan M Davis
Nov 01
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/2/17 1:11 AM, Jonathan M Davis wrote:

 
 Right now, what we have mostly works on FreeBSD 10.x and 11.x (it looks like
 64-bit has a dmd test failure, and 32-bit has a Phobos test failure) as well
 as older versions of 12-to-be (that's what I run locally, since that's what
 TrueOS is based on), but several months ago, FreeBSD did make changes to
 stat and related functions so that inodes are 64-bit, and that obviously
 changed the API. They did a lot of work to make that compatible so that
 programs didn't just break, but the compatibility stuff that they did was
 for C/C++, and we don't use C/C++ headers;
Well, that is only header compatibility, not binary compatibility. In other words, that still means if you use C or C++, you need to recompile if you are on FreeBSD 12. You can't have one binary that supports both platforms. If this is the only compatibility they support, then I think we do need to have multiple versions. -Steve
Nov 02
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/02/2017 08:46 AM, Steven Schveighoffer wrote:
 Well, that is only header compatibility, not binary compatibility. In 
 other words, that still means if you use C or C++, you need to recompile 
 if you are on FreeBSD 12. You can't have one binary that supports both 
 platforms.
Thanks, this is the kind of hard data we're looking for. Do you have a link to support this?
 If this is the only compatibility they support, then I think we do need 
 to have multiple versions.
That's exactly right. Thanks! Andrei
Nov 02
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/2/17 10:56 AM, Andrei Alexandrescu wrote:
 On 11/02/2017 08:46 AM, Steven Schveighoffer wrote:
 Well, that is only header compatibility, not binary compatibility. In 
 other words, that still means if you use C or C++, you need to 
 recompile if you are on FreeBSD 12. You can't have one binary that 
 supports both platforms.
Thanks, this is the kind of hard data we're looking for. Do you have a link to support this?
Sorry, I don't have any experience with FreeBSD. I was reacting to Jonathan's claim that "They did a lot of work to make that compatible so that programs didn't just break, but the compatibility stuff that they did was for C/C++, and we don't use C/C++ headers" That lead me to believe that marking the headers differently is all they did. As I said, this is not binary compatibility. Sure, we can do this too, we don't use C/C++ headers, but we can port our headers. The question to answer is, "can we create a binary that runs on both versions of FreeBSD?". The answer to that question, I don't know. Is it possible on FreeBSD to detect this at runtime and call the right binding? Not sure. It might not even be detectable (see codephantom's post on how FreeBSD 12 may be compiled with the older binding anyway!) Another possible option, if it existed, would be to simply call a function that does the right thing. Perhaps a .so that can be swapped out based on which version of the OS you are on? But the only thing I can think of currently, that will definitely "solve" the problem, is to treat each version as a different OS with a new version statement. This doesn't scale well, so I'm not sure if that's the road we want to go down. -Steve
Nov 02
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 2 November 2017 at 15:33:39 UTC, Steven 
Schveighoffer wrote:
 But the only thing I can think of currently, that will 
 definitely "solve" the problem, is to treat each version as a 
 different OS with a new version statement. This doesn't scale 
 well, so I'm not sure if that's the road we want to go down.
That seems to be the road version statements are already going down...There is Playstation and Playstation4. There is SysV3 and SysV4. There are 5 different ARM versions. Posix groups together FreeBSD, OSX, Solaris, etc, which also exist on their own.
Nov 02
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, November 02, 2017 11:33:39 Steven Schveighoffer via 
Digitalmars-d wrote:
 On 11/2/17 10:56 AM, Andrei Alexandrescu wrote:
 On 11/02/2017 08:46 AM, Steven Schveighoffer wrote:
 Well, that is only header compatibility, not binary compatibility. In
 other words, that still means if you use C or C++, you need to
 recompile if you are on FreeBSD 12. You can't have one binary that
 supports both platforms.
Thanks, this is the kind of hard data we're looking for. Do you have a link to support this?
Sorry, I don't have any experience with FreeBSD. I was reacting to Jonathan's claim that "They did a lot of work to make that compatible so that programs didn't just break, but the compatibility stuff that they did was for C/C++, and we don't use C/C++ headers" That lead me to believe that marking the headers differently is all they did. As I said, this is not binary compatibility. Sure, we can do this too, we don't use C/C++ headers, but we can port our headers. The question to answer is, "can we create a binary that runs on both versions of FreeBSD?". The answer to that question, I don't know. Is it possible on FreeBSD to detect this at runtime and call the right binding? Not sure. It might not even be detectable (see codephantom's post on how FreeBSD 12 may be compiled with the older binding anyway!)
The bug report I linked to has an example of how it might be fixed with a wrapper function that calls a different version of stat depending on what version of FreeBSD it looks like is running at runtime. But I have no idea how complete that is. I keep meaning to find the time to look into this in detail but haven't gotten around to it yet. I believe that what codephantom's post means is that with that build option, the compatibility stuff is in place which allows the 32-bit inode stuff to be used but in spite of the fact that they've now switched to 64-bit inodes (certainly, that's my understanding of what the compatibility stuff does), but I haven't dug deep enough to figure out the details. Given that this issue hasn't been sorted out yet and that if it's not sorted out by next month, I'm going to be stuck between not upgrading my desktop and not having a working D setup (due to the TrueOS-stable update to a newer version of FreeBSD 12), it's looking like I'm going to have to find the time to dig deeper.
 Another possible option, if it existed, would be to simply call a
 function that does the right thing. Perhaps a .so that can be swapped
 out based on which version of the OS you are on?

 But the only thing I can think of currently, that will definitely
 "solve" the problem, is to treat each version as a different OS with a
 new version statement. This doesn't scale well, so I'm not sure if
 that's the road we want to go down.
Well, in the case of FreeBSD, it's not terrible, especially since it doesn't make much sense to support versions of FreeBSD that the FreeBSD guys don't support. And in that case, the most you'd get is probably 3 versions (currently FreeBSD10, FreeBSD11, and FreeBSD12), and they would shift over time, so while there would be more in the compiler if they weren't removed, druntime or Phobos wouldn't get an ever growing number of them. But from what I can tell, the API changes rarely enough that it usually wouldn't even be needed. I think that it's usually a greater risk that you'd need to build for a newer system because of ABI changes than that the API changed in a way that requires versioning druntime or Phobos. This inode situation is an extreme case, and they've been working for years on getting it done in a way that minimizes the level of disruption and breakage that it causes. The bigger problem with separate versions is that the autotester would then really need to be running at least a FreeBSD 10.x and FreeBSD 11.x box (and later 11.x and 12.x once 12 is released), and we'd need to release different packages for each (though we could arguably just rely on the ports tree for the releases so long as someone is maintaining the FreeBSD port). The fact that we don't test multiple versions of FreeBSD has occasionally been a problem already, but the bigger problem has been that the auto-testers just haven't gotten updated often (IIRC they're on 8.x and not even 9.x, whereas 10.3 is currently the oldest supported release), and now several things have needed to get fixed towards being able to update them, because several things broke. If we _can_ continue to do just do one release of dmd for FreeBSD that works across several versions, then that's ideal, but the way that FreeBSD is released, I think that it's normally expected that you're going to have to rebuild stuff for each major release even if APIs don't change, and if we're not testing multiple versions, then we're going to miss it when we manage to break something. In any case, we need a clear picture of exactly what needs to be done for the inode64 breakage to know whether we absolutely need to have separate builds or whether we can get away with playing tricks at runtime to work around it. The bug report makes it sound like we _might_ be able to work around this with runtime tricks. - Jonathan M Davis
Nov 02
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2017 10:11 PM, Jonathan M Davis wrote:
 But we
 don't currently have a way to version code for a particular version of
 FreeBSD even if we wanted to.
The FreeBSD version can be detected at runtime, and different code executed.
Nov 02
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, November 02, 2017 13:46:11 Walter Bright via Digitalmars-d 
wrote:
 On 11/1/2017 10:11 PM, Jonathan M Davis wrote:
 But we
 don't currently have a way to version code for a particular version of
 FreeBSD even if we wanted to.
The FreeBSD version can be detected at runtime, and different code executed.
Sure, but you can't actually compile different code based on the FreeBSD version, and if a type or function API changes, then that doesn't work. Wouldn't you get a linker error for the stuff that isn't actually defined on the C side of things? If so, then you can't really provide both the old and new versions of a function or type and switch between code that uses one or the other based on the version of the OS at runtime. You'd have to be able to have the source code differ depending on the FreeBSD version. Depending on what was done with the compatibility layer for the 64-bit inode stuff, we may be able to do something in this case to choose which to use based on the version of the OS at runtime, because you'd have both the direct API and the compatibility API to use and thus there are different symbols to link against, but in the general case, if an API is simply updated, then you only have one version to link against. So, while we may be able to deal with this particular issue with something that makes the choice at runtime, I don't see how that would work in general any time that there's a breaking API change. Any time that happens, we'd need to be able to statically differentiate which version of FreeBSD we'd be compiling for. And that may not actually ever come up, since it's not like the FreeBSD folks change APIs for the fun of it, but it still looks to me like not being able to version the source code based on the version of FreeBSD your compiling for is potentially a showstopper for having code work with multiple versions of FreeBSD. I think that we're more likely to get away with it with dmd, druntime, and Phobos, because we mostly use POSIX APIs, which they aren't going to be changing much, but if you're dealing with something that isn't POSIX, then the odds are that it would matter more. In such a case, you'd probably be forced to either provide different versions of a module depending on the OS version, and have the build system differentiate for you, or you'd have to provide custom version identifiers as part of the build so that the code could be versioned appropriately. - Jonathan M Davis
Nov 02
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/2/2017 2:25 PM, Jonathan M Davis wrote:
 On Thursday, November 02, 2017 13:46:11 Walter Bright via Digitalmars-d
 wrote:
 On 11/1/2017 10:11 PM, Jonathan M Davis wrote:
 But we
 don't currently have a way to version code for a particular version of
 FreeBSD even if we wanted to.
The FreeBSD version can be detected at runtime, and different code executed.
Sure, but you can't actually compile different code based on the FreeBSD version, and if a type or function API changes, then that doesn't work. Wouldn't you get a linker error for the stuff that isn't actually defined on the C side of things? If so, then you can't really provide both the old and new versions of a function or type and switch between code that uses one or the other based on the version of the OS at runtime. You'd have to be able to have the source code differ depending on the FreeBSD version.
I know in Windows the imports can be dynamically loaded at runtime.
Nov 02
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, November 02, 2017 19:28:50 Walter Bright via Digitalmars-d 
wrote:
 On 11/2/2017 2:25 PM, Jonathan M Davis wrote:
 On Thursday, November 02, 2017 13:46:11 Walter Bright via Digitalmars-d

 wrote:
 On 11/1/2017 10:11 PM, Jonathan M Davis wrote:
 But we
 don't currently have a way to version code for a particular version of
 FreeBSD even if we wanted to.
The FreeBSD version can be detected at runtime, and different code executed.
Sure, but you can't actually compile different code based on the FreeBSD version, and if a type or function API changes, then that doesn't work. Wouldn't you get a linker error for the stuff that isn't actually defined on the C side of things? If so, then you can't really provide both the old and new versions of a function or type and switch between code that uses one or the other based on the version of the OS at runtime. You'd have to be able to have the source code differ depending on the FreeBSD version.
I know in Windows the imports can be dynamically loaded at runtime.
I thought that that was just when explicitly loading a .dll or .so file via something like dlopen or LoadLibrary instead of linking against it, and you normally link against system libraries rather than dlopening them. But Windows is pretty weird about how it dynamically links stuff, so I could be misunderstanding something in Windows' case. Regardless, it wouldn't be the case with static linking, and there are cases where it's definitely preferable to statically link. So, I fully expect that there are times when being able to version the source code based on the OS version (or the libc version if you're talking about Linux) would be needed. However, I don't know if it's needed often enough for the compiler to directly support it rather than using custom version specifiers for those code bases that do. Technically, I think that the versioning that they do in C/C++ for this sort of thing with #includes is more or less equivalent to using custom version specifiers rather than actually doing anything special with the compiler. Regardless, it would be nice if we could avoid the need to statically version any code in dmd, druntime, or Phobos based on OS version. - Jonathan M Davis
Nov 02
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-11-03 03:43, Jonathan M Davis wrote:

 So, I fully expect that there are times when being able to version the
 source code based on the OS version (or the libc version if you're talking
 about Linux) would be needed. However, I don't know if it's needed often
 enough for the compiler to directly support it rather than using custom
 version specifiers for those code bases that do. Technically, I think that
 the versioning that they do in C/C++ for this sort of thing with #includes
 is more or less equivalent to using custom version specifiers rather than
 actually doing anything special with the compiler.
 
 Regardless, it would be nice if we could avoid the need to statically
 version any code in dmd, druntime, or Phobos based on OS version.
I don't know all the details, just throwing some ideas out there: * macOS went through a similar transition, perhaps have a look at how Apple did that. There some information here [1], scroll down to the documentation for the _DARWIN_FEATURE_64_BIT_INODE macro * Fully statically link the binaries, including the C standard library. Might work assuming the kernel did not change * Do something similar to what AppImage [2] is doing on Linux. AppImage works by creating a binary with an executable header and a disk image that holds the payload. In the case of AppImage the payload would be the application including all the files necessary to run it. Perhaps we could instead build something like universal binaries on macOS. Embed two separate executables and run one of the depending on the current system [1] https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/stat.2.html [2] https://appimage.org -- /Jacob Carlborg
Nov 03
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/2/2017 7:43 PM, Jonathan M Davis wrote:
 I thought that that was just when explicitly loading a .dll or .so file via
 something like dlopen or LoadLibrary instead of linking against it,
That's right. But given our resource limitations, I suggest the most pragmatic thing to do is support the latest FreeBSD, and leave older versions enabled in Druntime with `version` statements. That way the user could recompile Phobos for earlier versions if he needed it, but it wouldn't be officially supported. Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(
Nov 03
next sibling parent reply codephantom <me noyb.com> writes:
On Friday, 3 November 2017 at 09:40:01 UTC, Walter Bright wrote:
 Note that dmd still runs on Windows XP, though it is not 
 officially supported. You just need to be careful about using 
 TLS variables on it :-(
Please keep it that way ;-) btw. dmd runs just fine on FreeBSD 12 too, as I just tested it. Mind you, I just compile my own stuff, and that's all. I don't have extensive unit tests, so some things may well not work.
Nov 03
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 03, 2017 09:50:37 codephantom via Digitalmars-d wrote:
 On Friday, 3 November 2017 at 09:40:01 UTC, Walter Bright wrote:
 Note that dmd still runs on Windows XP, though it is not
 officially supported. You just need to be careful about using
 TLS variables on it :-(
Please keep it that way ;-)
I think that there's a decent chance that some of Phobos won't work with XP though. A lot of API calls were added in Vista, some of which were major improvements. Plenty of stuff will probably continue to work on XP, but we don't support it, and as time goes by, the odds of stuff not working on it are going to increase. So, feel free to use XP if you want to, but you're using it at your own risk, and if something doesn't work, then you're just going to be out of luck.
 btw. dmd runs just fine on FreeBSD 12 too, as I just tested it.

 Mind you, I just compile my own stuff, and that's all.

 I don't have extensive unit tests, so some things may well not
 work.
It definitely crashed the last time I tested it, and the aforementioned bug report has someone testing it, and it crashing. So, either they've changed something that somehow magically made our stuff work as-is, or you just got lucky. But regardless of whether it currently crashes, it's clear that we're going to need to make stat and friends work with 64-bit inodes rather than simply using the 32-bit inodes, even if they still happen to work for the moment, since at some point, the 32-bit inodes are going to be going away (though I'm sure not until at least FreeBSD 13). - Jonathan M Davis
Nov 03
next sibling parent codephantom <me noyb.com> writes:
On Friday, 3 November 2017 at 10:26:42 UTC, Jonathan M Davis 
wrote:
 So, feel free to use XP if you want to, but you're using it at 
 your own risk, and if something doesn't work, then you're just 
 going to be out of luck.
that's ok, if it works great, if not, oh well. at least it executes ;-) e.g clang etc won't even execute on xp.
 It definitely crashed the last time I tested it, and the 
 aforementioned bug report has someone testing it, and it 
 crashing. So, either they've changed something that somehow 
 magically made our stuff work as-is, or you just got lucky.
Yes, **do** your own testing, as my concept of testing is at best, dodgy... i.e. I just grabbed all my .d files off FreeBSD 11, put them on FreeBSD 12, and executed this: for f in *.d; do echo $f;dmd $f; done ;-)
Nov 03
prev sibling parent reply codephantom <me noyb.com> writes:
On Friday, 3 November 2017 at 10:26:42 UTC, Jonathan M Davis 
wrote:
 I think that there's a decent chance that some of Phobos won't 
 work with XP though....
Same for FreeBSD ;-) e.g: below compile fine on Windows, but on FreeBSD (11 and 12), I get a compile time error: Error: template instance to!string to is not a template declaration, it is a module. I've come across a few others too.... so Phobos developers need to test on FreeBSD too. ------------------ import std.stdio; import std.conv; void main() { auto i = to!string(55); writeln("i is a ", typeof(i).stringof); } -----------------------
Nov 03
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 03, 2017 11:04:12 codephantom via Digitalmars-d wrote:
 On Friday, 3 November 2017 at 10:26:42 UTC, Jonathan M Davis

 wrote:
 I think that there's a decent chance that some of Phobos won't
 work with XP though....
Same for FreeBSD ;-) e.g: below compile fine on Windows, but on FreeBSD (11 and 12), I get a compile time error: Error: template instance to!string to is not a template declaration, it is a module. I've come across a few others too.... so Phobos developers need to test on FreeBSD too. ------------------ import std.stdio; import std.conv; void main() { auto i = to!string(55); writeln("i is a ", typeof(i).stringof); } -----------------------
Well, I won't deny that most of the core devs don't use FreeBSD, and the auto-tester situation with FreeBSD needs to be improved, but that code compiles just fine on my TrueOS system with dmd master, and that code is not the sort of thing that I would expect to have issues that depended on the OS it was on. What version of dmd are you running? - Jonathan M Davis
Nov 03
next sibling parent codephantom <me noyb.com> writes:
On Friday, 3 November 2017 at 19:36:51 UTC, Jonathan M Davis 
wrote:
 Well, I won't deny that most of the core devs don't use 
 FreeBSD, and the auto-tester situation with FreeBSD needs to be 
 improved, but that code compiles just fine on my TrueOS system 
 with dmd master, and that code is not the sort of thing that I 
 would expect to have issues that depended on the OS it was on. 
 What version of dmd are you running?

 - Jonathan M Davis
That is strange, that it compiles ok on TrueOS. I don't think it's a FreeBSD issue as such, maybe more a posix issue?? I **cannot** compile that code that I mentioned on FreeBSD-11/12, Debian 8.5.0, or Centos 7.3.1611. In all those cases, DMD gives the same strange message. The only way I got it to work (on both Debian and Centos) was to compile with GDC instead. On FreeBSD-11/12, it just won't compile whether I use DMD or LDC (and of course i don't have GDC on FreeBSD so don't know would happen if I did). But: auto i = to!string(55); Gee...that's a pretty simply piece of code, and shouldn't be failing at all, anywhere.
Nov 03
prev sibling parent reply codephantom <me noyb.com> writes:
On Friday, 3 November 2017 at 19:36:51 UTC, Jonathan M Davis 
wrote:
 What version of dmd are you running?

 - Jonathan M Davis
======================================================== DMD (installed on..) ---- FreeBSD: DMD64 D Compiler v2.076.1 Debian: dmd_2.076.1-0_amd64.deb Centos: 2.076.1/dmd-2.076.1-0.fedora.x86_64.rpm Windows: dmd-2.076.1.exe GDC (installed on Debian and Centos) --- ..(gdcproject.org 20161225-v2.068.2_gcc6) 6.3.0 LDC (installed on FreeBSD-11/12) --- ..LDC - the LLVM D compiler (1.3.0): based on DMD v2.073.2 and LLVM 3.9.1 ========================================================
Nov 03
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, November 04, 2017 01:28:24 codephantom via Digitalmars-d wrote:
 On Friday, 3 November 2017 at 19:36:51 UTC, Jonathan M Davis

 wrote:
 What version of dmd are you running?

 - Jonathan M Davis
======================================================== DMD (installed on..) ---- FreeBSD: DMD64 D Compiler v2.076.1 Debian: dmd_2.076.1-0_amd64.deb Centos: 2.076.1/dmd-2.076.1-0.fedora.x86_64.rpm Windows: dmd-2.076.1.exe GDC (installed on Debian and Centos) --- ..(gdcproject.org 20161225-v2.068.2_gcc6) 6.3.0 LDC (installed on FreeBSD-11/12) --- ..LDC - the LLVM D compiler (1.3.0): based on DMD v2.073.2 and LLVM 3.9.1 ========================================================
I don't know what to tell you. I just tested your example with dmd 2.073.2 dmd 2.074.1 dmd 2.075.1 dmd 2.076.1 dmd master on both TrueOS stable and Arch Linux, and it compiled just fine with all of them. And that example is so basic that something is seriously wrong if it doesn't work. So, that implies that you're doing something funny, but if you're installing dmd with an installer or package manager, then I would think that it would at least be set up correctly. You might want to try dmd --version to make sure that you're running the version you think you are and which dmd to make sure you're running the binary that you think you're running - e.g. maybe you did something previously with dmd that resulted in a borked install that has precedence in the path over the properly installed one - though I wouldn't think that you'd manage that on multiple systems like that. So, I don't know, but it's a thought. - Jonathan M Davis
Nov 03
next sibling parent codephantom <me noyb.com> writes:
On Saturday, 4 November 2017 at 03:19:00 UTC, Jonathan M Davis 
wrote:
 maybe you did something previously with dmd that resulted in a 
 borked install that has precedence in the path over the 
 properly installed one - though I wouldn't think that you'd 
 manage that on multiple systems like that. So, I don't know, 
 but it's a thought.

 - Jonathan M Davis
nope. it cannot be any easier to install dmd I also verified all the versions using dmd --version. They are all the same version, straight off the dlang website. My TrueOS download just completed, so I'll give that a go later today. btw. I discovered that a small change to the code, and it will compile ok: -------------------------------------------------- import std.stdio; //import std.conv; // this will *not* compile. import std.conv : to; // this will compile ok. void main() { auto i = to!string(55); writeln("i is a ", typeof(i).stringof); } -----------------------------------------------
Nov 03
prev sibling parent reply codephantom <me noyb.com> writes:
On Saturday, 4 November 2017 at 03:19:00 UTC, Jonathan M Davis 
wrote:
 So, that implies that you're doing something funny, but if 
 you're installing dmd with an installer or package manager, 
 then I would think that it would at least be set up correctly.
ok. I worked it out. my file was named: to.d so that caused dmd some confusion it seems. change the name to something else, then dmd is ok with that code. There's some real 'gotchas' when it comes to file names and dmd... I'm not sure I like it. Interestingly, gdc didn't care that my file was named to.d, it did what I wanted the code to do. Would like dmd to do the same ;-) But ldc does the same thing as dmd...neither likes a file named to.d when you're calling a template with the same name.
Nov 04
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, November 04, 2017 08:02:38 codephantom via Digitalmars-d wrote:
 On Saturday, 4 November 2017 at 03:19:00 UTC, Jonathan M Davis

 wrote:
 So, that implies that you're doing something funny, but if
 you're installing dmd with an installer or package manager,
 then I would think that it would at least be set up correctly.
ok. I worked it out. my file was named: to.d so that caused dmd some confusion it seems. change the name to something else, then dmd is ok with that code. There's some real 'gotchas' when it comes to file names and dmd... I'm not sure I like it. Interestingly, gdc didn't care that my file was named to.d, it did what I wanted the code to do. Would like dmd to do the same ;-) But ldc does the same thing as dmd...neither likes a file named to.d when you're calling a template with the same name.
Per the spec, if you don't give a module declaration, the name of the module is the name of the file (minus the extension). So, if you just give a module name (which you generally would in any real program rather than a quick test program), then it's not a problem - unless you give the module a name which conflicts with something that you're trying to use. If you'd had module to; at the top of the module, then you'd have the same problem regardless of the file name. The module name wins out over the imported name when there's a conflict, because the module name is a local symbol. In practice, that's rarely a problem, though poor module-naming practices could certainly make it a problem. You can also work around it by using the fully qualified name (std.conv.to in this case) or by aliasing the symbol to a new name (I think that you can also statically import a symbol with a new name, but if so, that's basically the same as statically importing it and then aliasing it). If gdc doesn't have the same behavior, it's either a bug, and/or it's related to the fact that the last released version of gdc matched dmd 2.068 (IIRC). So, right now, gdc is a terrible compiler to use unless you don't care about using a really old version of D. I think that they're getting close to releasing an update that's much closer to the current version of dmd, but IIUC, the switch of the frontend from C++ to D was a huge roadblock for them, since they had a lot of redesign work to do (they also don't have much manpower). So, it's taken them quite a while to get back up-to-date. - Jonathan M Davis
Nov 04
parent reply codephantom <me noyb.com> writes:
On Saturday, 4 November 2017 at 08:17:44 UTC, Jonathan M Davis 
wrote:
 Per the spec, if you don't give a module declaration, the name 
 of the module is the name of the file (minus the extension). 
 So, if you just give a module name (which you generally would 
 in any real program rather than a quick test program), then 
 it's not a problem - unless you give the module a name which 
 conflicts with something that you're trying to use.
Thanks. I had actually read that spec, but forgot all about it. Having only used D for a month or so, I'm only writing snippets (107 so far), not actual programs. I actually had to edit the source code of my editor, so that when I create/save a .d file, if I happen to use hypens, then my editor will now automatically replace them with underscores (again, just because the way D deals with files). I think I'll do some more editing, and have my editor insert a default module name as well. Still, I don't like the spec. I would prefer that dmd did not implictly do stuff like that. Then I could regain the freedom to name my files however I wanted.
Nov 04
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, November 04, 2017 08:38:58 codephantom via Digitalmars-d wrote:
 On Saturday, 4 November 2017 at 08:17:44 UTC, Jonathan M Davis

 wrote:
 Per the spec, if you don't give a module declaration, the name
 of the module is the name of the file (minus the extension).
 So, if you just give a module name (which you generally would
 in any real program rather than a quick test program), then
 it's not a problem - unless you give the module a name which
 conflicts with something that you're trying to use.
Thanks. I had actually read that spec, but forgot all about it. Having only used D for a month or so, I'm only writing snippets (107 so far), not actual programs. I actually had to edit the source code of my editor, so that when I create/save a .d file, if I happen to use hypens, then my editor will now automatically replace them with underscores (again, just because the way D deals with files). I think I'll do some more editing, and have my editor insert a default module name as well. Still, I don't like the spec. I would prefer that dmd did not implictly do stuff like that. Then I could regain the freedom to name my files however I wanted.
Well, the modules need names. So, either, the compiler is going to have to pick a name for you, or you're going to have to give it one. In general though, D was designed with the idea that modules would match files and packages would match directories - and that the names on disk would match the ones in the file. Overall, things are much simpler that way. On some level, you can get around that by giving module names that don't match the file names, but in general, you're just begging for trouble if you don't make your file names and module names match (at least some stuff is going to be looking for modules by looking at the file system for them with the assumption that the package names match folders and the module names match files). So, in the long run, you'll just have fewer problems if you make your file names and module names match. - Jonathan M Davis
Nov 04
next sibling parent reply codephantom <me noyb.com> writes:
On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis 
wrote:
 Well, the modules need names. So, either, the compiler is going 
 to have to pick a name for you, or you're going to have to give 
 it one. In general though, D was designed with the idea that 
 modules would match files and packages would match directories 
 - and that the names on disk would match the ones in the file. 
 Overall, things are much simpler that way. On some level, you 
 can get around that by giving module names that don't match the 
 file names, but in general, you're just begging for trouble if 
 you don't make your file names and module names match (at least 
 some stuff is going to be looking for modules by looking at the 
 file system for them with the assumption that the package names 
 match folders and the module names match files). So, in the 
 long run, you'll just have fewer problems if you make your file 
 names and module names match.

 - Jonathan M Davis
Yes. All that makes complete sense I guess. It might also make sense, that if a source code file does not contain a module statement, then it should not be treated as a module, and the compiler should look to the import statements instead of implicitly making in a module. btw. That bug in gdc, which appear to do just that, is a nice bug ;-)
Nov 04
next sibling parent reply codephantom <me noyb.com> writes:
On Saturday, 4 November 2017 at 09:34:05 UTC, codephantom wrote:
 Yes. All that makes complete sense I guess.

 It might also make sense, that if a source code file does not 
 contain a module statement, then it should not be treated as a 
 module, and the compiler should look to the import statements 
 instead of implicitly making in a module.

 btw. That bug in gdc, which appear to do just that, is a nice 
 bug ;-)
I should add one more thing. Both Andrei's book (The D Programming Language), and Ali's book (Programming in D), provide the usual 'hello world' thing, at the beginning. In both cases, the 'module' statement is not part of that example. That is consistent with other 'hello world' I've seen in D. All the other code in both book also consistently leaves out the 'module' statement. My point being, given that "D is serious about modularity" (as Andrei put it in his book), then I think all 'hello world' examples should include the 'module' specifier as well, and explain why it's there too. I think that would really aid those who are new to the language..
Nov 04
parent reply rjframe <dlang ryanjframe.com> writes:
On Sat, 04 Nov 2017 09:51:12 +0000, codephantom wrote:

 It might also make sense, that if a source code file does not contain a
 module statement, then it should not be treated as a module, and the
 compiler should look to the import statements instead of implicitly
 making in a module.
I should add one more thing. Both Andrei's book (The D Programming Language), and Ali's book (Programming in D), provide the usual 'hello world' thing, at the beginning. In both cases, the 'module' statement is not part of that example. That is consistent with other 'hello world' I've seen in D. All the other code in both book also consistently leaves out the 'module' statement. My point being, given that "D is serious about modularity" (as Andrei put it in his book), then I think all 'hello world' examples should include the 'module' specifier as well, and explain why it's there too. I think that would really aid those who are new to the language..
Many people seem to leave the module statement out of their main.d/app.d files; I think it's a way to say "this is the main thing - don't import it from somewhere else." Basically, it's easier to act like that code isn't in a module than it is to have the compiler support code not in a module.
Nov 04
parent codephantom <me noyb.com> writes:
On Saturday, 4 November 2017 at 11:04:33 UTC, rjframe wrote:
 Many people seem to leave the module statement out of their 
 main.d/app.d files; I think it's a way to say "this is the main 
 thing - don't import it from somewhere else." Basically, it's 
 easier to act like that code isn't in a module than it is to 
 have the compiler support code not in a module.
I think maybe, the compiler should just refuse to compile anything, unless the module namespace is explicitely stated. I don't know what the effects of that would be in total, but it would avoid compilation errors when, for example, you do what I do - which is create 100's of snippets of code, save each snippet with a name corresponding to the thing 'snipped' (so I can easily find them again), and then discovering that they won't compile. (i.e. D having neither a default global namespace, and then the compiler making implicit assumptions about what namespace to use, based on the file name, seems problematic. Better to just 'refuse to compile' a file, unless it explicitely states a module namespace. e.g. (the .d files further below, without any module name specified, will not compile - presumably because the compiler is having problems resolving the namespace. So why is the compiler forced to do that anyway? Why not just refuse to compile simply because no module namespace was provided - then a nice clear message stating that, could be provided back to the user, instead of the cryptic message: " Error: function expected before (), not module writeln of type void" -----save this as writeln.d and it will not compile ----------------- import std.stdio; void main() { writeln("Hello World!"); } ------------------------------- -----save this as to.d and it will not compile ----------------- import std.stdio; import std.conv; void main() { auto i = to!string(55); } ----------------------------------------
Nov 04
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, November 04, 2017 09:34:05 codephantom via Digitalmars-d wrote:
 On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis

 wrote:
 Well, the modules need names. So, either, the compiler is going
 to have to pick a name for you, or you're going to have to give
 it one. In general though, D was designed with the idea that
 modules would match files and packages would match directories
 - and that the names on disk would match the ones in the file.
 Overall, things are much simpler that way. On some level, you
 can get around that by giving module names that don't match the
 file names, but in general, you're just begging for trouble if
 you don't make your file names and module names match (at least
 some stuff is going to be looking for modules by looking at the
 file system for them with the assumption that the package names
 match folders and the module names match files). So, in the
 long run, you'll just have fewer problems if you make your file
 names and module names match.

 - Jonathan M Davis
Yes. All that makes complete sense I guess. It might also make sense, that if a source code file does not contain a module statement, then it should not be treated as a module, and the compiler should look to the import statements instead of implicitly making in a module.
The language has no concept of any D code not being in a module. Not only would adding such a concept complicate things, but it wouldn't help real world programs. Having the module name infered from the file name was a simple solution to the problem and usually doesn't cause problems (at least as long as you're just dealing with toy programs). Personally, I think that we would have been better off just requiring the module statements (especially since it doesn't work to have modules in packages without the module statements), but I doubt that that change would be accepted at this point, particularly since it wouldn't matter for much other than toy programs. Mostly all it would do is force folks to use module statements up front when learning the language instead of trying to go without like some do and then inevitably hitting issues when they start to use packages. And that has value, but I doubt that it would be enough of an argument to get such a change made. - Jonathan M Davis
Nov 04
prev sibling parent codephantom <me noyb.com> writes:
On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis 
wrote:
 Well, the modules need names. So, either, the compiler is going 
 to have to pick a name for you, or you're going to have to give 
 it one.
ok..just one more ... I can't help myself.. I know that D does not have a 'global namespace', but what if did? Then, if a file does not declare its own module namespace (like none of my 109 snippets) then what's the big deal with having the compiler just use that (statically known) global name space. I wonder what the implication would be, if any. oh..and it would save a few keystrokes...which seems to be a main focus of numerous DIPs ;-)
Nov 04
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 03.11.2017 10:40, Walter Bright wrote:
 On 11/2/2017 7:43 PM, Jonathan M Davis wrote:
 I thought that that was just when explicitly loading a .dll or .so 
 file via
 something like dlopen or LoadLibrary instead of linking against it,
That's right. But given our resource limitations, I suggest the most pragmatic thing to do is support the latest FreeBSD, and leave older versions enabled in Druntime with `version` statements. That way the user could recompile Phobos for earlier versions if he needed it, but it wouldn't be officially supported. Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(
to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
Nov 03
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
 Note that dmd still runs on Windows XP, though it is not officially supported. 
 You just need to be careful about using TLS variables on it :-(
to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
The fact that we haven't officially tested that it works for years means be careful about attesting that it does work. Even simple DLL support in Windows keeps breaking because it is not part of the autotester test suite.
Nov 04
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, November 04, 2017 01:30:12 Walter Bright via Digitalmars-d 
wrote:
 On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
 Note that dmd still runs on Windows XP, though it is not officially
 supported. You just need to be careful about using TLS variables on it
 :-(
to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
The fact that we haven't officially tested that it works for years means be careful about attesting that it does work. Even simple DLL support in Windows keeps breaking because it is not part of the autotester test suite.
Just the other day, a fix for std.experimental.allocator that was supposed to fix FreeBSD 10.x/11.x fixed 32-bit but broke 64-bit - and it had no effect on FreeBSD 8.4 or whatever it is that's running on the main autotester FreeBSD boxes. The problem was caught and fixed, but for any given platform, unless we're running it as part of the autotester, or someone runs the tests locally and reports any breakages that occur, it's trivial for bugs to creep in, as annoying as that is. As such, I don't think that the odds are good at all that running modern D programs on Windows XP is going to work correctly in general. I don't expect that it's completely broken, but I sure wouldn't trust it without running the complete test suite in XP to verify whatever version of dmd, druntime, and Phobos you're trying to use - and I think that we may even be using some Windows API calls in Phobos which were introduced in Vista, since a lot of improved API calls were added in Vista, and it's certainly the case that _those_ won't work in XP. I confess that I have little sympathy if D doesn't work in XP though given that the fact that Microsoft doesn't support it anymore makes it completely unsafe to run unless it's not connected to the Internet. - Jonathan M Davis
Nov 04
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 04.11.2017 09:30, Walter Bright wrote:
 On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
 Note that dmd still runs on Windows XP, though it is not officially 
 supported. You just need to be careful about using TLS variables on 
 it :-(
to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
The fact that we haven't officially tested that it works for years means be careful about attesting that it does work.
It is working in Visual D since that time.
 
 Even simple DLL support in Windows keeps breaking because it is not part 
 of the autotester test suite.
Agreed, they haven't been officially tested a lot in the past, but you have merged the PR to do that back in April: https://github.com/dlang/dmd/pull/6709
Nov 04
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/4/2017 1:54 AM, Rainer Schuetze wrote:
 
 
 On 04.11.2017 09:30, Walter Bright wrote:
 On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
 Note that dmd still runs on Windows XP, though it is not officially 
 supported. You just need to be careful about using TLS variables on it :-(
to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
The fact that we haven't officially tested that it works for years means be careful about attesting that it does work.
It is working in Visual D since that time.
Ok, but does that mean you're testing the TLS support on XP? 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.)
 Even simple DLL support in Windows keeps breaking because it is not part of 
 the autotester test suite.
Agreed, they haven't been officially tested a lot in the past, but you have merged the PR to do that back in April: https://github.com/dlang/dmd/pull/6709
It's good that the samples work, but there's a bit more to the smoke test suite I had for it. I haven't tried it in a while.
Nov 05
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 5 November 2017 at 09:17:37 UTC, Walter Bright wrote:
 On 11/4/2017 1:54 AM, Rainer Schuetze wrote:
 
 
 On 04.11.2017 09:30, Walter Bright wrote:
 On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
 Note that dmd still runs on Windows XP, though it is not 
 officially supported. You just need to be careful about 
 using TLS variables on it :-(
to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
The fact that we haven't officially tested that it works for years means be careful about attesting that it does work.
It is working in Visual D since that time.
Ok, but does that mean you're testing the TLS support on XP? 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. 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.
Nov 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
 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.
Nov 05
next sibling parent reply codephantom <me noyb.com> writes:
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.
Nov 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/5/2017 6:44 PM, codephantom wrote:
 https://www.xylos.com/blog/en/2012/04/legacy-16-bit-applications-on-64-bi
-operating-systems/ 
Thanks for the link. I didn't know that, this clears it up!
Nov 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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-bi
-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 :-)
Nov 05
parent reply codephantom <me noyb.com> writes:
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.
Nov 05
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 06
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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/
Nov 06
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 06
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Thursday, 2 November 2017 at 04:25:26 UTC, 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,

 Andrei
Targetted versioning should be implemented. Full stop ;-) Pre ino64 ABI compatibility can be obtained in 12, **if** the kernel is compiled with option COMPAT_FREEBSD11 (presumably this option is enabled in the DEFAULT kernel)... That option enables 'several techniques' that can mitigate for ABI breakage, but it won't work for all cases - really depends on what the application is doing with struct stat. https://svnweb.freebsd.org/base/head/sys/sys/stat.h?view=markup#l158
Nov 01
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 06
next sibling parent reply codephantom <me noyb.com> writes:
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 ;-)
Nov 06
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 06
prev sibling parent codephantom <me noyb.com> writes:
On Monday, 6 November 2017 at 22:25:48 UTC, Andrei Alexandrescu 
wrote:
 it seems binary compatibility is not provided across major 
 versions.
Correction: ABI changes 'may' occur between major releases, and your binary may or may not run correctly, depending on whether those ABI changes are related to anything your binaries does - that is my understanding anyway. You can certainly take the DMD binaries and run them on 12 though. Beyond that, it just depends on what they're doing with regards to any change in the ABI. So one must study those ABI changes carefully, and consider their impact on DMD/PHOBOS etc... e.g does DMD/PHOBOS make of the inode struct? If so, where? And, what types are being used for storing the elements of that struct? I'm not sure many of us are in a position to investigate that any further.
 Like Walter, I'd be in favor of supporting the latest only.
Can I presume, by 'latest' you mean the latest 'release branch' (which would be the 11.x branch). If 'latest' actually means the CURRENT branch (aka HEAD), then that is 12, and it would be a mistake if that's is only what D was going to support (since most people wisely prefer to run a stable release branch (e.g 10.x, 11,x). If resources are limited, then I believe resources should be prioritised towards the latest release branch (which is the 11.x branch).
Nov 07