Hola Gallego, Como nadie te contestó, me tomo el atrevimiento de reenviarte dos hilos, uno tiene el parche para DEP, pero deberías verificar si los desplazamientos son los que van con tu versión de la VM/DLL, y si no definitivamente una tarea para amantes del SoftICE (si es que todavía funciona con los nuevos Windows, seguro necesitarás parches para eso tambien).
Saludos Hernán ---------- Forwarded message ---------- From: Todor Todorov <[email protected]> Date: 2005/12/28 Subject: Vista and VSE To: [email protected] 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 <[email protected]> Date: 2008/4/24 Subject: DEP Patch for VVM31W.DLL from 03-Mar-1999 To: [email protected] 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 <[email protected]> Sender: Using Visual Smalltalk for Windows/Enterprise <[email protected]> From: Andreas Rosenberg <[email protected]> Subject: Re: WinXP-SP2 Data Execution Prevention In-Reply-To: <[email protected]> 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 <[email protected]> > > Gente: > > Alguien sabe si anda el VS 312 en 64 bits? aunque sea en algun modo de > compatibilidad? > > Saludos > GallegO > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
