Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

KernelEx -- On building, debugging and related matters...

- - - - -

  • Please log in to reply
150 replies to this topic

#1
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag

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.


How to remove advertisement from MSFN

#2
Leyok

Leyok

    Newbie

  • Member
  • 40 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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.

Edited by Leyok, 28 February 2013 - 09:24 AM.


#3
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
- 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.

Edited by Drugwash, 28 February 2013 - 10:15 AM.


#4
Leyok

Leyok

    Newbie

  • Member
  • 40 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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.

Edited by Leyok, 28 February 2013 - 10:26 AM.


#5
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
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.

Edited by Drugwash, 01 March 2013 - 07:07 AM.


#6
Leyok

Leyok

    Newbie

  • Member
  • 40 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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.

Edited by Leyok, 01 March 2013 - 07:38 AM.


#7
Xeno86

Xeno86

    KernelEx Creator

  • Member
  • PipPip
  • 250 posts
  • OS:98SE
  • Country: Country Flag
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...
KernelEx: home board download

#8
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,782 posts
  • OS:98SE
  • Country: Country Flag

Donator

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
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
@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?

Edited by Drugwash, 02 March 2013 - 11:01 PM.


#10
Leyok

Leyok

    Newbie

  • Member
  • 40 posts
  • OS:Windows 7 x64
  • Country: Country Flag
Dencorso is important here ;)

@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
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
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
Xeno86

Xeno86

    KernelEx Creator

  • Member
  • PipPip
  • 250 posts
  • OS:98SE
  • Country: Country Flag
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.
KernelEx: home board download

#13
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
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
Leyok

Leyok

    Newbie

  • Member
  • 40 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
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
coolman

coolman

    Junior

  • Member
  • Pip
  • 80 posts
  • OS:98SE
  • Country: Country Flag



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.

Edited by coolman, 23 March 2013 - 01:24 PM.

Helicopters don't fly; they vibrate so much and make so much noise that the earth rejects them.
Oh blah, blah, blah, your needs!

#17
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
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! ;)

Edited by Drugwash, 06 March 2013 - 04:17 AM.


#18
schwups

schwups

    schwups

  • Member
  • PipPipPip
  • 410 posts
  • OS:ME
  • Country: Country Flag

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
PROBLEMCHYLD

PROBLEMCHYLD

    The Resurrector for old Windows OS

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,528 posts
  • OS:98SE
  • Country: Country Flag

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.

Believe God is the Alpha and Omega.
Believe Jesus Christ died for our sins.
Repent for your sins now or there will be
BLOOD

The Path to God


U98SESP3 03-11-2013


#20
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
@ 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.

#21
Xeno86

Xeno86

    KernelEx Creator

  • Member
  • PipPip
  • 250 posts
  • OS:98SE
  • Country: Country Flag
KernelEx does build properly under both Windows 98 SE and Windows 7 Pro x64.
Just follow the instructions here:
http://kernelex.sour...ilding_KernelEx

No virtual machine is needed.
Autoexec.bat changes aren't needed. Just set up the paths correctly inside VC6!
VC6 is 100% compatible with Windows 7 x64.

The guide applies to vanilla v4.5.2 only, cannot warrant that it will work with 3rd party mods.
KernelEx: home board download

#22
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
Those settings should work with both Xeno86's version and Ley0k's. I can build both of them without problems.

The environment variables in autoexec.bat may not be required by KernelEx, but they're automatically created at PSDK install time and may be needed by other projects, so it may not be a bad idea to have them properly set, especially for those that may wanna use this environment to build other open-source projects.

Today I've disabled the debugger on the test machine, compiled the Release version from Ley0k and installed it. Upon reboot, mprexe crashed and subsequently KernelEx reported a failed installation. Manually launching the verify tool reports the same thing. However, the Compatibility tab appears in apps' properties. Kernelex.dll is loaded in mprexe's namespace, kexcom.dll is loaded in explorer's, but neither kexbasen nor kexbases are loaded by any executable. Machine does not hang anymore. I've also disabled the SSDP service (installed by uSP) prior to installing KernelEx - don't know if that had any impact, but reenabling it sure didn't change anything. MPREXE crashes at every boot, otherwise machine appears to be running normally.

What else can I do to help?

Here's the standard crash report:
MPREXE caused an invalid page fault in
module KERNEL32.DLL at 0167:bff9e0b7.
Registers:
EAX=0072f5e0 CS=0167 EIP=bff9e0b7 EFLGS=00000246
EBX=81c08380 SS=016f ESP=0072f430 EBP=0072f5e0
ECX=0000016f DS=016f ESI=00001da7 FS=1da7
EDX=0072f5d0 ES=016f EDI=0000016f GS=0000
Bytes at CS:EIP:
cc a1 e0 dc fc bf 8b 00 66 64 f7 05 1c 00 00 00 
Stack dump:
bfa40000 81c083c4 81c09d9c 81c09d64 
81c09d78 c196b220 00000000 0072f5ec 
ffecbad7 0072f480 0072f464 0000000e 
00000007 00000000 00000000 0072f488 


#23
Leyok

Leyok

    Newbie

  • Member
  • 40 posts
  • OS:Windows 7 x64
  • Country: Country Flag
The debugger will hang the machine (and wait for user's input) if any app crashes.

Apps crashes because it cannot create or open a window station.
There is a problem with the buffer in OpenWindowStationA_new, this is why there is a sleep between sprintf and kexOpenObjectByName. On my side, when there is no Sleep, it cannot open a window station (WinSta0).
I'll try to know more about that.

#24
loblo

loblo

    Oldbie

  • Member
  • PipPipPipPipPip
  • 754 posts
  • OS:ME
  • Country: Country Flag
On the subject of Windows Me environment variables, my understanding is that WinME uses both autoexec.bat and the HKLM\System\CurrentControlSet\Control\SessionManager\Environment registry key for setting environment variables. In case autoexec.bat entries aren't getting set, it will suffice to run msconfig which will automatically copy the autoexec.bat entries into the registry and they will sure be set at the next reboot.

#25
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,239 posts
  • OS:98SE
  • Country: Country Flag
@ Leyok: Thanks for the explanation. Is there a way to communicate with the debugger, from the other machine, to resume operation and/or get more useful information? I use Hyperterminal to watch the boot progress, although I don't like it keeping the message history. Anyway, let me know if there's anything else I can do.

@ loblo: Good info! :) Apparently, XP uses the same location for its pseudo-DOS mode.

Anyway, the locations pertaining to VC6 and PSDK, found in the PATH variable string from my post above, should be set in VC6's Executable files section, as mentioned in the same post. This goes for any host OS.
In Windows ME, the other variables can be set in the Registry, at the location mentioned by loblo above, if necessary.

I'm thinking, the entries in autoexec.bat may be required only when using the tools outside the VC6 environment, that is manually building the projects in commandline mode.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN