Jump to content

KernelEx Apps Compatibility List (New)


Recommended Posts

Is anyone else here having trouble getting sound to play in vlc 2.1.3. I tried UPXing multiple fresh copies, but I get the same result no sound.

EDIT: reverted backdown to vlc 2.1.2 and still have the sound issue,so it seems to not be a 2.1.3 issue, but rather an issue of my setup. I'll investigate some more.

Edited by Flasche
Link to comment
Share on other sites


With the help of a friend of mine, the problem is figured out :

23:16:19: I will try once more to explain in text
23:21:01: I have figgured it out proper
23:22:02: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366775(v=vs.85).aspx
23:22:27: RegionSize

The size of the region beginning at the base address in which all pages have identical attributes, in bytes.
23:23:22: Because win9x does not support execute PAGE_EXECUTE_READ
23:23:45: that page could merge with another page of PAGE_READONLY
23:24:19: somehow this has manifested to confuse the startup code and it ends up setting its .data section as read only


... bunch of testing....


0:24:11: I 100% know the problem now
0:24:49: winnt has another type of flag PAGE_WRITECOPY, win9x does not have that either
0:25:06: 6A540000, 000000, 001000, R
6A541000, 001000, 12B000, ER
6A66C000, 12C000, 002000, WC
6A66E000, 12E000, 001000, RW
6A66F000, 12F000, 10C000, R
6A77B000, 23B000, 002000, RW
0:25:26: there is a section of write_copy between .text and .data
0:25:51: on win9x the WC is merged with the RW below as just RW
0:26:11: when ER is changed to WR it merges with the RW below
0:26:44: the startup code uses VitualQuery to get the size of the .text again instead of caching its previous result
0:28:07: without the buffer of WC all the RW merges together and .data ends up being made write only when .text is reset to write only after temporary write access to apply start time code mods
0:28:49: somebody should report this to gcc as a library bug
Link to comment
Share on other sites

Interesting information that provides a few more details on what went wrong, but nothing on why (or where). We already knew there was a loader problem. Also doesn't explain why VLC 2.1.2 works and VLC 2.1.3 doesn't (same section definitions).

Can you ask him to do the same analysis for the VLC 2.1.2 libvlccore.dll? Also the UPXed and patched .text versions. And what tool is he using to get the memory page details? Thanks.

Link to comment
Share on other sites

Jumper, if you've got some spare time, could you look into the recent built of executables that crash in kexbases.dll? It seems like a generic issue and it's very annoying. As per faultlog.txt most crash in kexbases.dll at 0177:bfa41cbe and have no apparent missing functions/dependencies in common which seem to exclude a problem with KernelEx inadequate definitions. I can run the affected console programs without crashing in kexbases by profiling them in Dependency Walker, GUI apps fail to start in DW for other (and quite usual for KernelEx only apps) reasons.

Presumably interesting examples:

ffmpeg: both shared and static builds are identically affected. Only ffmpeg.exe and ffprobe.exe crash, ffplay.exe doesn't. All run without crashing from within DW. All files require the UPX or writable .text section fix first. Crashes occur at 0177:bfa41c54 which is slightly different than for most other programs.

http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-20140405-git-ec8789a-win32-static.7z

http://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-20140405-git-ec8789a-win32-shared.7z

zxtune: both latest (r3000) MINGW and MSVC builds are affected. Earlier builds (r2850) both run fine. Includes GUI and console programs. All console programs run without crash from within DW.

https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/2850/mingw/x86/zxtune_r2850_mingw_x86.zip

https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/2850/windows/x86/zxtune_r2850_windows_x86.zip

https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/3000/mingw/x86/zxtune_r3000_mingw_x86.zip

https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/3000/windows/x86/zxtune_r3000_windows_x86.zip

Well, those are 2 different issues altogether and I have solved the second one. It was down to having added an entry and definition for the InitializeCriticalSectionEx kernel32 function in Kstub822.ini which I have now removed and all is fine. This breaked most apps compiled with VS2013.

FFmpeg issue is not down to KexStub as it still occurs without it running. Suspecting am inadequate KernelEx def I shall investigate more. Perhaps I'll figure it out too.

Link to comment
Share on other sites

Interesting information that provides a few more details on what went wrong, but nothing on why (or where). We already knew there was a loader problem. Also doesn't explain why VLC 2.1.2 works and VLC 2.1.3 doesn't (same section definitions).

Can you ask him to do the same analysis for the VLC 2.1.2 libvlccore.dll? Also the UPXed and patched .text versions. And what tool is he using to get the memory page details? Thanks.

He just wrote the test tool as we spoke about it. Plus he has code from older times to use for the purpose.

