Using Win API LockFile/UnlockFile in a 64 bit environment

Hi All.

I have a bit of an issue which is kind of hard to explain but here goes.

We a 32 bit file server that contains files that represent the tables of a simple file based database.  Our software uses this database as its backed, it performs simple locking, read/write operations using the windows API functions CreateFile, ReadFile, LockFile, etc.

The problem that we are having is that when our software is run on a 64 bit operating system and we call LockFile to lock a region of the file, if the file is then opened again within the same process the original lock is not released when the application closes, i.e. when UnlockFile is called.

The exact steps are:

Open the file for random access using CreateFile
Read some bytes from the file using ReadFile
Lock a region of the file using LockFile

Open the file again for random access within the same process using CreateFile.
Close the file using CloseHandle

Release the previous lock using UnlockFile.

At the last stage the file remains locked and the operating system does not release it even after a day has passed.

I have traced the problem down to how LockFile is being called.  Say we want to lock the byte 6127, LockFile is being called like this LockFile(Handle, 6127, 0, 1, 0), the high order parameters are being passed as 0 which I believe is correct.  

However if I call LockFile like this LockFile(Handle, 6127, 6127, 1, 1), i.e. using the same values for both the low and high order parameters then the issue goes away.

I have also noticed that opening the file using the FILE_FLAG_NO_BUFFERING flag solves the issue as well but unfortunately we cannot open the file in this way.

I would like to know if anyone else has experienced this problem before and how it might be solved.  Also is it correct to call LockFile(Handle, 6127, 0, 1, 0) or do we need to pass the high order parameters in a different way?

I really need this problem solved, any help would be most appreciated.
0
kerry
9/24/2010 10:13:33 PM
embarcadero.delphi.nativeapi 1236 articles. 1 followers. Follow

7 Replies
887 Views

Similar Articles

[PageSpeed] 27
Get it on Google Play
Get it on Apple App Store

> {quote:title=kerry convery wrote:}{quote}
> Hi All.
> 
> I have a bit of an issue which is kind of hard to explain but here goes.
> 
> We a 32 bit file server that contains files that represent the tables of a simple file based database.  Our software uses this database as its backed, it performs simple locking, read/write operations using the windows API functions CreateFile, ReadFile, LockFile, etc.
> 
> The problem that we are having is that when our software is run on a 64 bit operating system and we call LockFile to lock a region of the file, if the file is then opened again within the same process the original lock is not released when the application closes, i.e. when UnlockFile is called.
> 
> The exact steps are:
> 
> Open the file for random access using CreateFile
> Read some bytes from the file using ReadFile
> Lock a region of the file using LockFile
> 
> Open the file again for random access within the same process using CreateFile.
> Close the file using CloseHandle
> 
> Release the previous lock using UnlockFile.
> 
> At the last stage the file remains locked and the operating system does not release it even after a day has passed.
> 
> I have traced the problem down to how LockFile is being called.  Say we want to lock the byte 6127, LockFile is being called like this LockFile(Handle, 6127, 0, 1, 0), the high order parameters are being passed as 0 which I believe is correct.  
> 
> However if I call LockFile like this LockFile(Handle, 6127, 6127, 1, 1), i.e. using the same values for both the low and high order parameters then the issue goes away.
> 
> I have also noticed that opening the file using the FILE_FLAG_NO_BUFFERING flag solves the issue as well but unfortunately we cannot open the file in this way.
> 
> I would like to know if anyone else has experienced this problem before and how it might be solved.  Also is it correct to call LockFile(Handle, 6127, 0, 1, 0) or do we need to pass the high order parameters in a different way?
> 
> I really need this problem solved, any help would be most appreciated.

Simplifying to a reproducible bit of code would be good, or any code at all as it's hard to check code you can't see.

Just using the same value for hi and lo, is not going to actually help, as with your example you're locking 1 byte at offset 26315264628719 in the file (I'd be surprised if the file is really that big!)

Is your code threaded at all, the docs say the lock is granted to the calling thread, not process

