www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Win32 API Tango / using what ?

reply BLS <nanali nospam-wanadoo.fr> writes:
Confused ... Tango is not in sync. with  the latest efforts of the 
WINAPI community. no kernel, mm, bla bla, gdi+, and so on

Why
Nov 13 2007
parent reply Sean Kelly <sean f4.ca> writes:
BLS wrote:

 Confused ... Tango is not in sync. with  the latest efforts of the 
 WINAPI community. no kernel, mm, bla bla, gdi+, and so on


We originally tried to use the headers provided in the bindings project 
on dsource, but ran into too many problems.  They contained a ton of 
errors (at the time--they may have since improved), and in some cases 
contained duplicate declarations (winsock vs. winsock2) that were too 
troublesome to sort out.  As a result, we ended up using a set of 
headers someone else supplied to us instead.  They've done the trick so 
far, but I won't go so far as to claim that they're perfect or complete.

I have my hands full just dealing with the Posix headers.  If you or 
someone else wishes to volunteer to sort out the Win32 headers for 
Tango, that would be great.


Sean
Nov 13 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Sean Kelly wrote:


 BLS wrote:

 Confused ... Tango is not in sync. with  the latest efforts of the
 WINAPI community. no kernel, mm, bla bla, gdi+, and so on


 
 We originally tried to use the headers provided in the bindings project
 on dsource, but ran into too many problems.  They contained a ton of
 errors (at the time--they may have since improved), and in some cases
 contained duplicate declarations (winsock vs. winsock2) that were too
 troublesome to sort out.  As a result, we ended up using a set of
 headers someone else supplied to us instead.  They've done the trick so
 far, but I won't go so far as to claim that they're perfect or complete.
 
 I have my hands full just dealing with the Posix headers.  If you or
 someone else wishes to volunteer to sort out the Win32 headers for
 Tango, that would be great.
 
 
 Sean


Also note that there are/used to be codegen issues and compile speed issues.
Since all the Win32 headers are linked together like spaghetti, you risk
having to compile all every time (and they are big, so it gets slow).
The above also means that the binary size increase a lot, as every module
compiled into a D program, adds about 500 bytes.
The direct port meant using static const variables a lot, and these was put
into the executable, increasing binary size by a large quantity of bytes.
Using enums instead would fix this, but seemed like an onerous task at the
time.

As Sean said, and which may apply to these points too, things may have
changed and there may not be any issues left. We'd like to be careful with
just importing such a large body of code again, though.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Nov 13 2007
parent reply Sascha Katzner <sorry.no spam.invalid> writes:
Lars Ivar Igesund wrote:

 Also note that there are/used to be codegen issues and compile speed issues.
 Since all the Win32 headers are linked together like spaghetti, you risk
 having to compile all every time (and they are big, so it gets slow).


If you use the provided makefile it creates a lib with all headers. You 
can simply link this file in your projects without the need to recompile 
it every time.


 The above also means that the binary size increase a lot, as every module
 compiled into a D program, adds about 500 bytes.
 The direct port meant using static const variables a lot, and these was put
 into the executable, increasing binary size by a large quantity of bytes.
 Using enums instead would fix this, but seemed like an onerous task at the
 time.


I don't know if static const have this effect but we use enums anyway 
everywhere it is reasonable: 
http://www.dsource.org/projects/bindings/wiki/WindowsApi/Instructions

...and my observation is that the linker only includes what he needs 
from the lib file. So you can simply include all headers (via simple 
"import win32.windows;") without it adding even a byte to your executable.

LLAP,
Sascha Katzner
Nov 14 2007
next sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Sascha Katzner schrieb:

 Lars Ivar Igesund wrote:

 Also note that there are/used to be codegen issues and compile speed 
 issues.
 Since all the Win32 headers are linked together like spaghetti, you risk
 having to compile all every time (and they are big, so it gets slow).


 
 If you use the provided makefile it creates a lib with all headers. You 
 can simply link this file in your projects without the need to recompile 
 it every time.
 



