FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

SWT 3.0 Released
Goto page Previous  1, 2
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Forum Index -> DWT
View previous topic :: View next topic  
Author Message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Thu Aug 12, 2004 5:07 pm    Post subject: Reply with quote

Ok, I've updated svn. Hopefully I haven't messed anything up. There were a number of files that were missing from the previous build, so those got included with the update (particularly the dwt\events directory and contents). I didn't touch the Sconstruct files so I don't know if they still work properly for building the project. The new win32.mak file should work properly now.

- An err.txt is included revealing some of the current undefined symbol errors created when trying to link with dwt.lib.

- dwt.lib is the default make for the project makefile..

- A new zip file is now included that contains the recent changes. Since it was archived from my eclipse folder, it contains a few eclipse project directory decorations (sorry).

Hope this helps.
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Fri Aug 13, 2004 12:32 am    Post subject: Reply with quote

andy wrote:
MoveMemory is just memcpy(). Its overloads can trivially be re-implemented directly in the OS class:

Code:
static int MoveMemory(byte[] src, LOGFONT dest) { // or whatever the argument list happens to be
   assert(src.length == LOGFONT.sizeof);
   (cast(byte*)&dest)[0 .. LOGFONT.sizeof] = src[]; // just a copy
}


No extern (Windows), no link issues. Wink


Looking at the code again, I see that this is how a number of the MoveMemory's are already implemented. There will be several others that will have to be implemented equivalently. While it doesn't appear to be a big deal, I find it a little confusing why the arguments are so different for each movememory. Some are structs, some integers, some pointer's to structs. Destination is sometimes an integer while the source is a struct. It doesn't appear to make sense. I can't imagine why it was done this way. You would think there would be a simpler, straight forward way to do all that. Of course, there's a lot in SWT that I find confusing.

Anyway... the updated svn contains incomplete code. It currently compiles as is, but we will need to comment out all the MoveMemory's in internal\win32\func.d except the windows one, then start implementing them one by one in OS.d. The SVN update already has some of the new static MoveMemory's declared in OS.d; but as of now they are incorrectly implemented. Simple enough to remove and replace what's there, though.

Later,

John
Back to top
View user's profile Send private message
Blandger



Joined: 21 May 2004
Posts: 50
Location: Ukraine, Kharkov

PostPosted: Fri Aug 13, 2004 2:16 am    Post subject: Reply with quote

Thanks for the good job, John. I'm going to work with them on this weekends.
_________________
Regards, Yuriy
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Fri Aug 13, 2004 9:31 am    Post subject: Reply with quote

MoveMemory is an artifact from Java.

Java has no concept of pointers, so it needs some way to do a mass block-copy from an array of bytes/ints/etc into and out of all those not-really-struct classes that it uses to interact with the Win32 API.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Fri Aug 13, 2004 2:40 pm    Post subject: Reply with quote

Thanks Andy,

I now see what's going on. I went back to the SWT source and found that the various MoveMemory's are implemented in C in the OS.c file where pointers are legal. Each of these makes a call to the win32 MoveMemory function. D can certainly simplify the level of convolution that Java makes, as you have shown.

Later,

John
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Forum Index -> DWT All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group