On this 64bit os the following code releases the file correctly, so I'm not sure what you do differently
{code}
procedure TKpCmdLineForm4.btn1Click(Sender: TObject);
  procedure PopUpLastErrorMessage; // quickie display last sys error code message;
  var
    l: Cardinal;
  begin
    l := GetLastError;
    MessageBox(0, PChar('Err code: ' + IntToStr(l) + ' (0x' + inttohex(l,8) + ')' + #13#10 +
       SysErrorMessage(l)), 'Last Error', MB_ICONWARNING or MB_OK);
  end;

const
  fname = 'F:\DProjects2010\New Text Document.txt';
var
  file1, file2: TFileStream;
  testbyte: Byte;
begin
  PopUpLastError;
  file1 := TFileStream.Create(fname, fmOpenReadWrite or fmShareDenyNone);
  try
    if LockFile(file1.Handle, 10, 0, 1, 0) then
    begin
      file2 := TFileStream.Create(fname, fmOpenReadWrite or fmShareDenyNone);
      try
        // some code....
      finally
        file2.Free;
      end;

      if not UnlockFile(file1.Handle, 10, 0, 1, 0) then
        PopUpLastErrorMessage;
    end
    else
      PopUpLastErrorMessage;

  finally
    file1.Free;
  end;

end;

{code}


--
Any code shown is just an example, take a look, then go and read the docs
0
karl
9/24/2010 11:15:27 PM
For actually using params with hi/lo pairs it's easier to use int64rec or similar
eg
{code}
var FileLockAt,FileLockLength:Int64Rec ;
begin
  Int64(FileLockAt) := 6127; //start position of file lock, eg at position 6127
  Int64(FileLockLength) := 16; //lock 16 bytes

  file1 := TFileStream.Create(fname, fmOpenReadWrite or fmShareDenyNone);
  try
    if LockFile(file1.Handle, FileLockAt.Lo , FileLockAt.Hi , FileLockLength.Lo, FileLockLength.Hi) then
..................
{code}

or you can  define a slightly extended one
{code}
  type
    Int64RecEx = packed record
    case Integer of
      0: (I64:int64);
      1: (Lo, Hi: Cardinal);
      2: (Cardinals: array [0..1] of Cardinal);
      3: (Words: array [0..3] of Word);
      4: (Bytes: array [0..7] of Byte);
  end;

var FileLockAt,FileLockLength:Int64RecEx ;
begin
  FileLockAt.I64 := 6127; //start position of file lock, eg at position 6127
  FileLockLength.I64 := 16; //lock 16 bytes

  file1 := TFileStream.Create(fname, fmOpenReadWrite or fmShareDenyNone);
  try
    if LockFile(file1.Handle, FileLockAt.Lo , FileLockAt.Hi , FileLockLength.Lo, FileLockLength.Hi) then
..................
{code}
0
karl
9/24/2010 11:38:05 PM
> {quote:title=kerry convery wrote:}{quote}
> Hi All.
> 
> I have a bit of an issue which is kind of hard to explain but here goes.
> 
> We a 32 bit file server that contains files that represent the tables of a simple file based database.  Our software uses this database as its backed, it performs simple locking, read/write operations using the windows API functions CreateFile, ReadFile, LockFile, etc.
> 
> The problem that we are having is that when our software is run on a 64 bit operating system and we call LockFile to lock a region of the file, if the file is then opened again within the same process the original lock is not released when the application closes, i.e. when UnlockFile is called.
> 
> The exact steps are:
> 
> Open the file for random access using CreateFile
> Read some bytes from the file using ReadFile
> Lock a region of the file using LockFile
> 
> Open the file again for random access within the same process using CreateFile.
> Close the file using CloseHandle
> 
> Release the previous lock using UnlockFile.
> 
> At the last stage the file remains locked and the operating system does not release it even after a day has passed.
> 
> I have traced the problem down to how LockFile is being called.  Say we want to lock the byte 6127, LockFile is being called like this LockFile(Handle, 6127, 0, 1, 0), the high order parameters are being passed as 0 which I believe is correct.  
> 
> However if I call LockFile like this LockFile(Handle, 6127, 6127, 1, 1), i.e. using the same values for both the low and high order parameters then the issue goes away.
> 
> I have also noticed that opening the file using the FILE_FLAG_NO_BUFFERING flag solves the issue as well but unfortunately we cannot open the file in this way.
> 
> I would like to know if anyone else has experienced this problem before and how it might be solved.  Also is it correct to call LockFile(Handle, 6127, 0, 1, 0) or do we need to pass the high order parameters in a different way?
> 
> I really need this problem solved, any help would be most appreciated.

