Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Steven Woodford

Greenhorn
+ Follow
since Nov 11, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Steven Woodford

Thanks for your help & suggestions, I have now found a work around for this problem.
In case anyone is interested, you can disable the ddraw.dll by adding the startup parameter "-Dsun.java2d.noddraw=true" to your command line.
I have my application running on around 170 PCs running on a mixture of Windows NT and 2000. I had started to receive this error at three sites (2 NT and 1 2k) and this has solved the problem at all three.
I hope this can be of some help to someone else.
Steven
17 years ago
Hello everyone,
When starting my application that has a very simple GUI, I periodically receive the error message Initialization of the dynamic link library C:\Winnt\System32\Ddraw.dll failed. The process is terminating abnormally.
Pasted from the Microsoft Support site:
SYMPTOMS
Ddraw needs access to a certain virtual memory address to use as a global heap space. If this address is already occupied , Ddraw.dll does not load and the following error message occurs:
Initialization of the dynamic link library C:\Winnt\System32\Ddraw.dll failed. The process is terminating abnormally.
CAUSE
When Ddraw.dll is loaded, a file-mapped memory block is allocated. This block is required to be at the same virtual address for all processes so that it can be shared cross-process. Ddraw.dll owns management of video adapter video memory and needs it to be the same for all processes that attach to this dynamic-link library (DLL). The block is of size 0x100008 and starts at 0x43000000 in Microsoft Windows NT 4.0. If this block is occupied, the DLL initialization does not succeed.
WORKAROUND
Developers should avoid using that address range. A workaround for existing programs using Ddraw is to load Ddraw first and let it use that address so that conflicting dynamic-link libraries (DLLs) can dynamically relocate.
STATUS
This behavior is by design.

I was just wondering if anyone else has had the same problem and if there are any nice workarounds you know of. I have tried reducing the amount of memory available to the jvm at startup, as was reccommended on the java.sun.com forum, but this had no effect.
Thanks in advance
Steven
17 years ago
Thanks everyone for your suggestions,
In the end, I have had to rename the offending folder, create a new one and copy the original files into the new folder. My program now has full access to the files in the folder.
It looks like this was more of a file system issue than a java issue but I would still be interested to know why this folder suddenly started behaving strangely (I still had full read/write rights to all file from within windows explorer).
Ste
17 years ago
pram face is another good one. this is a female who is quite attractive but has that look like she should (or will soon be) pushing a pram around a council estate - similar to a bobfoc
17 years ago
Siu,
Thanks for the tip, that looks like a very useful piece of code to make a note of. Don't think it will help me out with this problem though... thanks anyway
Ste
17 years ago
I'm another. Come on... there must be more than two!
Here's a good insult for you...
If you were to be of the opinion that a certain individual was a rather unattractive specimen, you might refer to them as having a "face like a bulldog chewing a wasp"
i've got more, just can't remember too many postable ones...
17 years ago

Originally posted by Michael Morris:
[b]What OS are you using?


The PC is a Windows NT 4.0 workstation. I am now double-checking user permissions etc.
17 years ago
Thanks Michael, that's what I thought.
I am getting this result when checking a file that I know exists and that I know is not read-only. I will have to look elsewhere for the problem!
17 years ago
Hi all, not sure if this is the right place to post but it seems like a simple enough question!
Apart from the file being read-only - what reasons are there for the canWrite() method of the File class to return false?
Thanks in advance
Ste
17 years ago
Sorry, not explained fully again. The extra hour seems to be added on by the date formatter (the value of timeOut is correct)
17 years ago
Thanks for your suggestions, but I don't think I have explained my problem very well.
I am using a timer object to schedule events. The timer has a user-defined interval anywhere between 1 minute and a couple of hours. I want to display the time until the next timer event triggers.
The way I am calculating the time out, which seems to be correct, is as follows (all values are in long):
timeOut = timerInterval - (currentTime - timeOfLastEvent)
The value of timeOut is what i am putting into a date formatter to display the time out, but when I have the "adjust clock for daylight saving changes" option ticked I get an extra hour added onto the time out I have calculated.
Thanks again.
17 years ago
I am having a problem displaying small time periods using the Date class. I'm quite new to Java (and this forum) so i'm hoping there is an easy way around this that i just haven't learned yet.
Here goes:
This code has been tested on Windows NT 2K and XP with the same results.
I am trying to display a time period stored in milliseconds as a long using code similar to this.
long timePeriod = 300000L;
System.out.println(new Date(timePeriod));
I would expect this to display...
Thu Jan 01 00:05:00 GMT 1970 (i am ignoring the date, its just the time i'm looking for)
... but instead it displays
Thu Jan 01 01:05:00 GMT 1970
I have found that if i un-tick the "Automatically adjust clock for daylight saving changes" option in time zone settings, the problem goes away - however i need to have this option on.
I would be grateful of any light you could shed on this as it has got me feeling quite
Thanks in advance,
Ste
17 years ago