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

Externalize non-engine related Hercules components #76

Open
4 of 17 tasks
Fish-Git opened this issue Dec 18, 2017 · 1 comment
Open
4 of 17 tasks

Externalize non-engine related Hercules components #76

Fish-Git opened this issue Dec 18, 2017 · 1 comment
Labels
Discussion Developers are invited to discuss a design change or solution to a coding problem. Enhancement This issue does not describe a problem but rather describes a suggested change or improvement. M Issue contains checklist of items, not all of which have been completed yet. Ongoing Issue is long-term. Variant of IN PROGRESS: it's being worked on but maybe not at this exact moment.

Comments

@Fish-Git
Copy link
Member

Fish-Git commented Dec 18, 2017 •
edited
Loading

More non-engine related Hercules components need to be externalized.

Some components are already externalized, such as Crypto, decNumber, SoftFloat and telnet, but many others still need to be done. I recently made significant changes to Hercules's Rexx support which should also have been externalized at that time but wasn't. Many other areas of Hercules need to be broken out and externalized (made into a separate External Package) as well. Those that spring to mind are:

  • Crypto
  • decNumber
  • SoftFloat
  • telnet
  • Rexx support
  • Message handling
  • Panel display
  • Command processing
  • Utilities
  • Config file processing
  • External GUI support
  • Device support
  • Channel subsystem
  • ZLIB support
  • BZIP2 support
  • PCRE support
  • Other?

The overall long term goal is to eventually reduce Hercules to just the "engine" responsible for all of the architectural emulation side of things. Everything else would be external to Hercules-proper. This allows new emulators to be more easily written by simply linking the existing Hercules engine with a different set of external components (as well as for each external component to "evolve" separately on their own).
@Fish-Git Fish-Git added the Enhancement This issue does not describe a problem but rather describes a suggested change or improvement. label Dec 18, 2017
@Fish-Git Fish-Git added M Issue contains checklist of items, not all of which have been completed yet. Ongoing Issue is long-term. Variant of IN PROGRESS: it's being worked on but maybe not at this exact moment. labels Dec 6, 2018
@Fish-Git Fish-Git mentioned this issue Mar 29, 2019
Merged
@Fish-Git Fish-Git added the Discussion Developers are invited to discuss a design change or solution to a coding problem. label Jul 20, 2019
@Fish-Git Fish-Git mentioned this issue Jul 20, 2019
Closed
@Fish-Git Fish-Git mentioned this issue Sep 22, 2019
Closed
@PoC-dev
Copy link

PoC-dev commented Jan 22, 2021

Maybe externalize the 3705 code as a separate project, being properly attached to Hercules via a CTC configuration?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Discussion Developers are invited to discuss a design change or solution to a coding problem. Enhancement This issue does not describe a problem but rather describes a suggested change or improvement. M Issue contains checklist of items, not all of which have been completed yet. Ongoing Issue is long-term. Variant of IN PROGRESS: it's being worked on but maybe not at this exact moment.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Fish-Git @PoC-dev