MSFN Forum: KernelEx -- On building, debugging and related matters... - MSFN Forum

Jump to content


  • 8 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

KernelEx -- On building, debugging and related matters... Rate Topic: -----

#1 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 28 February 2013 - 08:45 AM

View PostLeyok, on 20 February 2013 - 01:21 PM, said:

I can compile it successfully and test it (otherwise I wouldn't even improve KernelEx lol).
As COMPILE.TXT says, you will need Microsoft Visual C++ 6.0 SP6 to compile.

Hi there, nice to see the project's been picked up!

However, I pulled the zip from your Github repo, tried to compile minutes ago and it won't go all the way. First, the kexbaseN and kexbaseS projects needed a minor path change to retrieve prep.exe from the newly-added folder output-i386. Then, the order the projects are being compiled is not correct, auxiliary will fail because KernelEx.lib is not present, which means dependencies are not correctly set. Finally, the vxd project bails out because of the new vkd.h include that wasn't there in Xeno's original project and is nowhere to be found in VC6, PSDK or 98DDK includes.
I extracted MYVKD.H from the Win2k SDK and put in in 98DDK's include folder, but that's not the right thing to do since others may not have/want to use the W2K DDK and even with that header added, the vxd project still throws linker errors. Got no problems whatsoever compiling Xeno's original project, so I doubt it would be my IDE's fault.
vxdmain.obj : error LNK2005: "void __stdcall ReplaceLine(int,char *)" (?ReplaceLine@@YGXHPAD@Z) already defined in patch_ifsmgr.obj
vxdmain.obj : error LNK2005: "int __stdcall DisplayString(char *)" (?DisplayString@@YGHPAD@Z) already defined in patch_ifsmgr.obj
vxdmain.obj : error LNK2005: "int  CurrentLine" (?CurrentLine@@3HA) already defined in patch_ifsmgr.obj
vxdmain.obj : warning LNK4006: "void __stdcall ReplaceLine(int,char *)" (?ReplaceLine@@YGXHPAD@Z) already defined in patch_ifsmgr.obj; second definition ignored
vxdmain.obj : warning LNK4006: "int __stdcall DisplayString(char *)" (?DisplayString@@YGHPAD@Z) already defined in patch_ifsmgr.obj; second definition ignored
vxdmain.obj : warning LNK4006: "int  CurrentLine" (?CurrentLine@@3HA) already defined in patch_ifsmgr.obj; second definition ignored
../output-i386/Release/VKrnlEx.vxd : fatal error LNK1169: one or more multiply defined symbols found



It's understandable that this is a work in progress and errors are inherent. Is there any estimation of the moment when the repository will became stable, that is capable of being compiled? Thank you.


#2 User is offline   Leyok 

  • Newbie
  • Group: Members
  • Posts: 40
  • Joined: 18-November 12
  • OS:Windows 7 x64
  • Country: Country Flag

Posted 28 February 2013 - 09:21 AM

I fixed the issue with path, you should now able to compile kexbases and kexbasen, but you will first need to build prep (release).
If you cannot link the prep release, try to compile prep (debug), then move util/prep/debug/prep.exe to util/prep/release folder.

As for auxiliary, you will need to compile the Core project first as it will create the KernelEx library, but I added a dependency for it, so it should compile Core first when needed.
I would recommend to do a batch build, select kexcrt and Core first then select other projects you want to build.
For the VxD, I removed the "#include <vkd.h>" line and fixed the linkage issue, I tested to fully rebuild the project and it works, so it should for you.

This post has been edited by Leyok: 28 February 2013 - 09:24 AM


#3 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 28 February 2013 - 10:07 AM

- Core depends on kexcrt so it will not compile unless kexcrt is compiled first.
- Paths still not fixed in kexbaseN and kexbaseS. prep.exe is being placed in $(WkspDir)\output-i386\Release, while both projects check for an if condition in $(WkspDir)\util\prep\Release and next launch it from the same location, so there's two places to modify for each configuration (Debug and Release), in each project: replace util\prep with output-i386. Also, KernelEx.lib not found in path ../../common, since it's being created in ../../core/Release or ../../core/Debug. Changing the former path in both configurations for both projects fixed it.
- Auxiliary fails due to winsta psapi and wtsapi32 makefiles also looking for KernelEx.lib in ../../common.
I always did a batch build, it used to work in Xeno's version, only that kexcontrol had to be executed separately, after Core (Debug) and sdbcreate must be disabled since it won't execute under Win9x (I use 98SE).
I think the proper order should be (at least for the Release configuration - haven't tried to build Debug):
kexcrt
prep
Core (Debug)
kexcontrol
Core (APIHOOK)
Core (Release)
and then all the others.

EDIT:
The NSIS installer will fail if the Setup folder doesn't exist in output-i386. It should be checked for and created before the executable is built.

This post has been edited by Drugwash: 28 February 2013 - 10:15 AM


#4 User is offline   Leyok 

  • Newbie
  • Group: Members
  • Posts: 40
  • Joined: 18-November 12
  • OS:Windows 7 x64
  • Country: Country Flag

Posted 28 February 2013 - 10:18 AM

Everything work fine on my side, and the path for prep is $(WkspDir)\util\prep\Release\prep.exe. Did you re-downloaded the repository? I made change to the workspace, and apilibs/core/kexcontrol/util project files.

I also fixed the NSIS installer, it create the Setup folder if it doesn't exist.

This post has been edited by Leyok: 28 February 2013 - 10:26 AM


#5 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 28 February 2013 - 10:29 PM

I always redownloaded after you made a change, it goes without saying. Also, I either performed Cleaning or deployed it in a separate folder.
Latest changes are close to, but not perfect - auxiliary, kexbaseN and kexbaseS still not compiling because of bad path to KernelEx.lib (../../common), which - as I said before - resides in ../../core/Release and ../../core/Debug, respectively. You'll also find an 'Invalid directory' message for the Core projects.

I'll be back much later, got some things to attend to, right now. In the mean time, here's the log for a full batch compile:
Spoiler


EDIT:
I've fixed some of the projects and makefiles, it all compiles fine now as a full batch. Here's the modded files: download

EDIT 2:
I've installed the package created after compilation, on a test machine (real hardware, 98SE + unofficial SP3) - upon reboot, the boot sequence hangs while Enumerating Plug and Play Software Device Enumerator, right after it finished Enumerating TapeDetection. I managed to uninstall it and then installed the package built from Xeno's last code at Sourceforge - no problems whatsoever after reboot.
Machine is an AMD Duron 800MHz with 448MB RAM, SiS630/730 chipset.

This post has been edited by Drugwash: 01 March 2013 - 07:07 AM


#6 User is offline   Leyok 

  • Newbie
  • Group: Members
  • Posts: 40
  • Joined: 18-November 12
  • OS:Windows 7 x64
  • Country: Country Flag

Posted 01 March 2013 - 07:36 AM

Actually, you should run it on a virtual machine (VirtualBox).

If you want to see what KernelEx prints to the debugger :
Assign a serial port to the virtual machine : COM1, host pipe, must create the pipe and the path must be \\.\pipe\ followed by the name you want (here I have \\.\pipe\win_pipe).

Copy all files from the 98DDK\DEBUG_WINDOWS98SE\RETAIL folder (symbols files) or D:\98DDK\DBG_SYM\RETAIL\WINDOWS\SYSTEM as well as 98DDK\bin\WDEB386.EXE and 98DDK\bin\RUNWDEB.WRF to the Windows 98 Virtual Hard Disk\WINDOWS\SYSTEM (either by using WinImage or using Windows 7's disk manager to open the VHD image).
Open AUTOEXEC.BAT stored in the VHD's root and copy this:

cd WINDOWS\SYSTEM
wdeb386.exe /n /x /c:1 /r:115200 /f:runwdeb.wrf ..\win.com



then save it to the VHD.

Download PuTTY for windows and run it (can be found here)
Go in the session category In serial line, type \\.\pipe\ followed by the name you assigned on the virtual machine serial port (for me it would be \\.\pipe\win_pipe).
The connection type must be serial, the speed (baud's rate) must be 115200 as well.
Launch the virtual machine, and on the PuTTY's window, click open.

If serial port is not working, the setup explained well here.

This post has been edited by Leyok: 01 March 2013 - 07:38 AM


#7 User is offline   Xeno86 

  • KernelEx Creator
  • PipPip
  • Group: Members
  • Posts: 250
  • Joined: 26-March 06
  • OS:98SE
  • Country: Country Flag

Posted 02 March 2013 - 03:29 PM

Actually you only need wdeb386.exe and no other files for debug output. Physical machine is also okay. You only gotta connect two machines with serial cable.

Also I suggest moving this discussion to a separate thread...

#8 User is offline   dencorso 

  • Adiuvat plus qui nihil obstat
  • Group: Super Moderator
  • Posts: 4,862
  • Joined: 07-April 07
  • OS:98SE
  • Country: Country Flag

Posted 02 March 2013 - 05:55 PM

View PostXeno86, on 02 March 2013 - 03:29 PM, said:

Also I suggest moving this discussion to a separate thread...

Done. If you think some previous post fits better here, please let me know. @Drugwash: congrats, you became thread starter! :)
Cheers to you all!

#9 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 02 March 2013 - 11:00 PM

@dencorso: Wow, I feel important now! :P However, for some reason, when splitting posts from other thread, the mail notifications stop coming. I had not received a notification for Leyok's post #6 from March 1 at 3:36PM and if it wasn't for Xeno's reply #7 from March 2 at 11:29 PM (got notification for that), I wouldn't have known the topic has been split. There was no notification for your 1:55AM reply #8 either. Could you please check the notification system (I always set notifications to 'instant')? Thank you.

@Xeno86: Sorry about the off-topic in the original topic, it's OK now. And thanks for everything! :thumbup
I might have a serial cable I've used a couple years ago in a project of mine, but I'm not at all familiar with such configuration :blushing: and it might not even be long enough to connect both machines (can't move them around, there's a whole mess in my room).

@Leyok: Could there be an option to print debug to file, as a choice? Thing is, I can't set up a virtual machine and am not familiar with that kind of configuration either. Besides, for the issue at hand, I can access all partitions of the test machine through local network from my main 98SE machine, even when it's stuck at boot time - apparently, the network drivers are already loaded by the time it hangs. Therefore I can open and read a log file, which would be much easier for me. I found out exactly where it hangs by comparing the two versions of bootlog.txt: the one created with KEx 4.5.3 beta and the one created with original KEx 4.5.2.

Any other alternative ideas?

This post has been edited by Drugwash: 02 March 2013 - 11:01 PM


#10 User is offline   Leyok 

  • Newbie
  • Group: Members
  • Posts: 40
  • Joined: 18-November 12
  • OS:Windows 7 x64
  • Country: Country Flag

Posted 03 March 2013 - 05:14 AM

Dencorso is important here ;)

View PostDrugwash, on 02 March 2013 - 11:00 PM, said:

@Leyok: Could there be an option to print debug to file, as a choice? Thing is, I can't set up a virtual machine and am not familiar with that kind of configuration either. Besides, for the issue at hand, I can access all partitions of the test machine through local network from my main 98SE machine, even when it's stuck at boot time - apparently, the network drivers are already loaded by the time it hangs. Therefore I can open and read a log file, which would be much easier for me. I found out exactly where it hangs by comparing the two versions of bootlog.txt: the one created with KEx 4.5.3 beta and the one created with original KEx 4.5.2.

Any other alternative ideas?


I was thinking to add an option to write to log file directly, I'll add that the debugger.

#11 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 03 March 2013 - 06:04 AM

That would be great, thank you!

And it just occured to me that you might create a second NSIS installer script for a debug package, so that the original Release package would behave normally (being built from the Release branch) while the Debug package (built from the Debug branch) would be the one that creates log and/or sends over pipe.

#12 User is offline   Xeno86 

  • KernelEx Creator
  • PipPip
  • Group: Members
  • Posts: 250
  • Joined: 26-March 06
  • OS:98SE
  • Country: Country Flag

Posted 03 March 2013 - 05:08 PM

You can already create debug installer package with the following command-line:

"c:\Program Files\NSIS\makensis.exe" /D_DEBUG KernelEx.nsi

As for debugging, put wdeb386.exe from 98ddk\bin under C:\WINDOWS and execute this command-line:
wdeb386.exe /n /c:1 /r:19200 win.com


On second computer run a serial port terminal - hyperterminal / putty / whatever.

#13 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 04 March 2013 - 03:36 AM

Thanks for the tip, Xeno. Apparently, _DEBUG is already defined in the .nsi script I got here, so running that command line results in an error.
Good thing is, while the command line wouldn't run from within Total Commander, I just modified the Registry, adding a context menu item for building with the Debug switch on, so now it's a breeze choosing Release or Debug with a simple right-click on the .nsi script. :)
But the _DEBUG switch should be removed from the .nsi script, so that building in Release mode would work correctly.

REGEDIT4

[HKEY_CLASSES_ROOT\NSIS.Script\shell\compile-debug]
@="Compile NSIS Script (Debug)"

[HKEY_CLASSES_ROOT\NSIS.Script\shell\compile-debug\command]
@="\"C:\\Program Files\\NSIS\\makensisw.exe\" /D_DEBUG \"%1\""




@Leyok: have you ever tried to build the whole project in batch mode on a 9x machine? I see you keep using the Post-build 'copy' command in the Core project, but here on my machine, the KernelEx.lib file is never copied to the destination folder, making kexbasen, kexbases and auxiliary projects fail at link time, not finding ../../common/KernelEx.lib.

Moreover, I may be wrong but in my logic, the Debug versions of kexbasen and kexbases should use the Debug version of the KernelEx.lib library, whereas currently, the way the batch order is and considering the copying of the KernelEx.lib library, they would always build through the library create by the APILIB version of the core (if the file would be succesfully copied to the destination folder, that is). I'm not sure of the implications, if any - just saying.

Have you tried using the modified project files I linked to somewhere above? They worked perfectly here. I'll be back a little later, after I manage to build, install and test the new version.

#14 User is offline   Leyok 

  • Newbie
  • Group: Members
  • Posts: 40
  • Joined: 18-November 12
  • OS:Windows 7 x64
  • Country: Country Flag

Posted 04 March 2013 - 03:55 PM

Check again, I edited the postbuild command.
Instead of copy /Y "$(OutDir)\KernelEx.lib" "$(WkspDir)\common\ it would be copy /Y "$(OutDir)\KernelEx.lib" "..\common\".

It's odd that the WkspDir is invalid on your side, It should copy KernelEx.lib to the common folder, on my side it works, I tried both Xeno's repository and mine.

Anyway, adding a menu to compile the debug version of NSIS scripts is useful. I was planning to release both Release and Debug version of KernelEx ;).

