Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About Chainfire

  • Rank
  1. - zlib_mn needs to be present in \Windows - Manila does NOT need to be patched to use libgles_mn (nor does this file need to be present) like on HTC devices, we've built all the CFC magic directly into the OpenGLv1 library
  2. Hurrah for progress :huh: 90 MWIPS on my stock unbranded 1.66 EU HD2.
  3. What exactly happens on JD1 ? Nothing at all, FPU enabler does not even start ?
  4. AutoClosePatch http://www.chainfire.eu/#/articles/68/Auto...h_1_1_released/ solves the issue for me - then again, I wrote it <_<
  5. WTH, still ? That sucks man ! I'll surely send one of those mails
  6. I'm not sure about the GUI yet, perhaps I'll make it myself so I can throw it on Marketplace for $0.99 :( Far from sure about that, though. I'll think about it some, and I'll see about at least implementing the do-not-close functionality next week.
  7. Actually for my day job I am in regular contact with Samsung's various Windows Mobile divisions. Never the development division, though, unfortunately. Does SKKV actually work for OEMs to fix stuff? I thought they just released apps and tools to consumers?
  8. It would require completely changing how the patch works internally to work right. I can't just implement in the current patch, because the patched functions may be called often (several times a second if memory is relatively low) and it this checking prioritizing actually does require quite a bit of CPU, so you don't want to do it that way. Then again, if only implementing a do-NOT-close list, that could be done without much impact (especially if changes require a reboot), but prioritizing aside from that is tricky.
  9. I have actually had that message once or twice during testing, but around 10mb (which is why I previously stated going lower gave me trouble). I've never seen it happen on 1.1, though. There is probably somewhere the system still checks available memory when starting an EXE, I'll have a look if I can find where this happens so I can patch it.
  10. Interesting thought and I had indeed thought of making it this way, however it is a LOT of extra work I'm not sure I'll have time to do anytime soon. In essence I would probably have to completely disable WM's internal auto-close system, and roll my own. The problem with this is that there are still a few parts of the system I have not properly reverse engineered yet, and if I don't know and understand exactly how it works, it's going to be hard to duplicate correctly.
  11. Can you check with something like Remote Process Viewer or dotFred (FDC) Task Manager exactly how many actual processes are running (not "applications" per se) ? If by apps you mean things from the start menu visible in 'normal' task managers, there are also around 8 or so system processes running at all times. That would make a total of 32. Note that WM6.x is based on CE5, which has a 32 task limit. System settings are generally DLLs loaded into one of the system's existing processes, and are thus not affected by this limit. If this is the case, it is a bug, though not in the way you might have thought - it means AutoClosePatch also prevents the system from shutting down apps when the process limit is reached.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.