Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hercules just ends without completing processing config file on Windows 11 #642

Closed
davekreiss opened this issue Mar 10, 2024 · 44 comments
Closed

Hercules just ends without completing processing config file on Windows 11 #642

davekreiss opened this issue Mar 10, 2024 · 44 comments
Labels
(Invalid/PEBKAC) Likely user error. The described problem does not exist or was otherwise determined to be bogus.

Comments

@davekreiss
Copy link

davekreiss commented Mar 10, 2024 •
edited by Fish-Git
Loading

I have run Hercules on my Windows 11 laptop for quite some time successfully, and in the past had no problems running multiple versions of Hercules.

Suddenly -- after not having run Hercules for some time on this laptop -- multiple versions of Hercules just terminate in the same way. That is, after issuing message:

HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3 and 4

Simply being back to the command prompt. If I run with >somelogfile.log on command line, there is nothing in that file.

I have included two examples:

  1. Example1.txt   HC01413I Hercules version 4.7.0.11001-SDL-DEV-g40fb2a2f-modified  (from a current TK5 install)

  2. Example2.txt   HHC01413I Hercules version 4.6.0.10941-SDL-g65c97fd6

I know recently I uninstalled some unused "apps" but don't recall which ones. I am suspicious this is cause but don't know how to identify which piece of uninstalled software might be related. I have made a rookie attempt to examine events logs on Windows with no clue if any entry was related.
@davekreiss davekreiss changed the title Hercules just ends without reading config file on WIndows 11 Hercules just ends without completing processing config file on WIndows 11 Mar 10, 2024
@Fish-Git Fish-Git changed the title Hercules just ends without completing processing config file on WIndows 11 Hercules just ends without completing processing config file on Windows 11 Mar 10, 2024
@wrljet
Copy link
Member

wrljet commented Mar 10, 2024

Dave,

Can you zip and post your config(s) here.

Bill

@Fish-Git
Copy link
Member

Fish-Git commented Mar 11, 2024 •
edited
Loading

  1. Example1.txt   HC01413I Hercules version 4.7.0.11001-SDL-DEV-g40fb2a2f-modified

That version was a private, TEMPORARY, TEST version of Hercules that I personally built for you by myself, back on July 13, 2023:

HC01413I Hercules version 4.7.0.11001-SDL-DEV-g40fb2a2f-modified
HHC01415I Build date: Jul 13 2023 at 03:42:37
HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)

which, according to your own email to me, ran just fine for you (except for an unexpected bogus debugging message, totally unrelated to your current problem, that I had included in it).

So whatever your current problem is, it's VERY LIKELY NOT a Hercules problem. It's much more likely IMHO to be a Windows-11 problem.

 

2. Example2.txt   HHC01413I Hercules version 4.6.0.10941-SDL-g65c97fd6  (from a current TK5 install)

which is the stock official 4.6.0 release version of Hercules, in general availability for the past 9 months, which no one has ever reported the behavior you're currently reporting.

I also find it highly suspicious that both completely different versions of Hercules would both decide to:

  1. Write a complete screen's worth of messages to the panel (where else did you copy the messages from in your two Example1.txt and Example2.txt documents?).
  2. Decide to exit back to the command prompt at the same place during execution.

 

CONCLUSION:

Your problem -- whatever it is -- is very likely not a Hercules problem. It is either a problem with the way you are running Hercules (i.e. using batch files or other non-standard means to start Hercules that is preventing a log file from being created, etc), or else something Microsoft has done to Windows 11 that has somehow broken things on your system. I seem to recall seeing in the news a while back that they were working on a new, fancy-schmancy Terminal (Command Prompt) program that supported multiple sessions and other sh*t that no one probably needs. Maybe they snuck that into your Windows?

In any, I don't believe this is a Hercules issue. It MIGHT perhaps be a TK5 issue, I don't know. I do know TK likes to do all kinds of weird sh*t before actually launching Hercules (has no one heard K.I.S.S.?!). But more than likely it's a Windows 11 problem.

But it's NOT a Hercules problem.

I am closing this issue as "(Invalid/PEBKAC)".

If you and Bill want to continue working on this problem, that's fine with me. You can continue working on it and posting comments to this GitHub Issue even after it has been closed. But I'm not going to waste my time with it. Sorry!

@Fish-Git Fish-Git added the (Invalid/PEBKAC) Likely user error. The described problem does not exist or was otherwise determined to be bogus. label Mar 11, 2024
@wrljet
Copy link
Member

wrljet commented Mar 11, 2024 •
edited by Fish-Git
Loading

I don't want to. I was just trying to be nice.  :)

@Fish-Git
Copy link
Member

Fish-Git commented Mar 11, 2024 •
edited
Loading

Another possibility:

It could also be a bad install of Rexx.

After reviewing my own Hercules log files (I have literally HUNDREDS and HUNDREDS of them), I happened to notice that the Hercules messages that are normally issued immediately after your reported "last" message (HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3 and 4) are the messages related to Rexx:

14:19:30.583 HHC01413I Hercules version 4.7.0.11119-SDL-gf7d2360a
14:19:30.583 HHC01414I (C) Copyright 1999-2024 by Roger Bowler, Jan Jaeger, and others
14:19:30.583 HHC01417I ** The SDL 4.x Hyperion version of Hercules **
14:19:30.583 HHC01415I Build date: Mar  9 2024 at 20:27:46
14:19:30.584 HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)
14:19:30.584 HHC01417I Build type: Windows MSVC AMD64 host architecture build
14:19:30.584 HHC01417I Modes: S/370 ESA/390 z/Arch
14:19:30.584 HHC01417I Max CPU Engines: 64
14:19:30.585 HHC01417I Using   shared libraries
14:19:30.585 HHC01417I Using   Fish threads Threading Model
14:19:30.585 HHC01417I Using   Error-Checking Mutex Locking Model
14:19:30.585 HHC01417I With    Shared Devices support
14:19:30.585 HHC01417I With    Dynamic loading support
14:19:30.586 HHC01417I With    External GUI support
14:19:30.586 HHC01417I With    Partial TCP keepalive support
14:19:30.586 HHC01417I With    IPV6 support
14:19:30.586 HHC01417I With    HTTP Server support
14:19:30.586 HHC01417I With    sqrtl support
14:19:30.586 HHC01417I With    Signal handling
14:19:30.586 HHC01417I With    Watchdog monitoring
14:19:30.586 HHC01417I With    CCKD BZIP2 support
14:19:30.586 HHC01417I With    HET BZIP2 support
14:19:30.586 HHC01417I With    ZLIB support
14:19:30.586 HHC01417I With    Regular Expressions support
14:19:30.586 HHC01417I With    Object REXX support
14:19:30.586 HHC01417I Without Regina REXX support
14:19:30.587 HHC01417I With    Automatic Operator support
14:19:30.587 HHC01417I Without National Language Support
14:19:30.587 HHC01417I With    CCKD64 Support
14:19:30.587 HHC01417I With    Transactional-Execution Facility support
14:19:30.587 HHC01417I With    "Optimized" instructions
14:19:30.587 HHC01417I With    OPTION_USE_SKAIP_AS_LOCK
14:19:30.587 HHC01417I With    OPTION_SIE2BK_FLD_COPY
14:19:30.587 HHC01417I With    OPTION_IODELAY_KLUDGE
14:19:30.587 HHC01417I With    OPTION_MVS_TELNET_WORKAROUND
14:19:30.587 HHC01417I With    OPTION_SIE_PURGE_DAT_ALWAYS
14:19:30.587 HHC01417I With    OPTION_NOASYNC_SF_CMDS
14:19:30.587 HHC01417I Machine dependent assists: cmpxchg1 cmpxchg4 cmpxchg8 cmpxchg16 hatomics=msvcIntrinsics
14:19:30.587 HHC01417I Running on: WIN7 (Windows 7 Ultimate-6.1.7601 Intel(R) x64) LP=8, Cores=8, CPUs=2
14:19:30.587 HHC01417I Built with crypto external package version 1.0.0.52-ga5096e5
14:19:30.587 HHC01417I Built with decNumber external package version 3.68.0.102-g3aa2f45
14:19:30.587 HHC01417I Built with SoftFloat external package version 3.5.0.105-g4b0c326
14:19:30.587 HHC01417I Built with telnet external package version 1.0.0.63-g729f0b6
14:19:30.588 HHC00100I Thread id 000021fc, prio 5, name 'impl_thread' started
14:19:30.588 HHC00100I Thread id 00003f80, prio 4, name 'logger_thread' started
14:19:30.588 HHC00018I Hercules is running in elevated mode
14:19:30.588 HHC02323W This build of Hercules has only partial TCP keepalive support
14:19:30.588 HHC00007I Previous message from function 'impl' at impl.c(1313)
14:19:30.592 HHC00150I Crypto module loaded (C) Copyright 2003-2016 by Bernard van der Helm
14:19:30.592 HHC00151I Activated facility: Message Security Assist
14:19:30.592 HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3 and 4

14:19:30.618 HHC17528I REXX(OORexx) VERSION: REXX-ooRexx_4.2.0(MT)_64-bit 6.04 22 Feb 2014
14:19:30.618 HHC17529I REXX(OORexx) SOURCE:  WindowsNT
14:19:30.618 HHC17525I REXX(OORexx) Rexx has been started/enabled
14:19:30.619 HHC17500I REXX(OORexx) Mode            : Subroutine
14:19:30.619 HHC17500I REXX(OORexx) MsgLevel        : Off
14:19:30.619 HHC17500I REXX(OORexx) MsgPrefix       : Off
14:19:30.619 HHC17500I REXX(OORexx) ErrPrefix       : Off
14:19:30.619 HHC17500I REXX(OORexx) Resolver        : On
14:19:30.619 HHC17500I REXX(OORexx) SysPath    (49) : On
14:19:30.619 HHC17500I REXX(OORexx) RexxPath   ( 0) :
14:19:30.619 HHC17500I REXX(OORexx) Extensions ( 8) : .REXX;.rexx;.REX;.rex;.CMD;.cmd;.RX;.rx
14:19:30.620 HHC02204I ARCHLVL        set to z/Arch
14:19:30.621 HHC02204I LPARNAME       set to HERCULES
14:19:30.621 HHC02204I LPARNUM        set to 1
14:19:30.621 HHC02204I CPUMODEL       set to 3931
14:19:30.621 HHC02204I CPUSERIAL      set to 111111
14:19:30.621 HHC02204I CPUVERID       set to 03
14:19:30.621 HHC02204I MODEL          set to hardware(EMULATOR) capacity(EMULATOR) perm() temp()
14:19:30.621 HHC02204I MANUFACTURER   set to HRC
14:19:30.621 HHC02204I PLANT          set to ZZ
14:19:30.621 HHC02204I MAXCPU         set to 1
14:19:30.622 HHC00111I Thread CPU Time IS available (_POSIX_THREAD_CPUTIME=1)
14:19:30.622 HHC00100I Thread id 0000301c, prio 2, name 'Processor CP00' started
14:19:30.622 HHC00100I Thread id 00003e74, prio 7, name 'timer_thread' started
. . .

Maybe your Rexx installation is f**ked? Maybe if you re-install it? (Or uninstall it first and then install it again?)

I just find it slightly suspicious that Hercules would choose to exit back to the command line at that specific point in its startup sequence.

Just a thought.  :)

@Fish-Git
Copy link
Member

I don't want to. I was just trying to be nice.  :)

Well you know me!  ;-)

@wrljet
Copy link
Member

wrljet commented Mar 11, 2024 •
edited by Fish-Git
Loading

I don't want to. I was just trying to be nice. :)

Well you know me! ;-)

That's why you keep me around.

@Fish-Git
Copy link
Member

Fish-Git commented Mar 11, 2024 •
edited
Loading

I don't want to. I was just trying to be nice. :)

Well you know me! ;-)

That's why you keep me around.

Well... I don't keep you around. It's not like I'm some boss or anything, that can fire people. It's you yourself that decides to stick around.  :)

And for that I am VERY appreciative!

After all, it's not like anyone else on the team is doing much contributing.  :-(

Maybe I'm paranoid or insecure, but I sometimes wonder whether it's because of me. Maybe I'm just rubbing people the wrong way?  :(

I hope not!  Because if that is the reason, then I'll leave in a heartbeat for the good of Hercules!

But I sometimes wonder that. It seemed years ago the team was much more active. Each member being more actively involved. These days however. not so much (except for you of course).