Thank you for your replies.  Yes I think my previous post wasn't very clear, I'll try to explain again how to replicate the problem.

1. Place a file that is between 7000 and 10000 bytes long in a shared folder on a 32 bit windows machine, we are using Windows Server 2003.
2. Write a basic application that does the following.  Compile for Win32 so that it runs under WOW64.  Please note that I've missed out try..finally, declarations, etc for simplicity.

FileHandle1 := CreateFile(FileName, GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, FILE_FLAG_RANDOM_ACCESS, 0);
 
FileRead(FileHandle1, Buffer^, 1, BytesRead, nil);

LockFile(FileHandle1, 6127, 0, 1, 0);

FileHandle2 := CreateFile(FileName, GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, FILE_FLAG_RANDOM_ACCESS, 0);

CloseHandle(FileHandle2);

UnlockFile(FileHandle1, 6127, 0, 1, 0);

CloseHandle(FileHandle1);

3. Run the application on a 64 bit windows machine.
 
4. Terminate your application.

5. If you now open up the computer manager on the server (control panel->computer management)  and look at the opened files in the share folder where your file resides you will see that your file is still open.

The problem goes does not occur if you either use the FILE_FLAG_NO_BUFFERING flag when opening the file the second time or if you lock the file by calling LockFile(FileHandl1, 6127, 6127, 1, 1).  However as you mentioned, that is not the correct way to call LockFile.  Note that you need to read the file before locking it otherwise the issue to does not occur.

Edited by: kerry convery on Sep 24, 2010 8:37 PM

Edited by: kerry convery on Sep 24, 2010 8:39 PM

Edited by: kerry convery on Sep 24, 2010 8:40 PM
0
kerry
9/25/2010 3:41:05 AM
Without having tried it, going after your description, I would say you are
posting on the wrong NG and need to contact microsoft instead.

kerry convery wrote:

> > {quote:title=kerry convery wrote:}{quote}
> > Hi All.
> > 
> > I have a bit of an issue which is kind of hard to explain but here goes.
> > 
> > We a 32 bit file server that contains files that represent the tables of a
> > simple file based database.  Our software uses this database as its backed,
> > it performs simple locking, read/write operations using the windows API
> > functions CreateFile, ReadFile, LockFile, etc.
> > 
> > The problem that we are having is that when our software is run on a 64 bit
> > operating system and we call LockFile to lock a region of the file, if the
> > file is then opened again within the same process the original lock is not
> > released when the application closes, i.e. when UnlockFile is called.
> > 
> > The exact steps are:
> > 
> > Open the file for random access using CreateFile
> > Read some bytes from the file using ReadFile
> > Lock a region of the file using LockFile
> > 
> > Open the file again for random access within the same process using
> > CreateFile.  Close the file using CloseHandle
> > 
> > Release the previous lock using UnlockFile.
> > 
> > At the last stage the file remains locked and the operating system does not
> > release it even after a day has passed.
> > 
> > I have traced the problem down to how LockFile is being called.  Say we
> > want to lock the byte 6127, LockFile is being called like this
> > LockFile(Handle, 6127, 0, 1, 0), the high order parameters are being passed
> > as 0 which I believe is correct.
> > 
> > However if I call LockFile like this LockFile(Handle, 6127, 6127, 1, 1),
> > i.e. using the same values for both the low and high order parameters then
> > the issue goes away.
> > 
> > I have also noticed that opening the file using the FILE_FLAG_NO_BUFFERING
> > flag solves the issue as well but unfortunately we cannot open the file in
> > this way.
> > 
> > I would like to know if anyone else has experienced this problem before and
> > how it might be solved.  Also is it correct to call LockFile(Handle, 6127,
> > 0, 1, 0) or do we need to pass the high order parameters in a different way?
> > 
> > I really need this problem solved, any help would be most appreciated.
> 
> Thank you for your replies.  Yes I think my previous post wasn't very clear,
> I'll try to explain again how to replicate the problem.
> 
> 1. Place a file that is between 7000 and 10000 bytes long in a shared folder
> on a 32 bit windows machine, we are using Windows Server 2003.  2. Write a
> basic application that does the following.  Compile for Win32 so that it runs
> under WOW64.  Please note that I've missed out try..finally, declarations,
> etc for simplicity.
> 
> FileHandle1 := CreateFile(FileName, GENERIC_READ or GENERIC_WRITE,
> FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING,
> FILE_FLAG_RANDOM_ACCESS, 0); FileRead(FileHandle1, Buffer^, 1, BytesRead,
> nil);
> 
> LockFile(FileHandle1, 6127, 0, 1, 0);
> 
> FileHandle2 := CreateFile(FileName, GENERIC_READ or GENERIC_WRITE,
> FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING,
> FILE_FLAG_RANDOM_ACCESS, 0);
> 
> CloseHandle(FileHandle2);
> 
> UnlockFile(FileHandle1, 6127, 0, 1, 0);
> 
> CloseHandle(FileHandle1);
> 
> 3. Run the application on a 64 bit windows machine.
>  
> 4. Terminate your application.
> 
> 5. If you now open up the computer manager on the server (control
> panel->computer management)  and look at the opened files in the share folder
> where your file resides you will see that your file is still open.
> 
> The problem goes does not occur if you either use the FILE_FLAG_NO_BUFFERING
> flag when opening the file the second time or if you lock the file by calling
> LockFile(FileHandl1, 6127, 6127, 1, 1).  However as you mentioned, that is
> not the correct way to call LockFile.  Note that you need to read the file
> before locking it otherwise the issue to does not occur.
> 
> Edited by: kerry convery on Sep 24, 2010 8:37 PM
> 
> Edited by: kerry convery on Sep 24, 2010 8:39 PM
> 
> Edited by: kerry convery on Sep 24, 2010 8:40 PM
0
Thorsten
9/25/2010 3:57:27 AM
> {quote:title=kerry convery wrote:}{quote}
> Hi All.
> 
> I have a bit of an issue which is kind of hard to explain but here goes.
> 
> We a 32 bit file server that contains files that represent the tables of a simple file based database.  Our software uses this database as its backed, it performs simple locking, read/write operations using the windows API functions CreateFile, ReadFile, LockFile, etc.
> 
> The problem that we are having is that when our software is run on a 64 bit operating system and we call LockFile to lock a region of the file, if the file is then opened again within the same process the original lock is not released when the application closes, i.e. when UnlockFile is called.
> 
> The exact steps are:
> 
> Open the file for random access using CreateFile
> Read some bytes from the file using ReadFile
> Lock a region of the file using LockFile
> 
> Open the file again for random access within the same process using CreateFile.
> Close the file using CloseHandle
> 
> Release the previous lock using UnlockFile.
> 
> At the last stage the file remains locked and the operating system does not release it even after a day has passed.
> 
> I have traced the problem down to how LockFile is being called.  Say we want to lock the byte 6127, LockFile is being called like this LockFile(Handle, 6127, 0, 1, 0), the high order parameters are being passed as 0 which I believe is correct.  
> 
> However if I call LockFile like this LockFile(Handle, 6127, 6127, 1, 1), i.e. using the same values for both the low and high order parameters then the issue goes away.
> 
> I have also noticed that opening the file using the FILE_FLAG_NO_BUFFERING flag solves the issue as well but unfortunately we cannot open the file in this way.
> 
> I would like to know if anyone else has experienced this problem before and how it might be solved.  Also is it correct to call LockFile(Handle, 6127, 0, 1, 0) or do we need to pass the high order parameters in a different way?
> 
> I really need this problem solved, any help would be most appreciated.