#15 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 05 March 2013 - 03:43 AM

No, it doesn't work for me. :( BTW, you forgot to change the path in the APILIB configuration, which is the latest being built and precisely the one that's being used by all other projects atfterwards. Reason why I insist on leaving the KernelEx.lib versions where they are and just modify the paths in the other projects (kexbasen, kexbases and auxiliary) such that they always use the proper version of KernelEx.lib, whether the projects are compiled in Release, Debug or full batch mode. That solution worked for me everytime, after every commit. I do not know why exactly the copy operation does not work, but since it's not even necessary (at this point), we shouldn't bother with this and just settle on a configuration that works, primarily in 9x and I'm certain it would work in XP/Vista/7 too.

Has anyone tried the modified projects from here? Do they work for you as they do for me?

Here's some debug logs:
Spoiler


#16 User is offline   coolman 

  • Junior
  • Pip
  • Group: Members
  • Posts: 80
  • Joined: 02-November 12
  • OS:98SE
  • Country: Country Flag

Posted 05 March 2013 - 07:07 PM

View PostLeyok, on 20 February 2013 - 01:21 PM, said:

View PostPROBLEMCHYLD, on 20 February 2013 - 12:17 PM, said:

View Postcoolman, on 19 February 2013 - 09:04 PM, said:

That looks great, Ley0k!
Would someone care to compile his repository, for some of us newbies?
It seems somewhat of a headache to compile. For starters, if you don't have or use the tools thats needed, then one must learn them all. This can be time consuming. I guess we will have to wait for someone to compile it.


I can compile it successfully and test it (otherwise I wouldn't even improve KernelEx lol).
As COMPILE.TXT says, you will need Microsoft Visual C++ 6.0 SP6 to compile.

I have been trying to compile the NSIS Installer (Kernelex.nsi) for a while now, but it keeps throwing up errors that it can't find files in the destination dir. These are the sections in the .NSI that caused the error:
Spoiler

(If I remove one of the lines that caused the error message, it will just move to the next file and bring up the same error message as well. Just removing those lines in the file would make no sense, because the files described in there are critical to the main functionality of KernelEx (I think))
This is the error message I get with or without removing the lines.
File: "output-i386\Debug\KernelEx.dll" -> no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
   /oname=outfile one_file_only)
Error in script "C:\WINDOWS\Desktop\KernelEx-master\KernelEx.nsi" on line 244 -- aborting creation process


From what I can tell, It seems to create the installation directory (output-i386 or as NSIS would call it '$INSTDIR'), but it can't find any data in that directory, and that's a problem.

I also tried to compile some of the C++ .dsw files with VC++ 6.0, but it keeps telling me it can't execute (or find) rc.exe, cl.exe, etc.