That kind of bothers/worries me.  :(

@davekreiss
Copy link
Author

davekreiss commented Mar 11, 2024 via email •
edited by Fish-Git
Loading

@wrljet
Copy link
Member

wrljet commented Mar 11, 2024

Not trying to be a pain but back to your suspicions wasn't it Hercules' code that terminated rather abruptly with no signs of what happened??? Maybe some trace if available (or can be built in) might help?

We'll do whatever we can to figure it out.

@wrljet
Copy link
Member

wrljet commented Mar 11, 2024

OK, so there's a lot in those logs.

I see some mismatch of versions. Hard to follow and keep straight.

There's a locally built (Hercules-Helper build Aethra) Hercules in C:\hercules\aethra\msvc.AMD64.bin\

And I see Hercules DASD in C:/PROGRA~1/hercules
(Not sure how any Hercules got in Program Files)

What happens if you run?

C:\hercules\aethra\msvc.AMD64.bin\hercules --version

and

C:\hercules\aethra\msvc.AMD64.bin\hercules -f C:\hercules\aethra\hercules.cnf

@davekreiss
Copy link
Author

davekreiss commented Mar 12, 2024 via email •
edited by Fish-Git
Loading

@Fish-Git
Copy link
Member

Fish-Git commented Mar 12, 2024 •
edited
Loading

General FYI regarding email replies:

I would very much appreciate it if you would not respond/reply to GitHub Issues via email.

I would much prefer that you instead respond/reply directly via the GitHub Issues web page itself:

When you reply directly via their web page, I can make minor edits to your reply so it is more readable (prettier) by editing the fonts being used, formatting of log messages, etc.

When you reply via email however, I cannot edit your reply (GitHub does not allow it), so oftentimes it is much harder (more difficult) to read.

GitHub also does not allow attachments in their email replies either, making it impossible to receive a file that may have been requested from you.

It is up to you whether or not you want to take the time to reply via their web page or continue to reply via email, but it is generally preferable that you reply directly via their web page instead. Especially if you need to attach a file that was requested from you.

Thanks for understanding.

@wrljet
Copy link
Member

wrljet commented Mar 12, 2024

Dave,

OK, let's try something.

Download this SDL Debug Build

Unzip that someplace. Start a Command Prompt, change to that directory and run both these:

hercules --version

and

hercules -f hercules.cnf

Report back what you get.

Bill

@davekreiss
Copy link
Author

Bil,

Received the error 0x0150002 with both commands. Here is screen shot of DOS window and error message.
Screenshot 2024-03-12 170730

Dave

@wrljet
Copy link
Member

wrljet commented Mar 12, 2024

(If I were talking directly to Fish, I'd be swearing now.)

OK, I noticed in your logs above, that you had Visual Studio 2017 installed at some point?
Is that still the case?

If so I'll rebuild with that and resend.

Bill

@Fish-Git
Copy link
Member

Bill, (@wrljet)

The problem is not how you built Hercules (well, it kind of sort of is). It's being caused by the fact that it's a Debug build, which requires the user to have to the Debug version of Microsoft's VC runtime (and other Debug build related components), which unfortunately is/are not legally redistributable.

When I try running it on my own Windows 7 system, I get:

image

When I try running it on my Windows 10 VMware system. I get both of the below:

image
image

Note:  ucrtbased.dll is a Debug version of the ucrtbase.dll.

I've never heard of ucrtbase.dll (or ucrtbased.dll) before, but I'm guessing it's something new that Microsoft is doing in their later version of Visual Studio. (in which version they introduced it, I don't know.)

You might check Visual Studio documentation to see if maybe you can build Hercules without requiring ucrtbase.dll be present on the user's system. It might be a build build option, I don't know. Or it might be a new requirement, I don't know that either.

But unless the user has Visual Studio installed on their system, they will never be able to run a Debug build of Hercules (or any other program for that matter) due to the missing "Debug" version of Visual Studio's VC runtime dlls. And as I said, they are NOT legally redistributable, so you can't send it to them or upload them somewhere for them to download, without getting into a whole hornets nest of legal trouble with Microsoft.

The only way for the user to legally get it, is for them to actually install Visual Studio themselves. Then and only then should they then have legal copies of the Debug version of the VC runtimes.

Hope that helps!

@wrljet
Copy link
Member

wrljet commented Mar 14, 2024

Fish, yes I understand all that.
Based on one of the logs, I assumed Dave had a Visual Studio installed as it was a Hercules-Helper build.

Waiting to hear back if that is true, and what version.

Bill

@Fish-Git
Copy link
Member

Fish-Git commented Mar 14, 2024 •
edited
Loading

Fish, yes I understand all that.

Good. I wasn't sure, so I thought I should mention it anyway, just in case.

When I'm working on a problem with someone, it has been my habit to not presume (assume) the other party knows about (is aware of) certain things. If they do, no harm is done. But if they don't and I don't mention it (presuming that they already know about it), it can cause problems. So over the years I've gotten in the habit of presuming the person I'm talking to is an unknowledgeable/unskilled individual. For safety.

Most of the time the other person understands this and is not offended by that.

Sometimes however, the other person becomes offended. "I know that! What do you think I am? An idiot?! Sheesh!"

It's rare, but it does happen. It happened to me once a very long time ago and took me quite by surprise. Luckily it hasn't happened since, so I'm glad you weren't offended by my mentioning it.

I'll leave you guys alone now. Good luck with your effort!

@davekreiss
Copy link
Author

davekreiss commented Mar 15, 2024 •
edited by Fish-Git
Loading

bill,
Looks like I have Visual Studio 2107, 2022 and 2022 Preview.
Dave
image

@wrljet
Copy link
Member

wrljet commented Mar 15, 2024

For what it's worth I have reproduced the original issue of Hercules simply exiting.

... developing ...

@davekreiss
Copy link
Author

Bill
Great at least I feel a little less “Invalid/PEBKAC” but suspect it is going to turn out to be user error anyway.
Thanks Dave

@wrljet
Copy link
Member

wrljet commented Mar 15, 2024

Definitely NOT user error!

I've been cussing MSFT most of the day.

@wrljet
Copy link
Member

wrljet commented Mar 15, 2024 •
edited by Fish-Git
Loading

Dave,

Please give these a try:

(Fish, I don't believe these won't work on Windows 7)

Bill

@davekreiss
Copy link
Author

davekreiss commented Mar 15, 2024 •
edited by Fish-Git
Loading

Bill,
So, I just tried my TK5 IPL before seeing your post and it succeeded. There were some Windows 11 updates this week and there were updates to Visual studio 2017, 2022 and 2022 preview. Unluckily I had started Hercules with log output without log redirection so start up sequence rolled off. IPLing TK5 with a redirecting log shows we get right past the point of failure. From the TK5 IPL:

18:04:10 HHC00100I Thread id 00005358, prio 5, name 'impl_thread' started
18:04:10 HHC00100I Thread id 000053f0, prio 4, name 'logger_thread' started
18:04:10 HHC01413I Hercules version 4.6.0.10941-SDL-g65c97fd6
18:04:10 HHC01414I (C) Copyright 1999-2023 by Roger Bowler, Jan Jaeger, and others
18:04:10 HHC01417I ** The SDL 4.x Hyperion version of Hercules **
18:04:10 HHC01415I Build date: Jun  8 2023 at 15:48:12
18:04:10 HHC01413I Hercules version 4.6.0.10941-SDL-g65c97fd6
18:04:10 HHC01414I (C) Copyright 1999-2023 by Roger Bowler, Jan Jaeger, and others
18:04:10 HHC01417I ** The SDL 4.x Hyperion version of Hercules **
18:04:10 HHC01415I Build date: Jun  8 2023 at 15:48:12
18:04:10 HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)
18:04:10 HHC01417I Build type: Windows MSVC AMD64 host architecture build