Seems that GNU Make is needed. Can you confirm ?

I am a Tango fan. So I want to build my Windows GUI in conjunction with 
Tango but I WONDER how to manage it to use (to a certain degree) the 
binding project win sources and the  Tango windows. stuff.
Well I think the Tango forum is a better place to ask.

Thanks Bjoern





 The above also means that the binary size increase a lot, as every module
 compiled into a D program, adds about 500 bytes.
 The direct port meant using static const variables a lot, and these 
 was put
 into the executable, increasing binary size by a large quantity of bytes.
 Using enums instead would fix this, but seemed like an onerous task at 
 the
 time.


 
 I don't know if static const have this effect but we use enums anyway 
 everywhere it is reasonable: 
 http://www.dsource.org/projects/bindings/wiki/WindowsApi/Instructions
 
 ...and my observation is that the linker only includes what he needs 
 from the lib file. So you can simply include all headers (via simple 
 "import win32.windows;") without it adding even a byte to your executable.
 
 LLAP,
 Sascha Katzner
Nov 14 2007
next sibling parent Sascha Katzner <sorry.no spam.invalid> writes:
BLS wrote:

 Seems that GNU Make is needed. Can you confirm ?


Yes, GNU make is needed. The make from digital mars is to primitive.


 I am a Tango fan. So I want to build my Windows GUI in conjunction
 with Tango but I WONDER how to manage it to use (to a certain degree)
 the binding project win sources and the  Tango windows. stuff. Well I
 think the Tango forum is a better place to ask.


I don't use Tango, because I really don't like the whole idea of a
second standard library, so I can't help you there. ;-) But I see no
reason why it shouldn't be possible to use both in conjunction.

LLAP,
Sascha Katzner
Nov 14 2007
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
BLS wrote:

 Sascha Katzner schrieb:

 Lars Ivar Igesund wrote:

 Also note that there are/used to be codegen issues and compile speed 
 issues.
 Since all the Win32 headers are linked together like spaghetti, you risk
 having to compile all every time (and they are big, so it gets slow).


 If you use the provided makefile it creates a lib with all headers. 
 You can simply link this file in your projects without the need to 
 recompile it every time.


 
 
 Seems that GNU Make is needed. Can you confirm ?
 
 I am a Tango fan. So I want to build my Windows GUI in conjunction with 
 Tango but I WONDER how to manage it to use (to a certain degree) the 
 binding project win sources and the  Tango windows. stuff.
 Well I think the Tango forum is a better place to ask.
 
 Thanks Bjoern
 


The easiest thing to do is use dsss. My primitive conf file is just this 
atm:

name=win32
[win32]
buildflags=-inline -O -release -version=WindowsXP -version=Unicode

I've used the win32 bindings with Tango and it works fine. There are 
only a couple of imports of the c library that needs to be changed. I 
also deleted winsock.d and testall.d, iirc that was it.
Nov 14 2007
parent BLS <nanali nospam-wanadoo.fr> writes:
Lutger schrieb:

 BLS wrote:

 Sascha Katzner schrieb:

 Lars Ivar Igesund wrote:

 Also note that there are/used to be codegen issues and compile speed 
 issues.
 Since all the Win32 headers are linked together like spaghetti, you 
 risk
 having to compile all every time (and they are big, so it gets slow).


 If you use the provided makefile it creates a lib with all headers. 
 You can simply link this file in your projects without the need to 
 recompile it every time.



 Seems that GNU Make is needed. Can you confirm ?

 I am a Tango fan. So I want to build my Windows GUI in conjunction 
 with Tango but I WONDER how to manage it to use (to a certain degree) 
 the binding project win sources and the  Tango windows. stuff.
 Well I think the Tango forum is a better place to ask.

 Thanks Bjoern


 
 The easiest thing to do is use dsss. My primitive conf file is just this 
 atm:
 
 name=win32
 [win32]
 buildflags=-inline -O -release -version=WindowsXP -version=Unicode
 
 I've used the win32 bindings with Tango and it works fine. There are 
 only a couple of imports of the c library that needs to be changed. I 
 also deleted winsock.d and testall.d, iirc that was it.