This post has been edited by coolman: 23 March 2013 - 01:24 PM


#17 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 06 March 2013 - 03:07 AM

All the errors you get are due to incorrect/incomplete installation of the development environment. The file COMPILE.TXT in the root of the KernelEx source folder specifies the prerequisites:
- Visual C++ 6.0 SP6
- updated xtree header
- Platform SDK february 2003
- Windows 98/2000 DDK


In VC6 main menu > Tools > Options > Directories go through all items in the 'Show directories for' list and make sure the order of the items is as follows (that's important!):
Executable files
C:\Program Files\Microsoft Visual Studio\VC98\BIN
C:\Program Files\Microsoft Visual Studio\COMMON\MSDEV98\BIN
C:\Program Files\Microsoft Visual Studio\COMMON\TOOLS
C:\Program Files\Microsoft Visual Studio\COMMON\TOOLS\WIN95
C:\Program Files\Microsoft SDK\BIN
<other>

Include files
C:\Program Files\Microsoft SDK\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE
C:\Program Files\98DDK\INC\WIN98
<other>

Library files
C:\Program Files\Microsoft SDK\LIB
C:\Program Files\Microsoft Visual Studio\VC98\LIB
C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB
C:\Program Files\98DDK\LIB\I386\FREE
<other>

Source files
C:\Program Files\Microsoft Visual Studio\VC98\CRT\SRC
C:\Program Files\Microsoft Visual Studio\VC98\MFC\SRC
<other>

Also, if you're running VC6 under Win98/ME (and maybe not only these), there are a few additions required in AUTOEXEC.BAT so the system would know where to get the tools from:
SET PATH=%PATH%;C:\PROGRA~1\MICROS~6\Bin;C:\PROGRA~1\MICROS~6\Bin\Win9x;C:\PROGRA~1\MICROS~4\Common\MSDev98\Bin;C:\PROGRA~1\MICROS~4\Common\Tools
SET Basemake="C:\Program Files\Microsoft SDK\Include\BKOffice.Mak"
SET Bkoffice="C:\Program Files\Microsoft SDK\."
SET INCLUDE="C:\Program Files\Microsoft SDK\Include\."
SET INETSDK="C:\Program Files\Microsoft SDK\."
SET LIB="C:\Program Files\Microsoft SDK\Lib\."
SET MSSdk="C:\Program Files\Microsoft SDK\."
SET Mstools="C:\Program Files\Microsoft SDK\."


Please note that some of the items in the PATH variable may have different short names on each system, depending on the path they've been installed to; they usually are added by VC6 at installation time but I recall there's an option to skip this step so please check. There may be an option to add these system variables from within VC6 but I can't say where exactly - maybe someone else could chime in on this matter.

Also please note that not all of the items in the Directory list groups are required in order to correctly compile KernelEx but they may be required for other projects, so it's a good idea to set them up properly right now. If someone more knowledgeable notices anything wrong or missing with my advices, please do correct me.

Finally, please do read above in this topic in regard to a few minor issues in the KernelEx project files.

Oh and just to be clear: the NSIS packager cannot pack something that has not been compiled, so you definitely have to make VC6 work, compile the whole KernelEx project in batch mode and only after that launch the NSIS packager. The current .nsi script builds the Debug version of KernelEx so all pertaining components should be compiled and available. Using the modified project files I provided in the reply above, should allow a flawless batch compilation of the whole project. Just make sure there's enough free space on that partition.

Good luck! ;)

