be300.org is dead :(

Sounds like you have nice friends. After more than 20 years of not having this, I think you owe them a beer!

Can we make a CAB installer that does all this and issue it as a single update?

Do you have any version of CeCreateDatabase_POOM.exe for any architecture? I imagine that all it is will be a hook to the localhost ODBC driver on CE that then issues a create database followed by a series of data structure definitions.

Edit: Yes, CeCreateDatabase is even the name of the WinCe fsdbase.dll hook used to create the database https://docs.microsoft.com/en-us/previous-versions/ms933221(v%3dmsdn.10)

If you can work out what the schema is (table names, field names, data types), it can be rebuilt


Edit 2: I found one in the DLC https://www.hpcfactor.com/support/cesd/s/0130.asp . Rich says there that GPSPassion user Osprey provided the BIN, it might be worth PMing him to see if he'll release the source and we can recompile it for everything else.

Gee, that sounds very familiar . . .

https://www.hpcfactor.com/forums/forums/thread-view.asp?tid=17269&posts=77&start=1



I should point out first that this will not work with BeShell, which uses its own substitute for boot.exe called BeLoader.exe (this is the value found instead of boot.exe in the startup queue in HKLM/init).

No luck so far with Pocket Informant. I've tried versions 3.0 and 4.5, but I'm getting an "illegal operation" error right after it opens. Maybe this app needs a real version of InkX.dll.

Exactly

If you dependency walk its exe, what does it have to say? InkX.dll seems to have something to do with ActiveSync Rich Ink. We might also need the CE3 versions of these DLLs.

I've been looking for the MIPS InkWriter package, which includes RichInk.dll, InkX.dll, and other related DLLs. Haven't tried applying Dependency Walker yet; let me check it out there.

I'll have to register as a new member on GpsPasSion to be able to message Osprey. Probably a longshot, since it doesn't look like Osprey has posted there for a while.

I'm not familiar with this, when was it released? You have it in other architectures?

It wasn't released as a standalone - it was part of the H/PC Pro and H/PC 2000 platforms. cmonex had the ARM version, which I assume was pulled from a ROM dump somewhere. Dunno if anyone did the same thing from a MIPS device. IIRC, no one was able to build a proper ROM dumper for MIPS, only a RAM dumper. And that was a long time ago.

InkX.dll is apparently needed by one of Pocket Informant.exe's dependencies included in the program: WebISUI.dll. Still checking it out.

I've been doing a little more experimenting with DispChg on the BE-500 in conjunction with PSBoot.exe on some OEs where booting into landscape mode had previously failed, to see if bypassing the wipe-and-reload sequence might bypass the failure to reload that would cause it to revert back to Top Menu from the 4 MB bootloader section of the ROM. The only success I had, though, was with EpodXPLE, which is less of a memory and ROM hog than the other versions of EpodXP due to taking out all the extra apps. It's a little unstable, but it does boot into landscape:





Attachments
----------------
EpodXPLE.JPG (11KB - 0 downloads)

After stripping out a ton of files, including all the Casio PIM files, Internet Explorer, and some big DLL files like wininet.dll, none of which were essential to the system and all of which could be accessed and/or run from the Storage Card, I was able to boot EpodXP 2.1 (which up until now I wasn't able to get to boot even in portrait mode on the BE-500) and convert it to landscape with PSBoot.exe enabled as well. (Moving IE to the Storage Card eliminates the possibility of Web browsing, since no one ever got WiFi working on the SanDisk ConnectPlus card, but IE is still a useful app for reading not only HTML files, but also Windows CE help files [.htc, .htp].) EpodXP 2.1 is a less stable OE even in its original form in the slightly-larger BE-300 memory, occasionally having trouble loading the desktop, but for the most part does what it's supposed to even after being scaled down to nearly barebones form in the slightly more cramped BE-500. (The more I'm using the landscape EpodXPLE above, BTW, the more stable it's proving to be. Unlike 2.1 it seems to survive a power loss. )

Bypassing the memory wipe with PSBoot.exe doesn't make DispChg work on the BE-300. It's still causing the display not to work on reboot after setting landscape mode. (I presumed that there must be some difference between the display driver on the BE-500 v the BE-300, and a check of ddi.dll on each one confirmed this: the BE-500 version is about 4 KB larger. However, that file is loaded from the inaccessible 4 MB part of the ROM, and therefore can't be copied.) That means, so far at least, if you want landscape mode on a BE-300, you'll either have to convert it to a BE-500 using the method I described earlier in this thread, or you'll have to try your luck with Nyditot Virtual Display or Jimmy Software's JS Landscape. (Based on going through archived forum posts in more than one old BE-300 site, it looks like a few users were successful with Nyditot, but I don't recall which OE they had on those devices, though I think it was reported to work in Bee on the BE-300. I tried JS Landscape on a BE-300, and while version 2 does rotate the display and can simulate multiple display resolutions like Nyditot, it doesn't allow proper stylus calibration, rendering it useless on this device. JS Landscape 3 doesn't work at all, preventing reboot and forcing a restore.)





Attachments
----------------
EpodXP21.JPG (11KB - 0 downloads)

I've succeeded in booting and converting to landscape more OEs on the BE-500 (EpodXP 1.5 and 1.4 and the original ePods core) after stripping out lots of files and applying PSBoot.exe. The only OE which doesn't seem to want to convert correctly to landscape is Bee. DispChg has no effect in version 1.x (including Cobalt) even though the applet opens and functions. As I've reported before, it has a rather bizarre effect on Bee 2.0 when landscape is enabled (and applying PSBoot.exe has no effect on this). Even GTshell (and Top Menu under it) as well as older versions of BeShell support landscape rotation on the BE-500 through DispChg, though they won't properly load 320x240 (landscape) desktop images nor adapt the taskbar (well, that I'll need to check further since those OEs' taskbars are based on WisBar).

At least I can't say I've had nothing to do while stuck at home.

All of this sounds like a huge amount of progress if you ask me. The BE-500 seems to be a fun little device, and in fact this whole thread kinda makes me want to own one too.

Edited by ShadowMaster 2020-05-20 9:59 PM

It really is fun to play with since you can customize the operating environment you want and save it as a backup file. (The BE-500 still shows up in Yahoo! Japan Auctions about as often as the BE-300 shows up here on eBay. There's a BE-500 with the shiny, sparkly black case up on Yahoo! Japan right now.) Getting the POOM databases to sync was a big boost (something the BE gurus never accomplished), but the part that sucks is that the device dumps the databases in the event of a power loss and as such they have to be backed up with a third-party utility to protect against this. Since the registry is persistent once flushed and survives power loss, and since using PSBoot.exe preserves unsaved files in RAM and unflushed registry changes, shouldn't there be a way to flush the databases to make them permanent just like registry changes?

Okay, so I figured out why DispChg wasn't having any effect on Bee Cobalt Edition on the BE-500. Executing the applet creates updated versions of ddi.dll, keybddr.dll, and touch.dll in the \Nand Disk\Program Files\Patch folder, but in Bee 1.x those files are not copied to \Windows like the applet expects them to. So the device is still using the native versions of those files, which don't accommodate display rotation. So I just added the file PatchCopy.exe (actually the Casio compressed file PatchCopy.exe.cpk), which is used by EpodXP to execute the copyover to \Windows, added it to the startup queue in HKLM/init, and lo and behold, I got landscape mode in Bee 1.0 and Cobalt. One other adjustment, though: I had to delete BeeBar.exe, yet another WisBar-based custom taskbar skinner that Bee automatically executes during startup, because it won't adapt to the longer taskbar in landscape (and actually interferes with the entire desktop adapting to landscape). As can be seen below, Bee 1.0 forwent creation of a Start button icon, so without BeeBar it looks kinda plain. (The wallpapers came with their respective OEs, but I had to adapt them from 240x320 to 320x240.)

There doesn't seem to be a cure, though, for the touchscreen calibration problems with Bee 2.0 when in landscape mode. Inserting PSBoot.exe into the process doesn't change at all the results I got from the very beginning using DispChg in this OE.







Attachments
----------------
Bee1.JPG (9KB - 0 downloads)
Cobalt.JPG (5KB - 0 downloads)

It appears that the only barrier to getting DispChg to work on the BE-300 is stopping the display from shutting off. In addition to creating the three files I mentioned above, the applet also creates a registry key in HKLM/Drivers/Casio called Landscape. I tried importing this key into a BE-300 with the values inside it corresponding to landscape display, and manually copied the above three files into the Patch folder, and then soft reset. It actually started booting in landscape before the display shut off after about a second. Holding down the power button shows the display again, but it's just the last thing displayed before it went dark. If the boot process continues any further, it doesn't show on the screen. (BTW, I was wrong about the difference in file size between the native versions of ddi.dll on the BE-300 v the BE-500: both are 84.5k in size. I must've been looking at an already-enabled BE-500 with the updated file, which is 92.5 in size.) If only I could figure out the factor that's differing between the two devices' display properties.

Glad to know you are figuring many things out.

It's interesting how many of BE-300 and BE-500 are the same, but not 100% equal.

Don't know that I've really learned much - I still don't know what functions most of the DLLs perform. And the results vary widely even between OEs that appear to have nearly identical file structures. It's fun getting things to work, but it'd be nicer to know why. And I'm not a programmer.