Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

nvdaHelper: VBufRemote_nodeHandle_t should be 64 bit #1986

Closed
nvaccessAuto opened this issue Dec 7, 2011 · 4 comments
Closed

nvdaHelper: VBufRemote_nodeHandle_t should be 64 bit #1986

nvaccessAuto opened this issue Dec 7, 2011 · 4 comments
Assignees
@michaelDCurran
Labels
bug feature/browse-mode
Milestone
2013.1

Comments

@nvaccessAuto
Copy link

Reported by jteh on 2011-12-07 02:12
The vbuf IDL typedefs VBufRemote_nodeHandle_t as long, but long is only ever 32 bit. However, internally, that handle just encapsulates a pointer, which could be a 64 bit pointer. Thus, in a 64 bit process, this could cause problems.

We can either make it something like a __int64 (what ever the idl equivalent is) or we could make it itself be a contextHandle, thus allowing us to make it void_. Note that you are not aloud to use void_ in idl unless its a contextHandle.
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2011-12-07 02:14
I assume that if we make it a context handle, it will get marshalled correctly to us as a 32 bit pointer, even if the remote process is 64 bit? Are we certain of this?

@nvaccessAuto
Copy link
Author

Comment 2 by mdcurran on 2012-12-05 06:01
In c007f49 VBufRemote_nodeHandle_t is now an unsigned hyper. Though to do this all the methods that returned this handle had to be rewritten to provide the handle as a final out parameter otherwize it would not compile due to complaints about optimization -- perhaps RPC can't officially return anything greater than 32 bit.
I believe I have made all the necessary changes in NVDA's virtualBuffer classes, and quick tests in Firefox, iTunes and IE seem to suggest that things work.
However, I have not tested this on a pure 32-bit system yet. Not expecting anything to break but I would like some confirmation that it does still in deed work.
Changes:
Milestone changed from near-term to 2013.1

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2012-12-05 07:27
Mick, I was just double checking and I think you might have missed line 225 of virtualBuffers/__init__.py:

          NVDAHelper.localLib.VBuf_locateControlFieldNodeAtOffset(self.obj.VBufHandle,offset,ctypes.byref(startOffset),ctypes.byref(endOffset),ctypes.byref(docHandle),ctypes.byref(ID))

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2012-12-05 23:56
I tested in 32 bit Windows XP with both IE and Firefox and saw no problems.
Changes:
State: closed

@nvaccessAuto nvaccessAuto added this to the 2013.1 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@michaelDCurran michaelDCurran

Labels
bug feature/browse-mode
Projects
None yet
Milestone
2013.1
Development

No branches or pull requests
2 participants
@michaelDCurran @nvaccessAuto