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

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