Chris <chris@widdows.demon.nl> wrote in news:kqvlut4l3ftd54llhmi3k9cg1n8g6ctskl@4ax.com:

> Could you tell me more about the V port, I wasn't very succesfull finding info on that.
> 
> Chris.
> 

About V GUI (well, searching for V on the 'Net can be tough ;), you can visit www.objectcentral.com.  Shortly said, it's a LGPL'd GUI toolkit, portable across platforms.  With the same source code, you can build binaries for Win32, OS/2, GNU/Linux and other UN*X flavors (using MIT Athena, Motif or GTK in the background) and I'm not sure if Mac is on the list.  It's small, looks reasonably good, while maintaing platform-specific look-n-feel.  Crossplatform is important for me, so I'm using it.  It even has platform-independent printing support and OpenGL support!

About the DMC port of V, unless someone has done it independently, I don't think you'll find anything for now... I didn't publish it yet!  (web-space provider problems).  For now, I only have the main DMC Makefile working, and a few (not all) of the demos.  Unfortunately, VIDE is not on the list yet...

The problem is DMC's make does not support implicit rules that generates/(depends on) files in different directories.  So I had to write custom Perl scripts to generate makefiles for Walter's make (not for smake).

Another issue is that, AFAIK, with DMC you cannot have WinMain() placed in a library, as with other compilers (BCC, gcc), so you'll have to link vstartup.obj explicitly each time, besides vgui.lib.  Pretty weird limitation, but oh well... :)


Regards,
  Laurentiu

"Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:Xns91545E3A4A10Fplaurcrosswindsnet@63.105.9.61...
> The problem is DMC's make does not support implicit rules that generates/(depends on) files in different directories.  So I had to write custom Perl scripts to generate makefiles for Walter's make (not for smake).

Why not just use smake?

> Another issue is that, AFAIK, with DMC you cannot have WinMain() placed in
> a library, as with other compilers (BCC, gcc), so you'll have to link
> vstartup.obj explicitly each time, besides vgui.lib.  Pretty weird
> limitation, but oh well... :)

What is necessary is some reference that pulls it in from the library.

"Walter" <walter@digitalmars.com> wrote in news:9sg1cf$nsn$1@digitaldaemon.com:

> 
> "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:Xns9152CF66AEA8Bplaur@63.105.9.61...
>> My real app is executed in:
>> - 485 seconds (MinGW)
>> - 350 seconds (DMC 8.22)
>> - 217 seconds (BCC 5.5.1)
>> - 115 seconds (MSVC6SP5, they seem to be real good in fp!)
>>
>> As I mentioned, the bottle neck is the large number of integrations, so it's a weird loop that is optimized better or worse by different compilers. Even a few cycles gained due speculative execution side-effects (Athlon has more FPUs) really make a difference in this case.
> 
> In many cases, DMC will generate slower FPU code because it takes pains to generate correct IEEE standard compliant code. This means, for example, that all comparisons need to be double checked for NANs. The last time I checked, MSVC did not do this. Also, floating point constant folding is NOT done if the folding would raise the inexact flag.
> 
> Much of this can be disabled with the -ff switch, which would be close to an apples-apples comparison with other compilers.

Actually, this is how I compared: with fast floating point support on all compilers (I know I don't need correct denormal comparison, since, if I'm getting someting else than finite numbers and Infs in sigularities, I'm in real trouble anyway).  So the flags were "-o+all -6 -ff" for DMC, "-O2 -6 - ff" for bcc32, and similar for gcc (I also added -mieee-fp to -ffast-math, since I was testing for NaNs and denormals).

It's just a loop, and DMC generates very good code for it.  Visual C++ seems to generate excellent FPU code, and I have to admit this, even if I'm anything but a Microsoft fan.  Maybe I should mention that in my test case with MSVC, I only had normal numbers, no special cases like Inf, NaN, etc., so I don't know about MSVC's IEEE fp compliance.


Laurentiu

"Walter" <walter@digitalmars.com> wrote in news:9sh1ca$1pn2$1@digitaldaemon.com:

> "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:Xns91545E3A4A10Fplaurcrosswindsnet@63.105.9.61...
>> The problem is DMC's make does not support implicit rules that generates/(depends on) files in different directories.  So I had to write custom Perl scripts to generate makefiles for Walter's make (not for smake).
> 
> Why not just use smake?

When I started the V port for DMC, it was in the early days when "a CD will be available soon" (yes, even before you kindly sent me a DMC alpha - thanks again for this!).  Your make was the only one available for DMC.  After I bought the CD, I already had a working Perl script, so... :)

And, I must admit, I was too lazy to read SMAKE's manual (which SMAKE I understood is not available for free download, and I want to provide the V DMC port to everybody, not just CD owners).  But maybe I should take a look at SMAKE, after all!

