Printable View
You can't mix 64bit .dll and 32bit .exe, you can however set flag in .dll "app can handle >2GB address space"... MAYBE it will do some MAGIC in background ;)
Post some ASM code from olly, I wonder what data is processed in that function.
Could you try running your server with clean SQL Database (no records) and without "char" and "Field" folders?
Yea... there's a lot of misunderstanding here.
Gzuz: I would say (in my terminology) that you cannot run PT server on more than 4Gig. Because even if the physical machine has more than 4Gig, the PT server cannot address or see that memory. You can have as much memory on the PC as you like. That won't affect PT, and I'm not suggesting it will. All I'm saying is that PT is a 32-bit application running in a "virtual" 32-bit address space which cannot exceed 4Gig, and there is unlikely to be more than 3Gig of that "free" in that address space when the image (the initial exe file) is loaded into it. That "virtual" address space isn't the entire memory space on a 64-bit OS, but it is all the memory that the PT server executable, and any DLLs imported into it will be able to see.
Vormav: You can enable the > 2Gig Flat memory flag for PT, and I know from my experience that that doesn't instantly have an adverse affect on the PT server. But that image (the server executable) doesn't use the MSVCRT DLLs. They don't have the flag set, and the Clan.dll and SQL.dll do rely on them quite heavily.
It was my understanding (from the MS documentation I have read) that if the process is created with > 2Gig flag, then somewhere between 3 and 4 Gig will be in the "virtual" flat memory space of the entire process. However, if you then set that flag on SQL.dll and / or Clan.dll...? I don't know what will happen. Setting it on either of those, and not setting it on the shared MSVC dlls sounds like a bad idea. Setting it on all of them could well be a disastrous idea, and not setting it on any of them may not give you the memory boost within the process that you hope for.
Beyond that, I cannot honestly say that I know what may happen. What I can say is that I would expect results to vary greatly between Windows NT, (by which I mean everything from NT3 to Windows 7) Windows 9x (any Windows OS running under DOS, and not the NT kernel) and Wine. I would also expect a fair amount of difference in the memory map between every version and SP revision of Windows.
I believe that this "bug" will get very complex and sticky very quickly. :wink:
Vormav , but problem is in sql.dll and not server.exe , .exe work good , we didnt find anythink bad , and we not writing it for 64 bit , but writing for more memory...
There is no more memory in 32-bit. :ott1: This is why what you are saying makes little sense.
Additionally, SQL.dll doesn't create a process. It is simply injected into the process the Kernel creates for Server.exe, and it is the flag on that which is key.
The memory allocation performed by SQL.dll is actually managed by the MSVCRT DLLs which are (should be) shared and also do not have the > 2G memory flag.
You are looking purely at the DLL, and while you can do that with server.exe and see that it works okay but (maybe) doesn't really use the extra address space you have allowed it to, the scope of the issue for DLLs is much much larger. You must look carefully at all dependencies and interoperability. (ie. other programs may also be using the MSVCRT DLLs loaded in the same physical memory, but addressed at different locations within their virtual memory space / map)
You are talking about a change which affects an entire continent, and you are telling us about just a single football field. Like that's all that counts. ^_^
The case may be that that's all that counts to you, but there will probably be considerable come-back from the way this "simple change" affects everything else in your system.
(at least the virtual 32-bit system it is running in)
You say you aren't adapting it to 64-bit, butThat isn't possible in 32-bit. It just isn't. It's like saying "I'm using a live fish out of water, and normally the fish lives for days like that, but when I force it to breath air it dies, and I don't understand why."Quote:
Originally Posted by Kakdela
We are saying "The fish lives fine on the surface in a bucket of water, maybe... You want a bigger bucket, or are you trying to graft working lungs onto this fish and do away with the bucket?" You see where we are coming from? "No, I just want it to breath air without the lungs or bucket." is kinda what we are getting back from you. :lol:
this problem solved , waiting for next about this re-writed dll :)