This post has been edited by Drugwash: 06 March 2013 - 04:17 AM


#18 User is offline   schwups 

  • schwups
  • PipPip
  • Group: Members
  • Posts: 272
  • Joined: 11-November 09
  • OS:ME
  • Country: Country Flag

Posted 08 March 2013 - 10:53 AM

Quote

Has anyone tried the modified projects from here? Do they work for you as they do for me?


Hallo Drugwash,

I've installed the KernelEX Build Environment on ME and Vista, but I think my environment is still faulty. All "Batch Builds" gives errors and hence to compile with NSIS 2.44. I have yet to read, learn and test a lot. I hope the next days I get some positive results. I'll report! I don't have the 98DDK. The downlads on MDGX are dead - "You're sunk in windows ...error 404"?? - . I have 2K / ME DDK's. Xeno says: "Microsoft Windows 98 Driver Development Kit or Microsoft Windows 2000 Driver Development Kit". On Vista I get on install and start Visual Studio 6.0 messages stating "known compatibility issues". But obviously it seems to run.?.



#19 User is online   PROBLEMCHYLD 

  • The Resurrector for old Windows OS
  • PipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 2,465
  • Joined: 07-October 05
  • OS:98SE
  • Country: Country Flag

Posted 08 March 2013 - 11:50 AM

