On Thursday, 5 November 2015 at 11:12:11 UTC, johann wrote:
> On Thursday, 5 November 2015 at 11:07:04 UTC, johann wrote:
>> On Wednesday, 4 November 2015 at 18:33:49 UTC, Rainer Schuetze wrote:
>>> [...]
>>
>> could you import that automatically?
>> i just made an console program with nothing in it - except the main.d with the content:
>>
>> import std.stdio;
>>
>> int main(string[] argv)
>> {
>>     writeln("Hello D-World!");
>>     return 0;
>> }
>
> now getting another error:
> LIBCMT.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)

sorry forgot to mention

installed 2069 new
installed visuald Visual D 0.3.43 beta1
use VS2015

On 05.11.2015 12:07, johann wrote:
>>
>> It seems it fails to add legacy_stdio_definitions.lib to the link
>> command line. You could try to add it to the "additional linker
>> options" in the globl settings as a workaround.
>
> could you import that automatically?

Yeah, I already fixed that. It'll be in the next beta.

On 05.11.2015 12:11, johann wrote:
> On Thursday, 5 November 2015 at 11:07:04 UTC, johann wrote:
>> On Wednesday, 4 November 2015 at 18:33:49 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 04.11.2015 10:32, tester wrote:
>>>> [...]
>>>
>>> It seems it fails to add legacy_stdio_definitions.lib to the link
>>> command line. You could try to add it to the "additional linker
>>> options" in the globl settings as a workaround.
>>
>> could you import that automatically?
>> i just made an console program with nothing in it - except the main.d
>> with the content:
>>
>> import std.stdio;
>>
>> int main(string[] argv)
>> {
>>     writeln("Hello D-World!");
>>     return 0;
>> }
>
> now getting another error:
> LIBCMT.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol
> WinMain referenced in function "int __cdecl
> __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)

I guess you have changed the subsystem to "Windows". main doesn't seem to work then (only for "Console"), you'll have to implement WinMain as in the WindowsApplication template.

On 01.11.2015 11:29, Rainer Schuetze wrote:
> Hi,
>
> I just uploaded a beta for the next release of Visual D.
>
> You can find the list of changes and the installer here:
>
> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1
>
>
> Rainer

Now updated to a new beta:

https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta2

On Thursday, 5 November 2015 at 20:27:32 UTC, Rainer Schuetze wrote:
>
>
> On 05.11.2015 12:11, johann wrote:
>> On Thursday, 5 November 2015 at 11:07:04 UTC, johann wrote:
>>> On Wednesday, 4 November 2015 at 18:33:49 UTC, Rainer Schuetze wrote:
>>>>
>>>>
>>>> On 04.11.2015 10:32, tester wrote:
>>>>> [...]
>>>>
>>>> It seems it fails to add legacy_stdio_definitions.lib to the link
>>>> command line. You could try to add it to the "additional linker
>>>> options" in the globl settings as a workaround.
>>>
>>> could you import that automatically?
>>> i just made an console program with nothing in it - except the main.d
>>> with the content:
>>>
>>> import std.stdio;
>>>
>>> int main(string[] argv)
>>> {
>>>     writeln("Hello D-World!");
>>>     return 0;
>>> }
>>
>> now getting another error:
>> LIBCMT.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol
>> WinMain referenced in function "int __cdecl
>> __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
>
> I guess you have changed the subsystem to "Windows". main doesn't seem to work then (only for "Console"), you'll have to implement WinMain as in the WindowsApplication template.

thanks for the help pointers.
i generated the dfl2 lib anew with the current compiler - works fine for x64. the lib was seemingly maintained by a gentleman named franklike.
as for main, i used the following code:

import dfl.all;
int main()
{
	Form myForm;
	Label myLabel;
	myForm = new Form;
	myForm.text = "DFL Example";
	myLabel = new Label;
	myLabel.font = new Font("Verdana", 14f);
	myLabel.text = "Hello, DFL World!";
	myLabel.location = Point(15, 15);
	myLabel.autoSize = true;
	myLabel.parent = myForm;
	Application.run(myForm);
	return 0;
}

i set the subsystem to console (or 'Not Set') and try to link with the dfl2 lib. that works for console and it runs as expected - just with console window in the background.

if i set it to windows subsystem the link fails with:
LIBCMT.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
Release\dflTEST.exe : fatal error LNK1120: 1 unresolved externals
Building Release\dflTEST.exe failed!

do you have any suggestion what happens? how can i get rid of the console window after linking?