Thanks Lutger, a worthfull information.
Nov 14 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
BLS wrote:

 Sascha Katzner schrieb:

 Lars Ivar Igesund wrote:

 Also note that there are/used to be codegen issues and compile speed 
 issues.
 Since all the Win32 headers are linked together like spaghetti, you risk
 having to compile all every time (and they are big, so it gets slow).


 If you use the provided makefile it creates a lib with all headers. 
 You can simply link this file in your projects without the need to 
 recompile it every time.


 
 
 Seems that GNU Make is needed. Can you confirm ?
 
 I am a Tango fan. So I want to build my Windows GUI in conjunction with 
 Tango but I WONDER how to manage it to use (to a certain degree) the 
 binding project win sources and the  Tango windows. stuff.


If you have a library with more Win32 stuff in it than Tango offers, you 
can rename it to tango-win32-dmd.lib and replace the one shipped with 
Tango.  It will be linked automatically.


Sean
Nov 14 2007
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Sascha Katzner" <sorry.no spam.invalid> wrote in message 
news:fhec86$9pi$1 digitalmars.com...
<snip>

 The above also means that the binary size increase a lot, as every module
 compiled into a D program, adds about 500 bytes.
 The direct port meant using static const variables a lot, and these was 
 put
 into the executable, increasing binary size by a large quantity of bytes.
 Using enums instead would fix this, but seemed like an onerous task at 
 the
 time.


 I don't know if static const have this effect but we use enums anyway 
 everywhere it is reasonable: 
 http://www.dsource.org/projects/bindings/wiki/WindowsApi/Instructions


<snip>

I'm a little confused by this.

----------
const int qwert = 42;

enum {
    yuiop = 69
}
----------
Under DMD 1.023, the .obj file sizes are:
- for an empty D file, 349
- with just the const int, 396
- with just the enum, 605
- the whole thing, 652

so they are generating some object code either way.  Strange - I'd always 
been under the impression they didn't, but were expanded at compile-time and 
then discarded.  D certainly ought to support purely compile-time symbolic 
constants.  In 2.007, the whole testcase generates a 666-byte object file.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Nov 15 2007
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Stewart Gordon wrote:

 
 I'm a little confused by this.
 
 ----------
 const int qwert = 42;
 
 enum {
    yuiop = 69
 }
 ----------
 Under DMD 1.023, the .obj file sizes are:
 - for an empty D file, 349
 - with just the const int, 396
 - with just the enum, 605
 - the whole thing, 652
 
 so they are generating some object code either way.  Strange - I'd 
 always been under the impression they didn't, but were expanded at 
 compile-time and then discarded.  D certainly ought to support purely 
 compile-time symbolic constants.  In 2.007, the whole testcase generates 
 a 666-byte object file.
 
 Stewart.
 


Enums generate typeinfo, which is probably what you're seeing.
Nov 15 2007
parent reply Sean Kelly <sean f4.ca> writes:
Tomas Lindquist Olsen wrote:

 
 Enums generate typeinfo, which is probably what you're seeing.


Even unnamed enums?


Sean
Nov 15 2007
parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Sean Kelly wrote:

 Tomas Lindquist Olsen wrote:

 Enums generate typeinfo, which is probably what you're seeing.


 
 Even unnamed enums?
 
 
 Sean


Hmm. good point. it's definitely outputting static data for the .init 
property, but actually I think you're right it should not output a 
distinct instance of TypeInfo_Enum.

Looking at the object files from gdc, it seems like it is putting the 
symbols for typeid(int) and the TypeInfo_Enum baseclass in the object 
file though.

Maybe this is actually a harmless a bug.
Nov 15 2007