Changing the Logon Splash Screen bitmap

Does anybody know if/how this can be done?

TIA,
JohnO

BTW, the image is called signon.jpg, and it resides in the environment res directory. However altering it does not seem to have any effect.

I expect that it is compiled into oexplore.exe as a resource and that therefore there is no clean way of changing it :-(

JohnO

John,

I was never quite sure where these were stored but I tracked it down. The package install AVI file is dynamic and we used to replace it periodically in the old 10 MBit fat client days to entertain users while they were waiting. However the JDE login logo is stored as a resource in the JDEUSER.DLL. This DLL lives in the System\bin32 folder. You can also use a resource hacker program to manipulate the resources in the DLL. It's good fun.

Regards,

Hey, I hope you did not substitute anything too saucy for the AVI file - I know what sort of countries you have been working in and their "open minded" attitides!

But thanks for the tips on resource hacking jdeuser.dll - it worked a treat.

Next question: I did this on my client PC, but what is the best approach for getting a change to jdeuser.dll to deploy to out users in subsequent (full) packages?

Cheers,
JohnO

What tool did you use to hack the .DLL ?

Nope, not too saucy I have to admit I got the idea from a trainer at JDE 5 years ago. He had a 3 Stooges AVI playing while we waited for update packages to install.

To deploy the file you could put the hacked DLL into the System folder on the deployment server and then do a "recompress foundation" to get it into the SYSTEM.CAB. You would then deploy an update package. You should see your CNC gurus for this. However they will probably scoff at the idea. It would also need to be managed if you wanted to preserve the logo between service packs. You would need to hack each successive service pack. The CNC guy in me pretends that I did not say all that. But that IS how you would do it. You could also just copy the dll down via a login script. This would remove any impact on the deployment server. It would however go away on successive package installs.

Cheers,

resourcehacker. Google will find it.

Quite a handy tool. However as Justin points out, getting this hacked dll into a package and subsequent service packs is a pain. Plus PeopleSoft would presummably throw their hands in the air and cry "no support!" if they hear about this.

I can't believe such a fundemental sort of thing is so awkward/unsupportable in OneWorld!

Cheers,
JohnO

You can also use MS VC++ IDE (msdev.exe) for that.

I wouldn't assume that PSFT will not support this.

It's a normal and simple operation, which has nothing to do with hacking, especially when performed with a tool that PSFT explicitly supports - MS VC++.

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

Could I somehow bypass logon screen by using some shortcut or batch?

Thanks,
Yu

Yes, if you implement Unified Login. Perform a search on the JDELIST for "Unified Login" or "Unified Logon" to see details of my implementation last year.

True, I managed to use MSDEV to do this too, but it is a lot easier with RH.

PSFT support VC++ for compiling and maintaining business functions. They do not support users modifying their toolset.

In this context I'd say the term "hack" is appropriate as it is unauthorised, unapproved modifications to their code.

But I'm interested to see what they say about splash screens, so I'll enter a call on the KG an get back...

Cheers,
JohnO

It's actually not much different from changing the UDC text. I wouldn't cal this "changing the code" at any rate.

In many cases, it is the only way to translate or customize screen text. Compare this with changing the HTML pages used in OMW for news and such - technically, this would also constitute an unauthorised code change.

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

I'd have to plunder the statement... that since the JDE instructor(s) showed it to the students (and even discussed how to do it)... We should be able to get away with the statement that 'we were instructed by JDE authorized/trained instructors'???

I remember the instructor showing us how to do the 'hack' several years ago - and yes, the instructor had the three stooges.

db

"It's actually not much different from changing the UDC text."

Uh, I would draw a line between changing data and changing code.

Well, someone at Peoplesoft showing you how to do something doesn't make it supportable by PSFT.

Scenario:
Customer: "We cannot log into OneWorld, and the logon screen crashes with a memory fault"

PSFT: "Have you messed with the logon screen?"

Customer: "No, but we patched jdeuser.dll"

PSFT: "We cannot support your installation while it contains unsupportable modifications".

Customer: "But your instructor showed us how to do it!"

PSFT: "That does not make it supportable, but if you give us the intructor's name we'll fire him for you".

It's official from PSFT: modifying the images in jdeuser.dll is not supported. They already had raised SARs 5798525 and 5033194 over this issue but I wouldn't hold my breath.

They *do* support modifying the same image as used by the web platform.

Cheers,
JohnO

The image and resource strings are actually data, not code and changing them will not create memory faults.

In fact, changing business data via MS Access, for example, is much more likely to create problems (including GPF's) and is technically, not supported either.

I'd classify this as a matter of preference - it can be argued either way. Anybody who is comfortable doing this, can easily do it without any adverse effects.

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

Yeah, agreed resources are data, but they are contained in jdeuser.dll, i.e. code.

I agree with your points about hacking sql, semantics, and the fact that this will not itself corrupt the system.

But there is no escaping the fact that if something else goes wrong, and PSFT know you made an unsupported modification, then they no longer are obliged to support you. Further, I would never make an unsupported change without checking with my client first. No client I've ever had would authorise an unsupported change to to their enterprise-critical software.

Therefore, until PSFT support this, it is effectively a dead duck.

Cheers,
JohnO