On 06.11.2015 08:45, johann wrote:
> On Thursday, 5 November 2015 at 20:27:32 UTC, Rainer Schuetze wrote:
>> I guess you have changed the subsystem to "Windows". main doesn't seem
>> to work then (only for "Console"), you'll have to implement WinMain as
>> in the WindowsApplication template.
>
> thanks for the help pointers.
> i generated the dfl2 lib anew with the current compiler - works fine for
> x64. the lib was seemingly maintained by a gentleman named franklike.
> as for main, i used the following code:
>
> import dfl.all;
> int main()
> {
>      Form myForm;
>      Label myLabel;
>      myForm = new Form;
>      myForm.text = "DFL Example";
>      myLabel = new Label;
>      myLabel.font = new Font("Verdana", 14f);
>      myLabel.text = "Hello, DFL World!";
>      myLabel.location = Point(15, 15);
>      myLabel.autoSize = true;
>      myLabel.parent = myForm;
>      Application.run(myForm);
>      return 0;
> }
>
> i set the subsystem to console (or 'Not Set') and try to link with the
> dfl2 lib. that works for console and it runs as expected - just with
> console window in the background.
>
> if i set it to windows subsystem the link fails with:
> LIBCMT.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol
> WinMain referenced in function "int __cdecl
> __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
> Release\dflTEST.exe : fatal error LNK1120: 1 unresolved externals
> Building Release\dflTEST.exe failed!
>
> do you have any suggestion what happens? how can i get rid of the
> console window after linking?
>

The VC runtime libraries expect a WinMain entry point if you compile for subsystem windows, so you should replace main() with WinMain:

import core.runtime;
import core.sys.windows.windows;

extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
      Runtime.initialize();

      Form myForm;
      ...
      Runtime.terminate();
      return 0;
}

AFAICT this was different in earlier versions of the VC runtime. I'm not sure if the D runtime can/should try to redirect this to main().

On Friday, 6 November 2015 at 13:08:51 UTC, Rainer Schuetze wrote:
>
>
> On 06.11.2015 08:45, johann wrote:
>>[...]
>
> The VC runtime libraries expect a WinMain entry point if you compile for subsystem windows, so you should replace main() with WinMain:
>
> import core.runtime;
> import core.sys.windows.windows;
>
> extern (Windows)
> int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
> {
>       Runtime.initialize();
>
>       Form myForm;
>       ...
>       Runtime.terminate();
>       return 0;
> }
>
> AFAICT this was different in earlier versions of the VC runtime. I'm not sure if the D runtime can/should try to redirect this to main().

thanks - i tried that and it doesn't work. i am bust now.

On 06.11.2015 14:46, johann wrote:
> On Friday, 6 November 2015 at 13:08:51 UTC, Rainer Schuetze wrote:
>>
>>
>> On 06.11.2015 08:45, johann wrote:
>>> [...]
>>
>> The VC runtime libraries expect a WinMain entry point if you compile
>> for subsystem windows, so you should replace main() with WinMain:
>>
>> import core.runtime;
>> import core.sys.windows.windows;
>>
>> extern (Windows)
>> int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
>> lpCmdLine, int nCmdShow)
>> {
>>       Runtime.initialize();
>>
>>       Form myForm;
>>       ...
>>       Runtime.terminate();
>>       return 0;
>> }
>>
>> AFAICT this was different in earlier versions of the VC runtime. I'm
>> not sure if the D runtime can/should try to redirect this to main().
>
> thanks - i tried that and it doesn't work. i am bust now.

"doesn't work" means same error?

The WindowsApplication project template works for me, maybe you can use it as a starting point.

On Saturday, 7 November 2015 at 13:01:12 UTC, Rainer Schuetze wrote:
>
> On 06.11.2015 14:46, johann wrote:
>> On Friday, 6 November 2015 at 13:08:51 UTC, Rainer Schuetze wrote:
>>> [...]
>>
>> thanks - i tried that and it doesn't work. i am bust now.
>
> "doesn't work" means same error?
>
> The WindowsApplication project template works for me, maybe you can use it as a starting point.

sorry - sure it works, but when i use your example, it does not produce a window - just does nothing. there seems to be a conflict with dfl2, well thats at least my guess.

On Thursday, 5 November 2015 at 22:12:39 UTC, Rainer Schuetze wrote:
>
>
> On 01.11.2015 11:29, Rainer Schuetze wrote:
>> Hi,
>>
>> I just uploaded a beta for the next release of Visual D.
>>
>> You can find the list of changes and the installer here:
>>
>> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1
>>
>>
>> Rainer
>
> Now updated to a new beta:
>
> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta2

Thank you for the update!  It fixed my link issues.

I have found a very strange issue with I *think* visual D.  I have condensed into a very small repro here: http://1drv.ms/1Oai14L (entire solution).  If I build and run on x86 build config, everything is fine.  But on x64, debugging (with Debug x64 config) will cause an exception somewhere on this line:

writeln(AnotherColor.Red.stringof); // AnotherColor is an enum

But if I were to run the exe from the command line it is fine.  Release version is fine too.  Also, it is fine if I put a breakpoint on the first line in main.d and then step over each line.  But hitting continue will throw an exception.  I'm not exactly sure where the exception comes from:
 	DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() + 0x32 bytes	D
 	DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv() + 0x6f bytes	D
 	DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv() + 0x3c bytes	D
 	DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv() + 0x6f bytes	D
 	DPlayground.exe!_d_run_main() + 0x421 bytes	D
 	DPlayground.exe!__entrypoint.main( int argc, char** argv ) + 0x22 bytes	D
>	DPlayground.exe!invoke_main() Line 75	D
 	DPlayground.exe!__scrt_common_main_seh() Line 264 + 0x5 bytes	D
 	DPlayground.exe!__scrt_common_main() Line 309	D
 	DPlayground.exe!mainCRTStartup() Line 17	D

Have you seen anything like this before?