He writes some stuff, sends it over to me, I run it, send back error results and wait for another test. Couple hours went by like that haha.

Once he appears again I will poke him about the 2.1.2.

Link to comment
Share on other sites

And I poked him again, and this is what he told :

18:28:30: Its not the section structure
18:29:23: something changes the state of the pages to COPY WRITE
18:30:34: the first two pages of .data section get changed from READ_WRITE to WRITE_COPY
18:30:53: I do not know what api call does this, something todo with shared mapping
18:31:07: however win9x does not support this page mode
18:32:01: so there is no boundry between the remaining READ_WRITE pages of .data and the pages of .text which where temporarly made READ_WRITE
18:35:09: I will try hooking MapViewOfFile and see if that is culpret

18:44:06: actually the problem is nothing to do with the section structure
18:44:29: it seems that the WRITE_COPY section is set by windows

18:46:18: its a memory optimisation, setting the .data section to copy on write in case the program decides not to change it
18:47:23: it seems to only apply to complete pages, that would explain why the last partial page is normal READ_WRITE
18:47:50: if this is the case then the gcc startup code actually has a bug that would effect modern windows
18:48:10: if the program has less than 4kb of data then it would crash I would think

I'll edit the post when more info is available.

Edited by TmEE
Link to comment
Share on other sites

Posted in the wrong place.

New version mp3DirectCut. Still supporting Windows 98.

Features:
Non-destructive cut, copy, paste
Volume change, fade, normalize, pause detection
mp3 recording with ACM or Lame encoder
Fast mp3 visualisation and easy navigation
Supports Layer 2 (dvd/dvb audio)
ID3v1.1 tag editor · ID3v2 tag keeping
Cue Sheet support
Auto cue (track dividing by time values)
Track splitting with filename and tag creation
Trim · Crop · Fast play · Loop play
VU meter, bitrate visualisation
High speed recorder · Command line usage
Unicode support

http://mpesch3.de1.cc/mp3dc.html

Edited by petekeller
Link to comment
Share on other sites

Yes, this soft is very useful: very quick and light to work on Mp3 files, with no loss of quality (non-destructive).

New version 2.20 is running as well as the previous ones.

The good link is indeed: mp3DirectCut

...but I doubt it is needing KernelEx to run.

Seems to me that its right place should be : http://www.msfn.org/board/topic/105936-last-versions-of-software-for-windows-98se/

Edited by CharlesF
Link to comment
Share on other sites

  • 4 months later...

More blues for MPlayer.exe versions that run under KernelEx.  

Redxii's "MPlayer For Windows" starting with version svn-r37205 and sherpya's "MPlayer For Win32" starting with version svn-r37220 give this error message:

  The MPLAYER.EXE file is linked to missing export KERNEL32.DLL:GetCurrentConsoleFont.

The last redxii MPlayer.exe that works under KernelEx (with the UPX fix) is svn-r37203: http://sourceforge.net/projects/mplayerwin/files/MPlayer-MEncoder/r37203/

The last sherpya MPlayer.exe that works under KernelEx (with the UPX fix) is svn-r37199: http://sourceforge.net/projects/mplayer-win32/files/MPlayer%20and%20MEncoder/r37199%2Bg5e95551/

- Doug B.

Edited by DougB
Link to comment
Share on other sites

@ DougB.

Just add GetCurrentConsoleFont=z2 to the Kernel32 section of Kext and mPlayer will run again.

(But Jumper may know a better def than z2)

I played around with mPlayer the last couple of days but mp4 files are out of sync by several seconds !!

I went this far with my settings but I had no succes (-autosync 100 -cache 2000000 -cache-min 99).

 

Do you maybe have any suggestions ?

Link to comment
Share on other sites

Thanks for the tip, Mikl -- it works!  

One question though (KExt is pretty far over my head).  Looking through the Windows\KernelEx\ folder, i found a [Kernel32.dll] section in two files: K452STUB.INI and KSTUB822.INI.  I added the "GetCurrentConsoleFont=z2" line to both.  But do i need to do that, or would it be better to just add it to one of the files or the other?  

BTW, i checked out some M4V/MP4 video files, and they played ok (no synch problems) on my system with the latest builds of both the sherpya and redxii MPlayer.exe.  

- Doug B.

Link to comment
Share on other sites

Hi Doug, I do not have a k452stub.ini in my KernelEx folder. Maybe this was an earlier version ?

Just make sure that k452stub is not in the Core.ini under DCFG1 because otherwise this may cause trouble.

But Jumper will surely know better.

 

Did you ever used the EDL function of mPlayer ??

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...