I would appreciate it if someone would try to replicate it so that I know its not just happening on my machines.
0
kerry
9/25/2010 10:16:45 AM
> {quote:title=kerry convery wrote:}{quote}
> I would appreciate it if someone would try to replicate it so that I know its not just happening on my machines.

Ok, rewriting it like this still works fine for me, from a network share and local, on both win7 and server2003 (both x64)


If you've got anything that produces an error, it's much better to copy and paste the exact compilable code
1) You're making it easier for more people to give it a try, instead of thinking 'why should I bother'
2) There's not a lot of point in people writing and checking their own code?
3) It's really easy to read your own code and see 'what I meant to type' instead of what's actually there - happens all the time

{code}
procedure TKpCmdLineForm4.btn1Click(Sender: TObject);
  procedure PopUpLastErrorMessage(m: string = ''); // quickie display last sys error code message;
  var
    l: Cardinal;
  begin
    l := GetLastError;
    if m <> '' then
      m := m + #13#10;
    MessageBox(0, PChar(m + 'Err code: ' + IntToStr(l) + ' (0x' + inttohex(l,
          8) + ')' + #13#10 + SysErrorMessage(l)), 'Last Error', MB_ICONWARNING or MB_OK);
  end;

var
  fname: string;
  file1, file2: TFileStream;
  testbyte: Byte;
  FileLockAt, FileLockLength: Int64Rec;
  FileLockAt2, FileLockLength2: Int64Rec;
  FileHandle1, FileHandle2: THandle;
  buffer: array [0 .. 32767] of Byte;
  bytesread: Integer;
begin

  bytesread := 1;
  fname := ExtractFilePath(Application.ExeName) + 'New Text Document.txt';

  int64(FileLockAt) := 6127; // start position of file lock, eg at position 6127
  int64(FileLockLength) := 16; // lock 16 bytes
  int64(FileLockAt2) := 4127; // start position of file lock, eg at position 6127
  int64(FileLockLength2) := 16; // lock 16 bytes

  FileHandle1 := CreateFile(PChar(fname), GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE,
    nil, OPEN_EXISTING, FILE_FLAG_RANDOM_ACCESS, 0);
  if FileHandle1 <> INVALID_HANDLE_VALUE then
    try
      FileRead(FileHandle1, buffer, bytesread);
      if LockFile(FileHandle1, FileLockAt.Lo, FileLockAt.Hi, FileLockLength.Lo, FileLockLength.Hi) then
      begin
        FileHandle2 := CreateFile(PChar(fname), GENERIC_READ or GENERIC_WRITE,
          FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, FILE_FLAG_RANDOM_ACCESS, 0);
        if FileHandle1 <> INVALID_HANDLE_VALUE then
          try
            if LockFile(FileHandle2, FileLockAt2.Lo, FileLockAt2.Hi, FileLockLength2.Lo, FileLockLength2.Hi)
              then
            begin
              FileRead(FileHandle2, buffer, bytesread);
              if not UnlockFile(FileHandle2, FileLockAt2.Lo, FileLockAt2.Hi, FileLockLength2.Lo,
                FileLockLength2.Hi) then
                PopUpLastErrorMessage('f2');
            end
            else
              PopUpLastErrorMessage('f2');
          finally
            CloseHandle(FileHandle2);
          end
        else
          PopUpLastErrorMessage('openerror f2');

        if not UnlockFile(FileHandle1, FileLockAt.Lo, FileLockAt.Hi, FileLockLength.Lo, FileLockLength.Hi)
          then
          PopUpLastErrorMessage('f1');
      end
      else
        PopUpLastErrorMessage('f1');

    finally
      CloseHandle(FileHandle1);
    end
  else
    PopUpLastErrorMessage('openerror f1');

  memo1.Lines.Add('done');
end;
{code}



--
Any code shown is just an example, take a look, then go and read the docs
0
karl
9/25/2010 5:25:16 PM
> {quote:title=kerry convery wrote:}{quote}
> Hi All.
> 
> I have a bit of an issue which is kind of hard to explain but here goes.
> 
> We a 32 bit file server that contains files that represent the tables of a simple file based database.  Our software uses this database as its backed, it performs simple locking, read/write operations using the windows API functions CreateFile, ReadFile, LockFile, etc.
> 
> The problem that we are having is that when our software is run on a 64 bit operating system and we call LockFile to lock a region of the file, if the file is then opened again within the same process the original lock is not released when the application closes, i.e. when UnlockFile is called.
> 
> The exact steps are:
> 
> Open the file for random access using CreateFile
> Read some bytes from the file using ReadFile
> Lock a region of the file using LockFile
> 
> Open the file again for random access within the same process using CreateFile.
> Close the file using CloseHandle
> 
> Release the previous lock using UnlockFile.
> 
> At the last stage the file remains locked and the operating system does not release it even after a day has passed.
> 
> I have traced the problem down to how LockFile is being called.  Say we want to lock the byte 6127, LockFile is being called like this LockFile(Handle, 6127, 0, 1, 0), the high order parameters are being passed as 0 which I believe is correct.  
> 
> However if I call LockFile like this LockFile(Handle, 6127, 6127, 1, 1), i.e. using the same values for both the low and high order parameters then the issue goes away.
> 
> I have also noticed that opening the file using the FILE_FLAG_NO_BUFFERING flag solves the issue as well but unfortunately we cannot open the file in this way.
> 
> I would like to know if anyone else has experienced this problem before and how it might be solved.  Also is it correct to call LockFile(Handle, 6127, 0, 1, 0) or do we need to pass the high order parameters in a different way?
> 
> I really need this problem solved, any help would be most appreciated.

Ok, I'll leave it at that for now as its clear that I need to investigate further.  

Thank you for your help.
0
kerry
9/26/2010 9:45:43 AM
Reply:

Similar Artilces:

Probable Stupid Question: Using 64-bit Code on 64-bit Processors running 32-bit Windows...
Hi, Does anyone know if it is possible to do 64-bit processing (probably by writing some assembly language code) when running on a 64-bit CPU under 32-bit Windows? As near as I can tell, one has to develop all 64-bit code on a 64-bit machine running 64-bit windows and the target machines for 64-bit code have to be 64-bit machines running 64-bit windows. What might be useful, if it is possible, would be being able to detect a 64-bit processor when running 32-bit windows and take advantage of that to speed up some calculations. DanH ...

Probable Stupid Question: Using 64-bit Code on 64-bit Processors running 32-bit Windows... #2
Hi, Does anyone know if it is possible to do 64-bit processing (probably by writing some assembly language code) when running on a 64-bit CPU under 32-bit Windows? As near as I can tell, one has to develop all 64-bit code on a 64-bit machine running 64-bit windows and the target machines for 64-bit code have to be 64-bit machines running 64-bit windows. What might be useful, if it is possible, would be being able to detect a 64-bit processor when running 32-bit windows and take advantage of that to speed up some calculations. DanH Dan Hale wrote: > Does anyone k...

Trial as using Win 7 64 bit
Name: delboy01@sapo.pt Email: delboy01atsapodotpt Product: Firefox Summary: Trial as using Win 7 64 bit Comments: Trial as using Win 7 64 bit Browser Details: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre From URL: http://hendrix.mozilla.org/ Note to readers: Hendrix gives no expectation of a response to this feedback but if you wish to provide one you must BCC (not CC) the sender for them to see it. ...

What calling convention does 64-bit Delphi use?
Just came across this webpage: http://msdn.microsoft.com/en-us/library/ms235286(v=vs.100).aspx *Given the expanded register set, x64 just uses the __fastcall calling convention and a RISC-based exception-handling model.* Does this mean 64-bit Windows DLLs now export functions using __fastcall instead of stdcall for Win32? > Does this mean 64-bit Windows DLLs now export functions using __fastcall instead of stdcall for Win32? There's only one calling convention under Win64. With both MSVC and Delphi 64bit compliers, calling convention specifiers are just ignored. Simon ...

Minefield crashes on startup after todays update (64-bit, win 7 64-bit)
Name: Product: Minefield Summary: Minefield crashes on startup after todays update (64-bit, win 7 64-bit) Comments: Problem signature: Problem Event Name: APPCRASH Application Name: firefox.exe Application Version: 2.0.0.3930 Application Timestamp: 4caaf485 Fault Module Name: mozjs.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4caae92b Exception Code: c0000005 Exception Offset: 00000000001ab60e OS Version: 6.1.7600.2.0.0.256.1 Locale ID: 1053 Additional Information 1: ae61 Additional Information 2: ae61702521dd6121f7be0fc073032d6c ...

superreview requested: [Bug 303508] Add freebl shared libs that do only 64-bit integer math : [Attachment 197136] Replace IS_64 with new symbol that says "use 64 bit registers in 32-bit build"
Saul Edwards <saul.edwards.bugs@sun.com> has asked Wan-Teh Chang <wtchang@redhat.com> for superreview: Bug 303508: Add freebl shared libs that do only 64-bit integer math https://bugzilla.mozilla.org/show_bug.cgi?id=303508 Attachment 197136: Replace IS_64 with new symbol that says "use 64 bit registers in 32-bit build" https://bugzilla.mozilla.org/attachment.cgi?id=197136&action=edit ------- Additional Comments from Saul Edwards <saul.edwards.bugs@sun.com> I tested the performance of this patch on ultrasparc 3 (v440) and a target architecture for th...

superreview denied: [Bug 303508] Add freebl shared libs that do only 64-bit integer math : [Attachment 197136] Replace IS_64 with new symbol that says "use 64 bit registers in 32-bit build"
Wan-Teh Chang <wtchang@redhat.com> has denied Saul Edwards <saul.edwards.bugs@sun.com>'s request for superreview: Bug 303508: Add freebl shared libs that do only 64-bit integer math https://bugzilla.mozilla.org/show_bug.cgi?id=303508 Attachment 197136: Replace IS_64 with new symbol that says "use 64 bit registers in 32-bit build" https://bugzilla.mozilla.org/attachment.cgi?id=197136&action=edit ------- Additional Comments from Wan-Teh Chang <wtchang@redhat.com> Saul, Nelson: I'm sorry that my review comments are verbose. But I must point ...

superreview granted: [Bug 303508] Add freebl shared libs that do only 64-bit integer math : [Attachment 197136] Replace IS_64 with new symbol that says "use 64 bit registers in 32-bit build"
Wan-Teh Chang <wtchang@redhat.com> has granted Wan-Teh Chang <wtchang@redhat.com>'s request for superreview: Bug 303508: Add freebl shared libs that do only 64-bit integer math https://bugzilla.mozilla.org/show_bug.cgi?id=303508 Attachment 197136: Replace IS_64 with new symbol that says "use 64 bit registers in 32-bit build" https://bugzilla.mozilla.org/attachment.cgi?id=197136&action=edit ------- Additional Comments from Wan-Teh Chang <wtchang@redhat.com> You can check in this patch. The problems I pointed out can be remedied as follows: 1....

TDateTime with Delphi XE and Win 7 64-bit
Following on from thread 29082 (ShortDateFormat problem with Windows 7 64-bit & Delphi 2007) it gets even stranger. I am also running Delphi on Win 7 64, but XE rather than 2007. I followed a variation of the discussion in that thread to get the correct short date order for the UK, which is *dd/mm/yyyy*. I then obtained a Y,M,D triplet (1943,2,19) which I passed to EncodeDate. The string returned in the debugger was 2/19/1943, and the TDateTime value passed back to my application had day and month reversed. If I then passed this back to the date routines it was treated as an invalid...

Printer lockout using Win Vista (64-bit)
Name: William Fitzgerald Email: wgf4athotmaildotcom Product: Firefox Summary: Printer lockout using Win Vista (64-bit) Comments: When I try to make adjustments in my printer (HP C7280) window, I get locked out of the "preference tab" and cannot adjust settings. I am using the E-mail program supplied by my internet provider. The printer adjustments work perfectly if I use Microsoft's IE (ver 7, 64-bit). Perhaps a 64-bit version of Firefox should be pursued as there appears to be some problems running this 32-bit program on a 64-bit system. Some 32-bit pro...

Delphi Prism installed on Win 7 64 bit?
Is there, or should there be, any reason why Delphi Prisom 2010 would not install on Windows 7 64-bit? I found that it did not, but I think the problem was with the VS 2008 portion of the installation. Thanks, Bill Le 11.06.2010 22:42, William Meyer a écrit : > Is there, or should there be, any reason why Delphi Prisom 2010 would > not install on Windows 7 64-bit? I found that it did not, but I think > the problem was with the VS 2008 portion of the installation. > > Thanks, > > Bill Bill, In my Windows 7 64-bits, I have installed VS2008 with Delp...

64 bit cpu // 64 bit Os version // 64 bit powerbuilder?
Hi guys, Does anyone know if Powebuilder is available in 64 bit? Kind regards A 64-bit version of PB does not (yet) exist. -- HTH Arnoud Url: http://www.gloriant.be Also check out my PB Reference site : http://www.pbinfo.be "Gunther Huygens" <ghuygens@be.xrt.com> wrote in message news:eoSjDRaCDHA.331@forums-1-dub... > Hi guys, > > Does anyone know if Powebuilder is available in 64 bit? > > Kind regards > > > > Since there are no OS Windows 64 bits, i wonder how it could be possible. Since there is a 64 bi...

Using MBAM with a regular Win 7 64 bit account
I've had the pro version of MBAM for a while and just decided to switch on the realtime options. My admin account shows an MBAM icon in the notiifcation area but not in my regular account. I launched MBAM in my regular account and it showed realtime protection as off. When I tried checking the box to switch it on I got this message: --------------------------- Malwarebytes Anti-Malware --------------------------- An error has occurred. Please report this issue to our support team (include the content of all error message(s) and code(s) in your submission). PROGRAM_ERR...

Using C++ Code in Delphi XE4 64-bit [Edit]
I am interested in using C++ code in a Delphi XE4 Pro 64-bit app (no iOS, I did not want to pay the "nominal fee", at least not yet). I don't want to use a DLL, I want to link the C++ right into the 64-bit EXE. It is not easy finding info on this online, there's some stuff but not enough to answer all my questions. 1) Do I need to use C++ Builder 64-bit to create object files that can be linked via $LINK in Delphi XE4 64-bit? Or can I create them using Visual Studio? 2) Do I need to "flatten out" C++ classes in order to share them with Delphi or to share them ...