18:04:10 HHC00151I Activated facility: Message Security Assist
18:04:10 HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3 and 4
18:04:10 HHC17528I REXX(OORexx) VERSION: REXX-ooRexx_4.2.0(MT)_64-bit 6.04 22 Feb 2014
18:04:10 HHC17529I REXX(OORexx) SOURCE:  WindowsNT
18:04:10 HHC17525I REXX(OORexx) Rexx has been started/enabled
18:04:10 HHC17500I REXX(OORexx) Mode            : Command

Ok following the directions with your build produces this:

C:\TK5\TK5>cd "C:\Users\Dave\Downloads\Debug Hercules\msvc.debug.AMD64.bin

C:\Users\Dave\Downloads\Debug Hercules\msvc.debug.AMD64.bin> hercules --version
version.c(811)    HHC01413I Hercules version 4.8.0.11121-SDL-DEV-gfef7a85e3-modified
version.c(811)    HHC01414I (C) Copyright 1999-2024 by Roger Bowler, Jan Jaeger, and others
version.c(811)    HHC01417I *** Hercules-Helper Special Test Build ***
version.c(811)    HHC01415I Build date: Mar 15 2024 at 18:29:28

C:\Users\Dave\Downloads\Debug Hercules\msvc.debug.AMD64.bin>hercules -f hercules.cnf
impl.c(2021)      HHC02342S Configuration file 'hercules.cnf' not found: No such file or directory
version.c(811)    HHC01413I Hercules version 4.8.0.11121-SDL-DEV-gfef7a85e3-modified
version.c(811)    HHC01414I (C) Copyright 1999-2024 by Roger Bowler, Jan Jaeger, and others
version.c(811)    HHC01417I *** Hercules-Helper Special Test Build ***
version.c(811)    HHC01415I Build date: Mar 15 2024 at 18:29:28
impl.c(794)       HHC01407S Usage: hercules [--help[=SHORT|LONG|VERSION|BUILD]] -f config-filename|"none" [-o logfile-name] [-r rcfile-name] [-d] [-b logo-filename] [-s sym=val] [-t [factor]] [-p dyn-load-dir] [[-l dynmod-to-load]...] [> logfile]
impl.c(1208)      HHC02343S Terminating due to 1 argument errors
hscmisc.c(1484)   HHC01420I Begin Hercules shutdown
hscmisc.c(1516)   HHC01423I Calling termination routines
hdl.c(680)        HHC01500I HDL: begin shutdown sequence
hdl.c(704)        HHC01504I HDL: shutdown sequence complete
HHC01424I All termination routines complete
HHC01425I Hercules shutdown complete
HHC01412I Hercules terminated

C:\Users\Dave\Downloads\Debug Hercules\msvc.debug.AMD64.bin>

So, I was sure I rebooted multiple times including trying to diagnose the issue, so I went to \Windows\Prefetch\ReadyBoot\ and see this which I think identifies the last few Windows boots (where is todays?). By the way I never sleep or hibernate Windows I shutdown each time I am done.

03/08/2024  09:24 PM         2,790,787 Trace5.fx - I think this reboot was my attempt to fix problem before reporting.
03/11/2024  09:50 PM         2,774,494 Trace6.fx
03/11/2024  10:05 PM         2,820,603 Trace7.fx
03/14/2024  08:50 PM         2,800,135 Trace8.fx - This was first Windows update reboot.
03/14/2024  09:03 PM         2,329,407 Trace9.fx - This was a subsequent Windows update reboot.

Anyway, whatever it was no longer exists. Windows updates? Not sure what I can do now with a functioning Windows system to diagnose further.

Dave

@wrljet
Copy link
Member

wrljet commented Mar 15, 2024

Did your TK5 included Hercules work before all this? There's too much going on here and I can no longer keep it straight.

OK, so my -f hercules.cnf instructions were no good. You'll have to point the -f to existing config.

But the fact the --version worked, that worked around the problem where you got the 0x0150002 error.