>> Another issue is that, AFAIK, with DMC you cannot have WinMain()
>> placed in a library, as with other compilers (BCC, gcc), so you'll
>> have to link vstartup.obj explicitly each time, besides vgui.lib.
>> Pretty weird limitation, but oh well... :)
> 
> What is necessary is some reference that pulls it in from the library.

Yes, I remember our discussion about this, but I still haven't figured out a solution to generate a ref to WinMain(), without calling it.  AFAIK, I'm not supposed to call the entry function in a C++ program (the Standard refers to main(), but I guess that's also true for WinMain).  But I'm open to suggestions... :)

What's still unclear to me is why DMC's startup code doesn't trigger WinMain (), since it probably calls it (that's what happens in BCC, c0w.obj calls an external WinMain, and it's extracted from the LIB, without the need for any hack).

Laurentiu

On Fri, 9 Nov 2001 08:15:24 +0000 (UTC), Laurentiu Pancescu
<plaur@crosswinds.net> wrote:

>Chris <chris@widdows.demon.nl> wrote in news:kqvlut4l3ftd54llhmi3k9cg1n8g6ctskl@4ax.com:
>
>> Could you tell me more about the V port, I wasn't very succesfull finding info on that.
>> 
>> Chris.
>> 
>
>About V GUI (well, searching for V on the 'Net can be tough ;), you can visit www.objectcentral.com.  Shortly said, it's a LGPL'd GUI toolkit, portable across platforms.  With the same source code, you can build binaries for Win32, OS/2, GNU/Linux and other UN*X flavors (using MIT Athena, Motif or GTK in the background) and I'm not sure if Mac is on the list.  It's small, looks reasonably good, while maintaing platform-specific look-n-feel.  Crossplatform is important for me, so I'm using it.  It even has platform-independent printing support and OpenGL support!
>

Yes, I knew of Bruce's site, just when started nearing usability he dropped the  support. Hadn't been there for some time, but it is far less bulky than say WxWindows, and seems better constructed. Need to look into it more.

>About the DMC port of V, unless someone has done it independently, I don't think you'll find anything for now... I didn't publish it yet!  (web-space provider problems).  For now, I only have the main DMC Makefile working, and a few (not all) of the demos.  Unfortunately, VIDE is not on the list yet...
>

Well perhaps it could be published on the DM site (a question and suggestion rolled into 1), and more people could help finishing it. I use the IDDE quite often (I like the source code parsing, and have found that the resource editor does somethings differently when used from the IDDE (like use resource.h, instead of resource.k ??? when invoked outside the IDDE). Did you have to alter any source code?

>The problem is DMC's make does not support implicit rules that generates/(depends on) files in different directories.  So I had to write custom Perl scripts to generate makefiles for Walter's make (not for smake).
>

>Another issue is that, AFAIK, with DMC you cannot have WinMain() placed in a library, as with other compilers (BCC, gcc), so you'll have to link vstartup.obj explicitly each time, besides vgui.lib.  Pretty weird limitation, but oh well... :)
>
>
You're right, cannot find something similar to /include used in MSVC linker would do it.

>Regards,
>  Laurentiu

"Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:Xns9154E58631580plaur@63.105.9.61...
> Yes, I remember our discussion about this, but I still haven't figured out
a
> solution to generate a ref to WinMain(), without calling it.  AFAIK, I'm
not
> supposed to call the entry function in a C++ program (the Standard refers
to
> main(), but I guess that's also true for WinMain).  But I'm open to
> suggestions... :)
>
> What's still unclear to me is why DMC's startup code doesn't trigger
WinMain
> (), since it probably calls it (that's what happens in BCC, c0w.obj calls
an
> external WinMain, and it's extracted from the LIB, without the need for
any
> hack).
>
> Laurentiu

Does this help? www.digitalmars.com/ctg/acrtused.html

"Walter" <walter@digitalmars.com> wrote in news:9si877$9n$1@digitaldaemon.com:

> 
> "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:Xns9154E58631580plaur@63.105.9.61...
>> Yes, I remember our discussion about this, but I still haven't figured
>> out a solution to generate a ref to WinMain(), without calling it.
>> AFAIK, I'm not supposed to call the entry function in a C++ program
>> (the Standard refers to main(), but I guess that's also true for
>> WinMain).  But I'm open to suggestions... :)
>>
>> What's still unclear to me is why DMC's startup code doesn't trigger WinMain (), since it probably calls it (that's what happens in BCC, c0w.obj calls an external WinMain, and it's extracted from the LIB, without the need for any hack).
>>
>> Laurentiu
> 
> Does this help? www.digitalmars.com/ctg/acrtused.html

I read it - the thing that amazed me is that it seems that it's not the startup code that triggers main() or WinMain(), but it's the main() that triggers the stratup code???

Hmmm... maybe declaring a static function that calls WinMain, and never call that will do the trick?  After all, specifiying vstartup.obj at each link isn't that hard.

Thanks,
  Laurentiu

Chris <chris@widdows.demon.nl> wrote in news:uq0putkl1sdh3udc53kmc5tmp0ucn2a7b9@4ax.com:

> On Fri, 9 Nov 2001 08:15:24 +0000 (UTC), Laurentiu Pancescu
> <plaur@crosswinds.net> wrote:
> 
>>Chris <chris@widdows.demon.nl> wrote in news:kqvlut4l3ftd54llhmi3k9cg1n8g6ctskl@4ax.com:
>>
> 
> Yes, I knew of Bruce's site, just when started nearing usability he dropped the  support. Hadn't been there for some time, but it is far less bulky than say WxWindows, and seems better constructed. Need to look into it more.

Yep, hasn't been updated for more than a year.  I'd like to have some notebook-like control (tabbed control, in Win), and maybe a tree control. They exist in GTK, Win32 and Motif, so they should be there, IMHO...

The GTK port is also behind... too bad! :(

WxWindows is too big and bulky, IMHO.  Another cross platform toolkit that I like is FLTK (www.fltk.org).  I've been using it on GNU/Linux, mainly...

> Well perhaps it could be published on the DM site (a question and suggestion rolled into 1), and more people could help finishing it. I use the IDDE quite often (I like the source code parsing, and have found that the resource editor does somethings differently when used from the IDDE (like use resource.h, instead of resource.k ??? when invoked outside the IDDE). Did you have to alter any source code?

I don't remember, probably not (even if I did, there were probably minor changes, otherwise I would have remembered about doing that).  Too much work, I guess... :)

I'll finish the port, and then try to convince Walter to put some INCOMING dir on the ftp.digitalmars.com, or some contrib section on DigitalMars. Perhaps I'm not the only one wishing to contribute code... ;)

> You're right, cannot find something similar to /include used in MSVC linker would do it.

I think it's a rather minor inconvenient.  BTW, vdraw, one of the demo apps, has only 158k, statically linked with DMC port of V.  Not bad at all! :)


Laurentiu

"Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:Xns91558A4C83D8Fplaur@63.105.9.61...
> > Does this help? www.digitalmars.com/ctg/acrtused.html
> I read it - the thing that amazed me is that it seems that it's not the
> startup code that triggers main() or WinMain(), but it's the main() that
> triggers the stratup code???

Yes. I wished to avoid having to specify the startup code to the linker.

> Hmmm... maybe declaring a static function that calls WinMain, and never
call
> that will do the trick?  After all, specifiying vstartup.obj at each link isn't that hard.

That sounds like it should work.

On Sat, 10 Nov 2001 12:32:45 +0000 (UTC), Laurentiu Pancescu

<snip>
>
>WxWindows is too big and bulky, IMHO.  Another cross platform toolkit that I like is FLTK (www.fltk.org).  I've been using it on GNU/Linux, mainly...
>

I don't know fltk (except coming across it once or twice), but WxWindows was churning out multi meg apps with ease, so that turned me right off. Zinc for the desktop is free now, when I last looked at that it seemed pretty good. Anyway, I think it would be nice to a cross-platform option alongside the current Win/MFC stuff (which I want also).

>> Well perhaps it could be published on the DM site (a question and suggestion rolled into 1), and more people could help finishing it. I use the IDDE quite often (I like the source code parsing, and have found that the resource editor does somethings differently when used from the IDDE (like use resource.h, instead of resource.k ??? when invoked outside the IDDE). Did you have to alter any source code?
>
>I don't remember, probably not (even if I did, there were probably minor changes, otherwise I would have remembered about doing that).  Too much work, I guess... :)
>
>I'll finish the port, and then try to convince Walter to put some INCOMING dir on the ftp.digitalmars.com, or some contrib section on DigitalMars. Perhaps I'm not the only one wishing to contribute code... ;)
>

I'm all for it, heck I might even have time to add to the effort to ;-) I
had a go at imagemagick, but ran into all sorts of problems. The Watcom
compiler did manage to get more going, but ended up just getting a little
Win only shareware lib. Pity, imagemagick looks pretty good. Perhaps I
should have another go, and keep posting the problems. One thing that made
things a little difficult was that some libs took the __SC__ define as
meaning Mac code, which didn't help. And the OLE/template stuff went
haywire. DM++ has come quite far since then, so perhaps I should give it
another go.

>> You're right, cannot find something similar to /include used in MSVC linker would do it.
>
>I think it's a rather minor inconvenient.  BTW, vdraw, one of the demo apps, has only 158k, statically linked with DMC port of V.  Not bad at all! :)
>

No, very nice, and that would compile/run wo alteration on Linux?
>
>Laurentiu