---------- Forwarded message ----------
From: Todor Todorov <t
...@cdm.dk>
Date: 2005/12/28
Subject: Vista and VSE
To: VSW
...@listserv.dfn.de
Hi VSE list,
I got an a mail from George Lewis asking about VSE and Vista. I thought that
the speculations in my answer could be interested other people here, so here's
the correspondence. Others ideas on the issue are welcome ;-)
-- Todor
=======================
Hi George,
Yes, we still use VSE heavily. As matter of fact, 95% of development I did
the last two years was in VSE. VSE is still much more productive than
switching to .Net. Well, Vista will have to be compatible with previous
versions of Windows, so VSE applications should work. However, there might
be some things one should know.
- On 64 bit systems it will run inside WOW (Windows On Windows - the 32 bit
windows emulator). This is however the case for 90% of all other
applications (at the moment).
- On machines with Data Execution Prevention, the VM will not work because
it generates machine code on the fly that is not marked for execution. VSE
can be excluded from DEP by administrators or the VM can be patched to
allocate memory with execution permissions. I know that a unofficially
patched VM exists to solve that problem, and from what I've heard, with the
right knowledge, it shouldn't be that difficult
The new Vista features might not be available to VSE. We have two options,
however I have not explored them at the moment due to lack of time and
resources.
1. Implement new Vista features natively inside VSE.
2. Embed VSE into some kind of .Net component with an appropriate bridge to
communicate between the .Net framework and VSE. An application will probably
have some .Net and some VSE code.
The second solution, and probably the first will require access to the VM
source code. I know that the source code can be licensed from Seagull for an
undefined amount of money. Then we have to get VSE to run in-process (as a
DLL) and create some bridge so communication and better, method invocation
can be done between VSE and .Net.
I prefer the second solution, because if we achieve that I believe that GUI
portions of our application will be written in .Net and business logic in
VSE. Also, the .Net class library will be exposed to VSE and VSE can use all
of the infrastructure and plumbing in .Net.
-- Todor
.
---------- Forwarded message ----------
From: Sergey Gitis <gi...@objectland.ru>
Date: 2008/4/24
Subject: DEP Patch for VVM31W.DLL from 03-Mar-1999
To: VSW...@listserv.dfn.de
Dear all,
My question refers Andreas Rosenberg's DEP patch (see below).
Have anyone a file offsets of DEP patch for VVM31W.DLL from 03-Mar-1999?
Thank in advance.
Sergey Gitis
==============================
==============================
Date: Fri, 22 Apr 2005 10:10:33 +0200
Reply-To: Using Visual Smalltalk for Windows/Enterprise
<VSW...@LISTSERV.DFN.DE>
Sender: Using Visual Smalltalk for Windows/Enterprise
<VSW...@LISTSERV.DFN.DE>
From: Andreas Rosenberg <andreas.rosenb...@APIS.DE>
Subject: Re: WinXP-SP2 Data Execution Prevention
In-Reply-To: <646B0AFE82D7D54B88596A6CA411FD1C01683...@s-hqmx2.pmbelz.de>
Content-Type: text/plain; charset="iso-8859-1"
Hi!
Yes, I've done the patch. Here are my notes regarding the patch:
--------------------------------------
Patches regarding the WinXP NX Feature
Parameters for VirtualAlloc needs to be switched from
PAGE_READWRITE (0x04) to PAGE_EXECUTE_READ_WRITE (0x40).
Following addresses were patched:
(file offsets - decimal)
38898,39077,38628,38679,39153
(file offsets - hexadecimal)
097f2,098A5,096e4,09717,098F1
(Offsets seem to be the same for these VVM31W.DLLs
checked: 200.704 bytes - 24.11.2003
200.704 bytes - 04.11.2001
190.976 bytes - 11.12.1995
these are different:
192.512 bytes - 05.11.1996
(no file offsets known)
address contains the opcode (usually a push 0x6a) -
next byte is the FL_PROTECT parameter
----------------------------------------
But this is not the only thing that needs to be fixed. Also
the Callback class allocates memory, that is being filled
with code thunks. The following changes must be done:
----------------------------------------
!KernelDLL methods !
virtualAlloc: lpAddress size: dwSize allocationType: dwAllocationType
protect: dwProtect
<api: VirtualAlloc ulong ulong ulong ulong ulongReturn>
^self invalidArgument!
virtualFree: lpAddress size: dwSize freeType: dwFreeType
<api: VirtualFree ulong ulong ulong ulongReturn>
^self invalidArgument! !
ExternalAddress subclass: #ExternalVirtualAddress
instanceVariableNames: 'memorySize '
classVariableNames: ''
poolDictionaries: 'OperatingSystemConstants '!
ExternalVirtualAddress class instanceVariableNames: ''!
!ExternalVirtualAddress class methods !
allocateMemory: size
"Allocate size number of bytes in host memory.
Answer an Address for the allocated memory."
| addressPtr address |
addressPtr := KernelLibrary virtualAlloc: 0 size: size allocationType:
MemCommit protect: 16r40. "PageExecuteReadWrite"
addressPtr = 0
ifTrue: [ ^self osError ].
address := self fromInteger: addressPtr.
address memorySize: size.
^address! !
!ExternalVirtualAddress methods !
memorySize: anInteger
memorySize := anInteger.!
memorySize
^memorySize!
memoryHandle
^0!
free
"Free the receiver."
self isValid ifFalse: [ ^self ].
KernelLibrary virtualFree: self asParameter size: self memorySize
freeType: MemDecommit.
contents := ByteArray new: 4.
memorySize := nil! !
!CallBack methods !
allocateSlot: anInteger
"Private - allocate host memory for the callback entry prologue."
^ExternalVirtualAddress allocateMemory: self class slotSize! !
------------------------------------------------------------------
This fixes the access violation with the NX feature enabled.
Regards
Andreas
2009/11/10 GallegO <fxgall...@gmail.com>
> Gente:
> Alguien sabe si anda el VS 312 en 64 bits? aunque sea en algun modo de
> compatibilidad?
> Saludos
> GallegO
|
