View previous topic :: View next topic |
Author |
Message |
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Thu Aug 12, 2004 5:07 pm Post subject: |
|
|
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 |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Aug 13, 2004 12:32 am Post subject: |
|
|
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. |
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 |
|
|
Blandger
Joined: 21 May 2004 Posts: 50 Location: Ukraine, Kharkov
|
Posted: Fri Aug 13, 2004 2:16 am Post subject: |
|
|
Thanks for the good job, John. I'm going to work with them on this weekends. _________________ Regards, Yuriy |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Fri Aug 13, 2004 9:31 am Post subject: |
|
|
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 |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Aug 13, 2004 2:40 pm Post subject: |
|
|
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 |
|
|
|
|
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
|