Re: how to detect OS architecture?
On Tue, 17 Dec 2013 13:21:30 -, Regan Heath wrote: Is GetNativeSystemInfo your other solution? On the MSDN page for GetNativeSystemInfo it recommends using IsWow64Process to detect if you're running under WOW64, at which point you would then call GetNativeSystemInfo. I am not sure what GetNativeSystemInfo does if called from a 32 bit exe on a 32 bit OS.. It seems to work. After all it makes sense, the native system is actually 32 bits. I /know/ that the code in std.internal.windows.advapi32 which dynamically loads and calls IsWow64Process will work, because we use it here at work for this very purpose. It's also the simplest most direct way to answer this specific question and it's already present, tested and working in phobos .. so I would be inclined to use it, in preference over GetNativeSystemInfo. R If after using IsWOW64Process a GetNativeSystemInfo must still be issued like you mentioned earlier, I don't see the advantage over calling that function directly in the first place. Or am I missing something?
Re: how to detect OS architecture?
On Tue, 17 Dec 2013 15:13:18 +0100, Gary Willoughby wrote: Make sure you handle if users have a 32bit OS installed on a 64bit PC. As a matter of fact that was the actual configuration in the system I wrote the app. I am now with a friend with the same configuration, and it also seems to be working. At work I use Windows 7 x86_64 and it also works.
Re: Type inference and overloaded functions
Namespace: No, not currently. But it is an interesting idea. Maybe I will implement this. A use case: https://d.puremagic.com/issues/show_bug.cgi?id=11757#c3 Visible in this line: key2[0 .. digestSize] = key.md5Of; But my suggested syntax is not that good, here $ has already a meaning, that is the whole length of b, So some different idea is needed here :-( b[0 .. $] = foo(); Otherwise you have to write code like: b[0 .. ReturnType!foo.length] = foo();
Re: Type inference and overloaded functions
On Tuesday, 17 December 2013 at 17:01:55 UTC, bearophile wrote:
Namespace:
Done:
https://github.com/D-Programming-Language/dmd/pull/2958
If you have a situation like this:
int[3] foo() {
typeof(return) a;
return a;
}
void main() {
int[100] b;
b[0 .. 3] = foo();
}
Can you use code like this to infer the length of the part
needed to copy?
int[3] foo() {
typeof(return) a;
return a;
}
void main() {
int[100] b;
b[0 .. $] = foo();
}
Bye,
bearophile
No, not currently. But it is an interesting idea. Maybe I will
implement this. And as far as I have enough time, I will also add
test cases. Maybe on christmas. :)
Re: migrating to 64 bit
Thanks Mike. I had come to the same conclusion as the dmd environment I copied over from 32 bit XP is working exactly as it used to in 64bit windows 8. Just being paranoid under the weight of newness I guess; its out to make everything we do obsolete you know.
Re: Shouldn't SList in std.container hold an owner pointer to verify a range belongs to the list?
On Tuesday, December 17, 2013 15:52:35 monarch_dodra wrote: > I'd be more afraid of DList's current semantics: Neither value > nor ref. I've been trying to fix it for more than a year now: > > https://github.com/D-Programming-Language/phobos/pull/953 Sorry. I keep meaning to look at it, but I'm so busy these days that I haven't had time to do much of anything with D. *sigh* - Jonathan M Davis
Re: libdl issues with DUB
On Tuesday, 17 December 2013 at 17:05:36 UTC, yazd wrote:
On Tuesday, 17 December 2013 at 12:41:16 UTC, Flamaros wrote:
When I build our project with DUB under linux I get some link
errors about libdl, that is messing.
In my main I have the following lines :
version(Posix)
{
pragma(lib, "dl");
}
This works well with MonoD, so it seems like version Posix
isn't defined with DUB or pragma ignored.
You'll need to add this to your package file:
"libs-posix": ["dl"]
Check the documentation here for more information
http://code.dlang.org/package-format#build-settings
The reason this works on DMD is that it builds and links the
executable in one step.
Dub separates that to two steps. And so this pragma will be
useless.
Thx.
It seems to be not the only Issue I got, I have a memory error
now.
I'll investigate on it.
Re: package.d
Hello again,
Reading DIP 37 ( http://wiki.dlang.org/DIP37 ) shed some light on the
issue, I think.
The motivation for package.d was to allow the split of a large module into
a package. From this perspective, the difference between package.d and
all.d regarding the fully-qualified names seems to make sense. But then,
the same DIP 37 says that "[using package.d] is identical to what some
projects have been doing with *all.d*, where they have a
*foo/bar/all.d*which publicly imports all of the
*bar* package, except that this provides additional syntactic sugar for it."
Is there any documentation describing the expected to behavior in regard to
the fully-qualified names of the publicly imported symbols in package.d? (
http://dlang.org/module.html doesn't mention package imports;
http://dlang.org/changelog.html#import_package doesn't mention
fully-qualified names).
Thank again,
LMB
On Mon, Dec 16, 2013 at 10:51 PM, Leandro Motta Barros wrote:
> Hello,
>
> I have some code using the old "all.d" idiom, which I am changing to use
> the new "package.d" feature.
>
> Originally, I had something like this:
>
> // mylib/util.d:
> module mylib.util;
> class Foo { }
>
> // mylib/all.d:
> module mylib.all;
> public import mylib.util;
>
> // main.d:
> import mylib.all;
> void main()
> {
>auto f = new mylib.util.Foo;
> }
>
> And this used to work. Now, I added a new file:
>
> // package.d
> module mylib;
> public import mylib.util;
>
> And changed the 'import' in the main one:
>
> // main.d
> import mylib;
>
> void main()
> {
>auto f = new mylib.util.Foo;
> }
>
> Now, the compiler complains:
>
> main.d(5): Error: undefined identifier 'util'
> main.d(5): Error: mylib.util.Foo is used as a type
>
> Isn't this 'package.d' feature supposed to work just as the old 'all.d'
> and '_,d' we used before?
>
> (I see that I can use 'mylib.Foo' instead of 'mylib.util.Foo', but
> http://dlang.org/module.html is clear saying that "[a]ll symbols from a
> publicly imported module are also aliased in the importing module. This
> means that if module D imports module C, and module C *publicly* imports
> module B which has the symbol *bar*, in module D you can access the
> symbol via bar, B.bar, and C.bar.")
>
> I am using DMD 2.064 here.
>
> Thanks,
>
> LMB
>
>
Re: Compile time checks and alias this
On Tuesday, 17 December 2013 at 21:28:12 UTC, Andrea Fontana wrote: Hey didn't this mean "is derived from"? :) Is there a way to check this at compile time? is(T : MyClass1) It actually means "is implicitly convertable to", which "is derived from" satisfies.
Re: Compile time checks and alias this
On Tuesday, 17 December 2013 at 17:19:26 UTC, anonymous wrote:
On Tuesday, 17 December 2013 at 16:50:18 UTC, Andrea Fontana
wrote:
I have something like this:
enum isValid(T) = is(T == MyClass1);
class MyClass1 {}
class MyContainer(T)
{
T value;
alias value this;
}
void main()
{
assert(isValid!MyClass1, "MyClass1 isn't valid");
assert(isValid!(MyContainer!MyClass1), "MyContainer!MyClass1
isn't valid");
}
second assert conditions is false. But in normal code
MyContainer!Myclass1 is casted automagically to MyClass1 and
works almost as MyClass1.
Hey didn't this mean "is derived from"? :)
Is there a way to check this at compile time?
is(T : MyClass1)
Re: Question about function aliases
On Thursday, 12 December 2013 at 11:39:56 UTC, FreeSlave wrote: I guess alias also should include extern(C) declaration i.e. the right way is alias Tcl_InterpDeleteProc = extern(C) void function(ClientData clientData, Tcl_Interp* interp) nothrow; Unfortunately that syntax doesn't compile. The alternative does however.
Re: Embed Windows Internet Explorer
Am 17.12.2013 17:34, schrieb Adam D. Ruppe: I'm not able to run your code but are you sure the web page control is sized in your window? One time I had a problem like this and it was because the control was a 1x1 pixel... I just checked, the dimensions of the main form are passed correctly to the IWebBrowser2 instance. GetClientRect(hwnd) is used and dimensions are evaluated correctly.
Re: tango -D2 regex
On Monday, 16 December 2013 at 17:20:59 UTC, Dmitry Olshansky
wrote:
16-Dec-2013 11:46, seany пишет:
I dont find any info on backtrack on tango-D2 regex.
For example, I want to match things like
barFOObar
or
bazFOObaz
so I would use, in PCRE, ^(\w*)FOO($1)$, with $1 meaning the
word (given
by \w* that was matced in the first subpattern (\w*)
With std.regex of Phobos this should just work.
auto re = regex(`^(\w*)FOO\1$`);
assert("barFOObar".match(re));
Syntax is like in JavaScript or Perl.
How to do the samein Tango for D2 (or even phobos for D2)?
thanks! this is what i was looking for (the \1)
Re: Compile time checks and alias this
On Tuesday, 17 December 2013 at 16:50:18 UTC, Andrea Fontana
wrote:
I have something like this:
enum isValid(T) = is(T == MyClass1);
class MyClass1 {}
class MyContainer(T)
{
T value;
alias value this;
}
void main()
{
assert(isValid!MyClass1, "MyClass1 isn't valid");
assert(isValid!(MyContainer!MyClass1), "MyContainer!MyClass1
isn't valid");
}
second assert conditions is false. But in normal code
MyContainer!Myclass1 is casted automagically to MyClass1 and
works almost as MyClass1.
Is there a way to check this at compile time?
is(T : MyClass1)
Re: libdl issues with DUB
On Tuesday, 17 December 2013 at 12:41:16 UTC, Flamaros wrote:
When I build our project with DUB under linux I get some link
errors about libdl, that is messing.
In my main I have the following lines :
version(Posix)
{
pragma(lib, "dl");
}
This works well with MonoD, so it seems like version Posix
isn't defined with DUB or pragma ignored.
You'll need to add this to your package file:
"libs-posix": ["dl"]
Check the documentation here for more information
http://code.dlang.org/package-format#build-settings
The reason this works on DMD is that it builds and links the
executable in one step.
Dub separates that to two steps. And so this pragma will be
useless.
using std.algorithm.topN with std.range.zip fails with undefined swap
Hi,
Trying to compile :
import std.stdio, std.range, std.algorithm;
void main() {
auto a = [2.0,1.0,3.0];
struct Point {
double x;
}
auto b = [Point(4.0), Point(5.0), Point(6.0)];
topN!("a[0] < b[0]")(zip(a,b),1);
//sort!("a[0] < b[0]")(zip(a,b));
writeln(a,b);
}
std/algorithm.d(8225): Error: template std.algorithm.swap does
not match any function template declaration.
Swapping out topN with sort works just fine. I assume both sort
and topN use swap, is there a reason this doesn't work with topN?
Thanks in advance,
-- Nikhil
Re: Type inference and overloaded functions
Namespace:
Done:
https://github.com/D-Programming-Language/dmd/pull/2958
If you have a situation like this:
int[3] foo() {
typeof(return) a;
return a;
}
void main() {
int[100] b;
b[0 .. 3] = foo();
}
Can you use code like this to infer the length of the part needed
to copy?
int[3] foo() {
typeof(return) a;
return a;
}
void main() {
int[100] b;
b[0 .. $] = foo();
}
Bye,
bearophile
Compile time checks and alias this
I have something like this:
enum isValid(T) = is(T == MyClass1);
class MyClass1 {}
class MyContainer(T)
{
T value;
alias value this;
}
void main()
{
assert(isValid!MyClass1, "MyClass1 isn't valid");
assert(isValid!(MyContainer!MyClass1), "MyContainer!MyClass1
isn't valid");
}
second assert conditions is false. But in normal code
MyContainer!Myclass1 is casted automagically to MyClass1 and
works almost as MyClass1.
Is there a way to check this at compile time?
Re: Embed Windows Internet Explorer
I'm not able to run your code but are you sure the web page control is sized in your window? One time I had a problem like this and it was because the control was a 1x1 pixel...
Re: Path to cmdfile?
On Monday, 16 December 2013 at 08:01:30 UTC, evilrat wrote: On Monday, 16 December 2013 at 07:33:47 UTC, Jeremy DeHaan wrote: I've been brain storming lately on some ideas to simplify building for the library I've been working on, and I wanted to do some experimenting using cmdfiles. Is there some way that I can pass a search path for these bad boys to the compiler if they are just text files? don't know about that, but there is string mixin search paths - using it with mixins may be possible alternative for what you trying to achieve(assuming you are using handmade D build script). I'm not exactly talking about building the library(though that does give me ideas for future experimenting), but making it easier for users to use it in their own projects. If I could have pre-made cmdfiles, the user could just send the compiler a location to where those are, and use them in their projects. I've already done some experimenting, and so far things have been successful, but I would really like a way to let the compiler know where to look for them. If this existed, it would make the build process quite a lot easier. I'm extremely new to Linux so I am still trying to work out some(a ton of) kinks, but here is an example of one of the cmdfiles I have been toying with. Name: dsfml-graphics -I/usr/local/src/ -L-L/usr/local/lib/dsfml -L-ldsfml-graphics-2 -L-ldsfml-graphics -L-ljpeg -L-lGL -L-lGLU -L-lfreetype -L-lGLEW I have a couple more files that are put together in a similar fashion with an end result being a command line that looks like this to build an example program: dmd main.d @dsfml-graphics @dsfml-window @dsfml-system Obviously this wouldn't work on every system , but it is a start and I really like how it has turned out so far. and also depending on your needs it may worth look at dub[1,2]. [1] http://code.dlang.org/download [2] https://github.com/rejectedsoftware/dub I've used DUB before and think it is really cool. Not everyone uses it, though. I'm trying to come up with a system that works well be it DUB, vanilla command line, or IDE.
Re: How to link to libdl under linux
Eventually i have lot of time to answer.
Here is what 'find' emits:
andrey@andress-ubuntu:~/anchovy$ find /lib /lib32 /usr/lib
/usr/lib32 -name "libdl*.so*" -type f -exec file {} ";"
/lib/i386-linux-gnu/libdl-2.17.so: ELF 32-bit LSB shared object,
Intel 80386, version 1 (SYSV), dynamically linked (uses shared
libs), BuildID[sha1]=0x37b128aa3fc5f9e2078059787463f6bb611b03d2,
for GNU/Linux 2.6.24, stripped
/lib/x86_64-linux-gnu/libdl-2.17.so: ELF 64-bit LSB shared
object, x86-64, version 1 (SYSV), dynamically linked (uses shared
libs), BuildID[sha1]=0xa39d9d93eb46ba4511ee1a8971d5f90b1e67d999,
for GNU/Linux 2.6.24, stripped
/lib32/libdl-2.17.so: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs),
BuildID[sha1]=0x686964642d380ed673813bc5f421eed8cb7de32b, for
GNU/Linux 2.6.24, stripped
/usr/lib/libreoffice/program/libdlgprovlo.so: ELF 64-bit LSB
shared object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=0xfb0d088f0da1219a0c5590beb9db9873cf5d1177, stripped
/usr/lib/debug/lib/x86_64-linux-gnu/libdl-2.17.so: ELF 64-bit LSB
shared object, x86-64, version 1 (SYSV), dynamically linked (uses
shared libs),
BuildID[sha1]=0xa39d9d93eb46ba4511ee1a8971d5f90b1e67d999, for
GNU/Linux 2.6.24, not stripped
Here i use verbose linking:
andrey@andress-ubuntu:~/anchovy$ dmd -debug -gc -m32
"examples/fpshelper.d" "examples/main.d" -I"import"
-I"deps/dlib" -I"deps/derelict-fi-master/source"
-I"deps/derelict-sdl2-master/source"
-I"deps/derelict-ft-master/source"
-I"deps/derelict-gl3-master/source"
-I"deps/derelict-glfw3-master/source"
-I"deps/derelict-util-1.0.0/source" "lib/debug/libgui.a"
"lib/debug/libgraphics.a" "lib/debug/libcore.a"
"lib/debug/libutils.a" "deps/dlib/libdlib.a"
"deps/derelict-fi-master/lib/libDerelictFI.a"
"deps/derelict-ft-master/lib/libDerelictFT.a"
"deps/derelict-gl3-master/lib/libDerelictGL3.a"
"deps/derelict-glfw3-master/lib/libDerelictGLFW3.a"
"deps/derelict-util-1.0.0/lib/libDerelictUtil.a" -L--verbose
-L-ldl -of"bin/guidemo" > link.txt
deps/derelict-fi-master/lib/libDerelictFI.a(sharedlib_416_4ee.o):
In function `_D8derelict4util9sharedlib13LoadSharedLibFAyaZPv':
/home/andrey/anchovy/deps/derelict-fi-master/../../../.dub/packages/derelict-util-1.0.0/source/derelict/util/sharedlib.d:60:
undefined reference to `dlopen'
deps/derelict-fi-master/lib/libDerelictFI.a(sharedlib_417_5d1.o):
In function `_D8derelict4util9sharedlib15UnloadSharedLibFPvZv':
/home/andrey/anchovy/deps/derelict-fi-master/../../../.dub/packages/derelict-util-1.0.0/source/derelict/util/sharedlib.d:64:
undefined reference to `dlclose'
deps/derelict-fi-master/lib/libDerelictFI.a(sharedlib_418_396.o):
In function `_D8derelict4util9sharedlib9GetSymbolFPvAyaZPv':
/home/andrey/anchovy/deps/derelict-fi-master/../../../.dub/packages/derelict-util-1.0.0/source/derelict/util/sharedlib.d:68:
undefined reference to `dlsym'
deps/derelict-fi-master/lib/libDerelictFI.a(sharedlib_419_463.o):
In function `_D8derelict4util9sharedlib11GetErrorStrFZAya':
/home/andrey/anchovy/deps/derelict-fi-master/../../../.dub/packages/derelict-util-1.0.0/source/derelict/util/sharedlib.d:72:
undefined reference to `dlerror'
collect2: error: ld returned 1 exit status
and here is content of link.txt http://pastebin.com/G3vyt345
Re: libdl issues with DUB
Am Tue, 17 Dec 2013 13:41:14 +0100
schrieb "Flamaros" :
> When I build our project with DUB under linux I get some link
> errors about libdl, that is messing.
> In my main I have the following lines :
>
> version(Posix)
> {
> pragma(lib, "dl");
> }
>
> This works well with MonoD, so it seems like version Posix isn't
> defined with DUB or pragma ignored.
More likely you do a one-step build in Mono-D and compile
single modules through DUB.
Can you post the exact error message please? Does it print
libdl or does it complain about undefined dlopen et altera?
--
Marco
Re: how to detect OS architecture?
Am Tue, 17 Dec 2013 13:30:25 - schrieb "Regan Heath" : > On Mon, 16 Dec 2013 21:27:13 -, Hugo Florentino wrote: > > > On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote: > >> On 2013-12-16 17:46, Marco Leise wrote: > >> > >>> Hehe, I guess the whole purpose of the launcher is to run in > >>> 32-bit and detect at runtime if the 64-bit main executable can > >>> be run or the 32-bit version must be used. > >> > >> The only advantage of that is that only a 32bit launcher needs to be > >> distributed. Perhaps that's the whole idea. > > > > It is. :) > > "Process Explorer" by sysinternals, now distributed by M$ does something > similar. > http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx > > It is a 32 bit exe, which detects the OS bit width and if it's 64 bit > extracts a 64 exe from within itself to run. When you quit that 64 bit > exe, it deletes the file it extracted from disk. It's quite a neat > solution. > > R > Only if your executable is self-contained. If you already have external DLLs or assets you can as well have a launcher and 2 actual binaries. -- Marco
Re: Shouldn't SList in std.container hold an owner pointer to verify a range belongs to the list?
On 12/17/13, monarch_dodra wrote: > Didn't I reply to this already? dlang.org was down recently, maybe the forum was as well. :) > Anyways... what I said is that we can add the test in > non-release, but I see it as assertive code, so it can be removed > in release. Sure: version(assert) SList owner; Works for me. > I'd be more afraid of DList's current semantics: Neither value > nor ref. I've been trying to fix it for more than a year now: > > https://github.com/D-Programming-Language/phobos/pull/953 I'll take a look.
Re: Shouldn't SList in std.container hold an owner pointer to verify a range belongs to the list?
On Monday, 16 December 2013 at 21:57:52 UTC, Andrej Mitrovic
wrote:
Here's some improper code that is not checked properly by SList
(meaning no assertions, not even in debug mode):
-
import std.stdio;
import std.container;
void main()
{
auto s1 = SList!string(["a", "b", "d"]);
auto s2 = SList!string(["a", "b", "d"]);
// note the s1[] instead of s2[]!
s2.insertAfter(std.range.take(s1[], 2), "c");
writeln(s1[]); // updated s1, not s2!
writeln(s2[]); // s2 stays the same.
}
-
Note the docs of insertAfter:
Inserts $(D stuff) after range $(D r), which must be a range
previously extracted from this container.
Well clearly we have a range extracted from one list being used
to add
items to a different list, but SList makes no checks at all to
verify
the range belongs to it. I had a look at DCollections[1], and it
stores an "owner" pointer (or reference) in the range type when
its
extracted from a linked-list, so it can do these types of sanity
checks.
So shouldn't we add this to SList? We'd have to add an owner
field to
its internal "Range" struct.
[1] : https://github.com/schveiguy/dcollections
Didn't I reply to this already?
Anyways... what I said is that we can add the test in
non-release, but I see it as assertive code, so it can be removed
in release.
I'd be more afraid of DList's current semantics: Neither value
nor ref. I've been trying to fix it for more than a year now:
https://github.com/D-Programming-Language/phobos/pull/953
Re: how to detect OS architecture?
On Monday, 16 December 2013 at 21:23:11 UTC, Hugo Florentino
wrote:
GetNativeSystemInfo worked. Thanks!
The code ended being like this (it seems to be working both in
x86 and x86_64):
import std.file: exists, getcwd;
import std.path: buildPath, dirName;
import std.string: format, toStringz;
import core.sys.windows.windows;
enum X86 = 0;
enum AMD64 = 9;
immutable static auto appname = "myapp";
extern(Windows) HANDLE ShellExecuteA(HWND, LPCSTR, LPCSTR,
LPCSTR, LPCSTR, int);
extern(Windows) int MessageBoxA(HWND, LPCSTR, LPCSTR, UINT);
int main() {
auto appath = getcwd();
string appexe;
SYSTEM_INFO env;
GetNativeSystemInfo(&env);
switch(env.wProcessorArchitecture) {
case X86: appexe = buildPath(appath, appname ~ "32.exe");
break;
case AMD64: appexe = buildPath(appath, appname ~ "64.exe");
break;
default:
MessageBoxA(null, "System architecture is not
supported.", "Error", MB_ICONHAND + MB_OK);
return -1;
}
if (exists(appexe)) {
auto param = format(`/ini="%s"`, buildPath(appath, appname
~ ".ini"));
ShellExecuteA(null, "", toStringz(appexe),
toStringz(param), "", SW_SHOWMAXIMIZED);
scope(failure) return -2;
}
return 0;
}
Make sure you handle if users have a 32bit OS installed on a
64bit PC.
Re: how to detect OS architecture?
On Mon, 16 Dec 2013 21:27:13 -, Hugo Florentino wrote: On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote: On 2013-12-16 17:46, Marco Leise wrote: Hehe, I guess the whole purpose of the launcher is to run in 32-bit and detect at runtime if the 64-bit main executable can be run or the 32-bit version must be used. The only advantage of that is that only a 32bit launcher needs to be distributed. Perhaps that's the whole idea. It is. :) "Process Explorer" by sysinternals, now distributed by M$ does something similar. http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx It is a 32 bit exe, which detects the OS bit width and if it's 64 bit extracts a 64 exe from within itself to run. When you quit that 64 bit exe, it deletes the file it extracted from disk. It's quite a neat solution. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: how to detect OS architecture?
On Mon, 16 Dec 2013 21:26:31 -, Hugo Florentino wrote: On Mon, 16 Dec 2013 17:04:18 -, Regan Heath wrote: ... Compile the launcher as 32bit, and use this global boolean "isWow64": ... Thanks, it's nice to have another option. What do you guys think are the possible advantages/disadvantages of either solution? Is GetNativeSystemInfo your other solution? On the MSDN page for GetNativeSystemInfo it recommends using IsWow64Process to detect if you're running under WOW64, at which point you would then call GetNativeSystemInfo. I am not sure what GetNativeSystemInfo does if called from a 32 bit exe on a 32 bit OS.. I /know/ that the code in std.internal.windows.advapi32 which dynamically loads and calls IsWow64Process will work, because we use it here at work for this very purpose. It's also the simplest most direct way to answer this specific question and it's already present, tested and working in phobos .. so I would be inclined to use it, in preference over GetNativeSystemInfo. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
libdl issues with DUB
When I build our project with DUB under linux I get some link
errors about libdl, that is messing.
In my main I have the following lines :
version(Posix)
{
pragma(lib, "dl");
}
This works well with MonoD, so it seems like version Posix isn't
defined with DUB or pragma ignored.
Re: migrating to 64 bit
On 12/17/2013 6:13 AM, Stephen Jones wrote: Thanks for your answers but I wasn't quite clear about what I asking. Basically I am on a 64 bit os but I want to continue compiling for a 32 bit os. I don't want to reconfigure Derelict because I already have all the functionality I need from Derelict. Until dmd on Windows 64 bit is sorted out, including a clear procedure for setting up the linker I have no need or wish to compile for 64 bit. Especially since any d program that compiles on 32 bit will compile under 64 bit. DMD *is* sorted out on Windows 64. To compile 32-bit, you do nothing special. To compile 64-bit programs, you set up the Visual Studio toolchain as described in the wiki[1] and pass the -m64 flag on the command line. Is there a flag on dmd that forces it to assume it is creating 32 bit object files? Or is this not possible? Typeing 'dmd' with no args will show you all supported flags, including -m32 and -m64. The former generates 32-bit objects and the latter 64-bit objects. On Windows, 32-bit is the default so you do not need to do anything. [1] http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible)