Web resources about - Using Win API LockFile/UnlockFile in a 64 bit environment - embarcadero.delphi.nativeapi

Environment - Wikipedia, the free encyclopedia
Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply. By using this site, you agree to the ...

Hopes fade of tougher air pollution standards at meeting of environment ministers
Standards for air pollution particles linked to lung cancer and restricted lung growth could be set at levels beyond those recommended by the ...

Ian Robert Turnbull pleads not guilty to murdering environment officer
The farmer accused of killing environmental&nbsp;officer Glen Turner has pleaded not guilty to murder.&nbsp;


Canada's environment minister worried about rights of indigenous peoples
The Daily Courier (subscription) Canada's environment minister worried about rights of indigenous peoples The Daily Courier (subscription) ...

The challenges of endpoint management in a hybrid environment
As the IT world is changing it's not uncommon for companies to be using a mix of cloud and on-premise solutions. These hybrid environments offer ...

Riverbed Survey: App Performance a Challenge in Hybrid IT Environments
Cloud computing brings its share of benefits and complexities, driving the need for greater visibility into app performance for executives and ...

Paris, The Environment, And Economic Growth
Ted Loch-Temzelides The Paris climate summit has attracted a fair amount of anticipation, and has captured the public’s imagination in many ways. ...

“We’re living in an age when humans have modified just about all aspects of our environment, deliber
“We’re living in an age when humans have modified just about all aspects of our environment, deliberately or accidentally,” said developmental ...

Zillow, Expedia co-founder Rich Barton on the importance of a healthy work environment
Find a big pond to go fishing in and find really talented people to fish with. That was one piece of advice from Rich Barton, the co-founder ...

Resources last updated: 12/15/2015 1:35:54 AM