There is definitely an issue here, which I have reproduced myself, and it's not fixed by any MSFT updates.
(in fact, I suspect it's caused by some update somewhere along the way)

TK5 is not a DEBUG build. The one I sent is.

You see the the difference because the lines often show the C source code filename and line number that generated it.

For example; hscmisc.c(1484) HHC01420I Begin Hercules shutdown

The issue with DEBUG builds if the way Hercules is created on Windows it generates a so-called manifest, which for reasons I have yet to figure out ALWAYS thinks vc90.crt DLL is required. This is present in most normal modern Windowses, but the DEBUG version of that is only there if VS2008 is installed.

What I just sent you rips all the manifest out.

Editorial: Punchline for me, that manifest stuff is not needed and is causing problems with more modern Windowes and the side-by-side DLL reservoir. Nobody except Fish is using Windows 7 anymore and it's time we cut that loose.

Bill

@davekreiss
Copy link
Author

davekreiss commented Mar 15, 2024 •
edited by Fish-Git
Loading

Bill

All of the original attempts reported earlier trying to run Hercules with various versions all failed at message HHC00151I so never got to the point of IPL command.

Sorry for not using your version of Hercules with TK5. Here is that log. I didn't actually IPL but did get to the that point in startup.

Dave

@wrljet
Copy link
Member

wrljet commented Mar 16, 2024

OK, so that shows it runs "at all" and is not related to the missing DLLs problem.

Nothing jumps out at me, appears wrong there. Fish might have a more discerning eye.

Bill

@Fish-Git
Copy link
Member

Fish-Git commented Mar 16, 2024 •
edited
Loading

The issue with DEBUG builds if the way Hercules is created on Windows it generates a so-called manifest, which for reasons I have yet to figure out ALWAYS thinks vc90.crt DLL is required. This is present in most normal modern Windowses, but the DEBUG version of that is only there if VS2008 is installed.

What I just sent you rips all the manifest out.

Editorial: Punchline for me, that manifest stuff is not needed and is causing problems with more modern Windowes and the side-by-side DLL reservoir. Nobody except Fish is using Windows 7 anymore and it's time we cut that loose.

It looks like Microsoft MAY? have an unfixed bug in whatever version of Visual Studio you are using to build Hercules with, that may be confusing whatever version of Windows Dave is using.

I manually copied (did not remove! just copied!) the manifest that my VS2008 embeds into each binary (I chose hengine.dll just for fun, but it shouldn't matter; they're all the same) and placed it into a text file.

Then I did the same thing for your binaries as well (except your manifests weren't in your binaries since you had already ripped them all out into their own separate .manifest file), and then compared the two with each other.

The results were quite eye opening:

My VS2008

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.21022.8" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Bill's (VS20nn?)

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
</assembly>

Here's the .htm report:

As you can plainly see, it appears Microsoft's manifest is malformed. It's missing both </requestedExecutionLevel> and </assemblyIdentity>.

Now it might still be okay. I don't know. I do see where VS20nn is inserting a <?xml ... statement, whereas VS2008 does not. I also notice that requestedExecutionLevel and assemblyIdentity both end with /> in the VS20nn version, whereas VS2008's end with just > and then has a </... end-of-block statement immediately following it. So maybe their new manifest format is actually valid and okay? I don't know. This might be a red herring.

But it's obvious they're different, and since you claim the problem seems to be manifest related, I thought I'd pass along my analysis to see what you think of it.

Problem? Yes? No?

As far as your wanting to drop support for Windows 7 and/or VS2008 (True? That is what you're suggesting? Yes?) goes, my response would be, "Oh HELL fucking no!"

Now I would have no problem with making, say, Windows 10 or Windows 11 be our preferred (default) build platform, as long as we didn't purposely break/remove our existing Windows 7 VS2008 support.

And if my VS2008 builds of Hercules are causing problems with users running Windows 10 or Windows 11, then I would have no problem with building our official release binaries using a more modern version of Visual Studio such as VS2022 instead. But I most definitely DON'T want to permanently drop support for VS2008 and/or Windows 7.

Change our default handling? Sure! No problem.

Drop Windows 7 and VS2008 support entirely? HELL FUCKING NO!

But then, my voice only counts as one voice too, and there are others on this team besides me and you. If the others feel that's the direction we should take Hercules in, then so be it. I guess I'll have to live with it.

I obviously won't like it very much. But it's not like I'm going to go out and jump off a bridge over the decision either. I'll be pissed, sure. But I'll live.

@wrljet
Copy link
Member

wrljet commented Mar 16, 2024

... developing ...

Spent hours cussing this stuff today.

@Fish-Git
Copy link
Member

Fish-Git commented Mar 16, 2024 •
edited
Loading

Spent hours cussing this stuff today.

I'm sorry to hear that. Have you been able to conclusively determine (in your professional opinion) that it's the embedded manifest that's causing the problem?

@wrljet
Copy link
Member

wrljet commented Mar 16, 2024

Fish, like I mentioned above ... developing ...
I don't yet know why a VS2017/2022 would be referencing VC90 runtime DLL in the manifests.

The DLLs themselves, don't refer to that import.

Bill

@Fish-Git
Copy link
Member

I don't yet know why a VS2017/2022 would be referencing VC90 runtime DLL in the manifests.

I think it might be just a switch? Just a way of triggering the use of the debug version of the CRT? I never understood the VC90 crap either.

@wrljet
Copy link
Member

wrljet commented Mar 16, 2024

Fish, I just don't know -- yet.

Definitely something's "up".

@ARandham
Copy link

I don't yet know why a VS2017/2022 would be referencing VC90 runtime DLL in the manifests.

I'm pretty sure it's because the included EXTPKGS are still VS2008 versions. The instructions in README.EXTPKG to build and then include them in the LIB and INCLUDE environment variables don't appear to work as intended.
I just overwrite the cloned external packages with the ones built with ExtPkgs.cmd, and no more VC90.

Andrew

@Fish-Git
Copy link
Member

I'm pretty sure it's because the included EXTPKGS are still VS2008 versions.

(Doh!)  Of course. I don't know why I hadn't thought of that before. Good catch, ARandham! Thank you!

The instructions in README.EXTPKG to build and then include them in the LIB and INCLUDE environment variables don't appear to work as intended.

They don't? What part is wrong?

I just overwrite the cloned external packages with the ones built with ExtPkgs.cmd, and no more VC90.

You "overwrite the cloned external packages"? What are you talking about? Cloning each of the External Packages doesn't (that I'm aware of!) provide you with any LIB files. You have to run the ExtPkgs.cmd to create the needed LIB files. Yes?

Let me try building Hercules with VS2022 but without building any of the External Packages (thus causing Hercules to link with its default pre-supplied external package LIB files from the Hercules repository (which I believe were built using VS2008)). I think maybe that might be where things are going wrong? Hercules is being built with VS2022 but linking with external package LIB files that were built with VS2008?

Give me a few minutes and I'll report back here with my results...

@ARandham
Copy link

ARandham commented May 23, 2024 •
edited
Loading

I'm pretty sure it's because the included EXTPKGS are still VS2008 versions.

(Doh!) Of course. I don't know why I hadn't thought of that before. Good catch, ARandham! Thank you!

The instructions in README.EXTPKG to build and then include them in the LIB and INCLUDE environment variables don't appear to work as intended.

They don't? What part is wrong?

When using the Build Solution or Rebuild Solution from within the Visual Studio GUI (I have 2019 and 2022) , the LIB variable is not picked up. It looks like the LIB is set to the Library Directories specified in the Project Properties (VC ++ Directories). Running Makefile.bat from a command window or using Hercules Helper (which launches a command window) picks up the LIB variable as intended.

I just overwrite the cloned external packages with the ones built with ExtPkgs.cmd, and no more VC90.

You "overwrite the cloned external packages"? What are you talking about? Cloning each of the External Packages doesn't (that I'm aware of!) provide you with any LIB files. You have to run the ExtPkgs.cmd to create the needed LIB files. Yes?

Correct, what I meant is I overwrite the LIB files which are included in the cloned SDL-Hercules file system with those generated by ExtPkgs.cmd.

Let me try building Hercules with VS2022 but without building any of the External Packages (thus causing Hercules to link with its default pre-supplied external package LIB files from the Hercules repository (which I believe were built using VS2008)). I think maybe that might be where things are going wrong? Hercules is being built with VS2022 but linking with external package LIB files that were built with VS2008?

Give me a few minutes and I'll report back here with my results...

@Fish-Git
Copy link
Member

Let me try building Hercules with VS2022 but without building any of the External Packages (thus causing Hercules to link with its default pre-supplied external package LIB files from the Hercules repository (which I believe were built using VS2008)). I think maybe that might be where things are going wrong? Hercules is being built with VS2022 but linking with external package LIB files that were built with VS2008?

Give me a few minutes and I'll report back here with my results...

Well, I renamed my extpkgs directory (where the external packages LIB and INCLUDE directories existed) and removed the directory from both my LIB environment variable as well as my INCLUDE environment variable (so that there was no way in hell that Visual Studio could find them, thereby forcing it to use the INCLUDE files from the Hercules repository, and link with the LIB files provided in the Hercules repository), and ... it worked fine. Hercules did not fail. It started up just fine. It did not just suddenly exit like originally reported.

So I'm unfortunately still just as confused as I originally was when this GitHub Issue was first created.  :(

Bill? How the heck did you manage to recreate the problem?

@ARandham
Copy link

ARandham commented May 23, 2024 •
edited by Fish-Git
Loading

DEBUG-X64 should fail almost immediately. Which Configuration did you try with?

Perhaps also related to your version of Windows? Mine is Win10 Pro 22H2 and it has a newer version of the MSVC 2008 Runtime installed.

@Fish-Git
Copy link
Member

When using the Build Solution or Rebuild Solution from within the Visual Studio GUI (I have 2019 and 2022) , the LIB variable is not picked up. It looks like the LIB is set to the Library Directories specified in the Project Properties (VC ++ Directories).

Ah! Yes. Know problem with later versions of Visual Studio. IMHO it's a bug, but Microsoft refuses to admit that it is, and thus refuses to fix it. To fix the problem you need to manually add $(LIB) and $(INCLUDE) to Visual Studios's directories.

Running Makefile.bat from a command window or using Hercules Helper (which launches a command window) picks up the LIB variable as intended.

Correct.

And since doing a Build Solution or Rebuild Solution from Visual Studio should automatically invoke makefile.bat, the previously mentioned Visual Studio Library Directories bug should not have any impact at all.

What Visual Studio Configuration are you building? It should be the Release/x64 configuration. If you're not building the Release/x64 configuration, then THAT is what your problem is.

@ARandham
Copy link

ARandham commented May 23, 2024 •
edited
Loading

When using the Build Solution or Rebuild Solution from within the Visual Studio GUI (I have 2019 and 2022) , the LIB variable is not picked up. It looks like the LIB is set to the Library Directories specified in the Project Properties (VC ++ Directories).

Ah! Yes. Know problem with later versions of Visual Studio. IMHO it's a bug, but Microsoft refuses to admit that it is, and thus refuses to fix it. To fix the problem you need to manually add $(LIB) and $(INCLUDE) to Visual Studios's directories.

Running Makefile.bat from a command window or using Hercules Helper (which launches a command window) picks up the LIB variable as intended.

Correct.

And since doing a Build Solution or Rebuild Solution from Visual Studio should automatically invoke makefile.bat, the previously mentioned Visual Studio Library Directories bug should not have any impact at all.

Well, it does have an impact, the resulting BuildLog lists the PATH, LIB and INCLUDE directories, and extpgks\lib is not there..

What Visual Studio Configuration are you building? It should be the Release/x64 configuration. If you're not building the Release/x64 configuration, then THAT is what your problem is.

I'm building Release/x64 and Debug/x64 from Visual Studio. In both cases, "Microsoft.VC90.CRT" is in the manifest file for hengine.dll.

@Fish-Git
Copy link
Member

Fish-Git commented May 23, 2024 •
edited
Loading

And since doing a Build Solution or Rebuild Solution from Visual Studio should automatically invoke makefile.bat, the previously mentioned Visual Studio Library Directories bug should not have any impact at all.

Well, it does have an impact, the resulting BuildLog lists the PATH, LIB and INCLUDE directories, and extpgks\lib is not there..

Did you add your extpkgs\include and extpkgs\lib directories to both your INCLUDE and LIB environment variables before building Hercules, as instructed in README.EXTPKG document? Because if you did, they should be there!

(And remember, with Windows (ever since WIndows 8?), you need to logoff and logon again (or reboot) whenever you change your environment variables)

@Fish-Git
Copy link
Member

Fish-Git commented May 23, 2024 •
edited
Loading

I'm building Release/x64 and Debug/x64 from Visual Studio. In both cases, "Microsoft.VC90.CRT" is in the manifest file for hengine.dll.

Which is almost certainly being caused by the fact that your Hercules is being linked with the default external package .lib files in Hercules's repository directories (which were indeed built with VS2008) instead of with your VS2022 built external packages .lib files, because your LIB environment variable was not updated to include that directory (as evidenced by your own admission of their not appearing anywhere in your BuildLog).

@ARandham
Copy link

ARandham commented May 23, 2024 •
edited by Fish-Git
Loading

Yes, the configuration was done correctly and the machine was rebooted. Running a SET from a command window lists the LIB variable with the correct library paths. It's still not in the Buildlog, so Visual Studio must be resetting that prior to executing the makefile?

Anyway, as you pointed out above, I added '$(LIB)' to the Visual Studio directories. '$(INCLUDE)' was already defined. The Rebuild Solution executed and picked up the external packages from the correct location and is also listed in the Buildlog. Thanks for that!

As to the original problem, I'll leave that to your expertise. My debug/x64 build with the default extpkgs is failing because I don't have VS2008 installed and the debug libraries are not included in the 2008 redistributable.

@Fish-Git
Copy link
Member

Fish-Git commented May 23, 2024 •
edited
Loading

Yes, the configuration was done correctly and the machine was rebooted. Running a SET from a command window lists the LIB variable with the correct library paths. It's still not in the Buildlog, so Visual Studio must be resetting that prior to executing the makefile?

Okay, that sounds like a serious bug in Visual Studio then!  >:-(

Visual Studio should NOT be resetting already defined environment variables! Especially not for LIB! (or INCLUDE!) It may update the LIB variable (add directories to the beginning, end or middle of the LIB variable's list of search directories (But never delete any of course!)), but it should certainly not be resetting (replacing!) the value that is already defined!

Both the the LIB and INCLUDE environment variables are integral to any build process (software development), so if Visual Studio is not honoring their settings, then that IMHO is a serious bug in Visual Studio!

Anyway, as you pointed out above, I added '$(LIB)' to the Visual Studio directories. [...] The Rebuild Solution executed and picked up the external packages from the correct location and is also listed in the BuildLog. Thanks for that!

You're very welcome. I hope Bill can begin to see now why I'm sticking with Windows 7 and Visual Studio 2008!  ;-)

(Windows has been going downhill for the last several versions now. It's both sad and incredibly infuriating!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
(Invalid/PEBKAC) Likely user error. The described problem does not exist or was otherwise determined to be bogus.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Fish-Git @wrljet @davekreiss @ARandham