View Postcoolman, on 05 March 2013 - 07:07 PM, said:

I also tried to compile some of the C++ .dsw files with VC++ 6.0, but it keeps telling me it can't execute (or find) rc.exe, cl.exe, etc.
Same message I got, If I wasn't working on other projects, I would have invested more time in it. Lets hope someone can compile it correctly since it seems like everyone is having some issue or another.

#20 User is offline   Drugwash 

  • MSFN Expert
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 1,097
  • Joined: 21-June 06
  • OS:98SE
  • Country: Country Flag

Posted 08 March 2013 - 12:20 PM

@ schwups: VC6 is old, it may not be 100% compatible with newer Windows; should work under ME though. Problem is, ME doesn't have a real DOS and doesn't take into account autoexec.bat, so even if VC6 and PSDK added the required lines, they will not take effect.

I wish I had more experience with ME, to know how to overcome this issue. Thing is, VC6 and PSDK need those environment variables to know where to find its tools. If those variables aren't set (which is the job of the autoexec.bat lines), VC6 will fail. Maybe the variables can be set through the registry, but we'll have to wait for someone more knowledgeable to point to the right direction. After that, the rest of the settings I listed in the post above should be checked and properly set.

One alternative solution would be to install a virtual machine under Vista, install 98SE and set up VC6, PSDK and the rest of the development environment, then try to compile. Personally I'm not a big fan of virtual environments, always did things on real hardware even if it took much longer (that's what experience builds up from), but in extreme situations such environment may prove useful. Well, it's worth a shot anyway.

@ PROBLEMCHYLD: I've always managed to build the project, but only after a few small changes to the projects. Unfortunately, after installing it, the machine hangs upon reboot. I've provided a few debug logs above, hopefully they'd be of some use. Haven't checked out the repository today, see if there's any newer commit; will do that soonish.
Please see my reply above to schwups, your problem might be the same, with missing environment variables in autoexec.bat.

Share this topic:


  • 8 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users



All trademarks mentioned on this page are the property of their respective owners
Copyright © 2001 - 2013 msfn.org
Privacy Policy