Quote:
Originally Posted by madmerlin3009
there are 2 missing library headers for the client bogdy already posted a while back.But also i guess people forgot to realise that the .dsp file alters when you alter the full compile paramaters.Ie include headers.The .dsp will self generate , so each time triggers and conditions are sent to the complier and linker. Jesus dont you know about defined user space, in .net. Your complile and link space, is pre generated on your first attempt.
errors mainly occur due to you not scoping you environmental parameters to the correct folders. jesus!!!
|
Just to clarify a lot of fake info you gave - .dsp file is a "project" file containing the information about its structure. You can easily open it in Notepad and check what does it contain. Well, it was used in old versions of Visual Studio, now you may know it as a ".vcxproj" - that's basically the same, but in XML. Don't take me wrong, I'm not here to humiliate you - just wanted to mention some facts why this .dsp file may be important.
Code:
!ELSEIF "$(CFG)" == "EODLoginServer - Win32 Debug"
# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 1
# PROP BASE Output_Dir "Debug"
# PROP BASE Intermediate_Dir "Debug"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 1
# PROP Output_Dir "Debug"
# PROP Intermediate_Dir "Debug"
# PROP Ignore_Export_Lib 0
# PROP Target_Dir ""
# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c
# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /D "_WIN32_DCOM" /FR /YX /FD /GZ /c
# ADD BASE RSC /l 0x412 /d "_DEBUG"
# ADD RSC /l 0x412 /d "_DEBUG"
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept
# ADD LINK32 winmm.lib ws2_32.lib Iphlpapi.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /out:"ExeFiles/NDLogin_D.exe" /pdbtype:sept
# SUBTRACT LINK32 /pdb:none
It also keeps the data such as configs for the compilation and linking processes. It includes the names of the static libraries (.lib), defines the appropriate SDK, sets the flags, etc.
Also, correct me if I'm wrong, but calling clean C++ a ".NET" is kinda... incorrect. It's true that C++/CLI is a part of .NET platform, but:
- it's an extension for "managed c++",
- it's not a 'valid' ISO C++.
While it is true you can "regenerate" .dsp file, it's rather dubious it'll be correct. You can just recursively add all of the files in the project as a "source item", but you still won't get any configuration back.
Quote:
Originally Posted by annoyinglyUgly
Can you send the 2009 server/client source? All I want is the old acclaim UI. You don't know how many hours I wasted trying to make the 2008 client and server work. The old UI only works with the old data folder + an old exe file that loads the stuff. Problem is I cannot log in with old ninedragons dot exe's because of f*cking
1.) packet size error
2.) bad sequence error
3.) LMBC (Login Mode By Company)
4.) Size Mismatch
I can compile an old Login_srv dot exe and I can alter the source but I don't know how to tell the login server to f*cking let me log in with any temp acc/id pw... otherwise I'd need a valid account and password to log in with, which is impossible because I don't know how the old DB structure is. This is beyond frustrating. Also, this "test login" BS that was created by Indy is just a declared bool and that's it. It has no functionality. Trash-ass lame Indy21 programmers. Worst coders in this universe.
|
The most annoying part of dealing with it would be actually refactoring the code and analyzing it to get the valid structures. Even if you manage to deal with LS, you still would have an incompatible GS, and that one is a pain in the ass. Trust me on this one.
Well, if you're still going, your safest bet would be changing the COLE_DB_Executer::AcclaimLogin method - as long as you're not going to use the database. It's basically the dead-end street. You may consider analyzing the DS for the database structure. At least for the DB part. For the packet stuff, you are probably going to RE a bit to get the packets right. Both the ones sent by the client and the GS responses.