rehabilitating Juno
This is specifically for Jesse K Phillips, Jesse, It appears we're both interested in Juno. You lack time and I lack D experience. What could a D clown do for your juno repository to get it functional again. The last time I grabbed the code and ran it vs. current D compiler I got a whole bunch of errors for what appear to be base D packages. Feel free to give me scutwork if that will help get Juno back into orbit.
Missed it by THIS much
This is me trying to link with Juno and getting tantalizingly close to success. DMD home is d:\d so binaries are d:\d\dmd2\windows\bin (on path) Juno is in D:\dlang\Juno-Windows-Class-Library D:\dlang\Juno-Windows-Class-Library\juno.lib exists sc.ini is untouched D:\dlang\Juno-Windows-Class-Library\examples\com>dmd -L+d:\dlang\Juno-Windows-Cl ass-Library\juno.lib -Id:\dlang\Juno-Windows-Class-Library events.d OPTLINK (R) for Win32 Release 8.00.15 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html d:\dlang\Juno-Windows-Class-Library\juno.lib(core) Error 42: Symbol Undefined _VarCmp@16 --- errorlevel 1 I'm pretty sure I've got the -L+ part right because when I didn't I got about 20 Symbol Undefined errors and if I leave out the -I part it doesn't even compile. What's the trick to get the link to work?
implib and system dlls, oh my
On Tuesday, 24 June 2014 at 04:37:56 UTC, Rikki Cattermole wrote: On 24/06/2014 1:13 p.m., Jason King wrote: This is me trying to link with Juno and getting tantalizingly close to success. DMD home is d:\d so binaries are d:\d\dmd2\windows\bin (on path) Juno is in D:\dlang\Juno-Windows-Class-Library D:\dlang\Juno-Windows-Class-Library\juno.lib exists sc.ini is untouched D:\dlang\Juno-Windows-Class-Library\examples\com>dmd -L+d:\dlang\Juno-Windows-Cl ass-Library\juno.lib -Id:\dlang\Juno-Windows-Class-Library events.d OPTLINK (R) for Win32 Release 8.00.15 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html d:\dlang\Juno-Windows-Class-Library\juno.lib(core) Error 42: Symbol Undefined _VarCmp@16 --- errorlevel 1 Looks like that's a Windows API function [0]. Get it to link with OleAut32 and it should work, if I'm correct. Thanks, Rikki There was a pragma(lib,"oleaut32.lib") in one of the source files, so it should have been linking. The problem now is that the DM oleaut32.lib doesn't include a _VarCmp@16. I ran lib -l oleaut32.lib to get a list file. No exported _VarCmp@16. There were 400-odd lines of exports so I believe lib -l worked. If I run implib /s oleaut32.lib oleaut32.dll vs. a windows XP oleaut32.dll I get an oleaut32.lib that includes a _VarCmp (not _VarCmp@16). What's the secret sauce to creating an oleaut32.lib that's fully decorated? Is there a way to get a newer oleaut32.lib into the d distributions. The full dmc oleaut32.lib is also missing _VarCmp@16 so no joy there either.
Re: implib and system dlls, oh my
I don't know enough about implib to explain it. But another method that I believe should work is to use linker definition files. It'll allow optlink to work. Just add it to dmd, actually I believe it needs to be passed to Optlink (so -L it). Another fix, might be to use 64bit, but shouldn't be required. [0] http://www.dsource.org/projects/bindings/wiki/DefFiles/OleAut32 Rikki, Thank you for your kind attention. I spewed to the newsgroup and googled for an answer in the wrong order. It appears the solution to this problem is the combination of coffimplib + windows SDK. After using those on the SDK's oleaut32.lib I got a library with the properly decorated _VarCmp@16. Not your job, but this could probably be made simpler.
Re: rehabilitating Juno
FYI after running coffimplib over SDK versions of oleaut32.lib and gdiplus.lib I've gotten all the examples in the makefile to run. Next up for me is to get tlbimpld compiling and I'll fork and do a pull request to add that to the makefile.
Re: Why is the Win32 boilerplate the way it is?
On Monday, 30 June 2014 at 05:30:23 UTC, Jeremy Sorensen wrote: Assuming the nCmdShow thing isn't a problem I see no reason why the wiki should tell people to use WinMain at all. If MSDN is to be believed VOID WINAPI GetStartupInfo( _Out_ LPSTARTUPINFO lpStartupInfo ); will get you nCmdShow and lots of other goodies.
Re: Why is the Win32 boilerplate the way it is?
On Monday, 30 June 2014 at 15:19:39 UTC, Adam D. Ruppe wrote: On Monday, 30 June 2014 at 15:14:24 UTC, Jeremy Sorensen wrote: documentation means "import core.sys.windows.windwos" The Windows headers that come with D are pathetically minimal. You'll need to grab a more complete win32 header OR copy/paste the individual prototypes off MSDN and use them that way. This is a more complete set of windows api headers https://github.com/AndrejMitrovic/WindowsAPI
Re: implib and system dlls, oh my
You may want to spearhead the effort to get Win32 support of MSVC into D, if you care enough about it. Rainer has done most of the work, you'd just have to turn his patches into pull requests, shepherd them through the review process, and maybe add some polish: http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com Let me see what I can do for time. There's the above, it's also possible to link mixed coff and omf with jwlink (http://www.japheth.de/JWlink/JWlink.htm). There's a couple of paths and while win32 isn't leading edge, I think enhancing it is a worthwhile project for lesser lights like myself.
Re: implib and system dlls, oh my
You may want to spearhead the effort to get Win32 support of MSVC into D, if you care enough about it. Rainer has done most of the work, you'd just have to turn his patches into pull requests, shepherd them through the review process, and maybe add some polish: http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com I'd love to, but that might be a little over my head. I see he forked from 2.060 and now we're almost in 2.066. I'd have to radically improve my git fu and my D fu to be able to bring the patches up to 2.066. I'm on some extended time off in a couple of weeks for some surgery, this might be a project to while away the recovery days.
Re: implib and system dlls, oh my
Let me see what I can do for time. There's the above, it's also possible to link mixed coff and omf with jwlink (http://www.japheth.de/JWlink/JWlink.htm). There's a couple of paths and while win32 isn't leading edge, I think enhancing it is a worthwhile project for lesser lights like myself. I've tried the above and get a horde of errors. Some seem to be weak link __symbol doesn't match the library's _symbol (two leading underbars on one side, one on the other). Some seem to be some utterly missing capitalized symbols like GETLONG, GETPOINTER and STRLEN2. The underbar mismatches I should be able to fix with a def file or maybe there's a (j)wlink option I missed to resolve those. As I make progress, such as it is, I'll report. Anybody who sees something I've missed feel free to chime in. While I'm learning I have no pride, I save it for pride in having learned.
Re: DMDScript
On Friday, 11 July 2014 at 15:45:42 UTC, Chris wrote:
Tried to compile on linux, got this error message (I guess I
can fix it):
dmd -c textgen.d
textgen.d(36): Error: cannot implicitly convert expression
("DMDScript fatal runtime error: ") of type string to char[]
.. bunch more errors.
You might try
https://github.com/DmitryOlshansky/DMDScript which, according to
it's notes has changes to make it compatible with D2.
Re: SImple C++ code to D
On Monday, 14 July 2014 at 14:50:36 UTC, Alexandre wrote: Yes yes, I did it, I used the anonymous type Look the complete code: https://gist.github.com/bencz/3576dfc8a217a34c05a9 I know, has several things that can be improved Now that you've done that, can you build us a linker that reads COFF libs so we can lose optlink:)
Re: DMDScript
My idea is to use (at least test) DMDScript for server side JS. I don't mean to sound like a D-hater here, but V8 has had about 2 years more work on it than DMDScript. At one time they were. IIRC, quite close performance-wise but lots of work and support by Google have probably levered past the advantages of being coded in D. My 2c only.
