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.

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

Porting woes: INITENV was originally paragraph-aligned already #96

Open
ecm-pushbx opened this issue Aug 19, 2024 · 5 comments
Open

Porting woes: INITENV was originally paragraph-aligned already #96

ecm-pushbx opened this issue Aug 19, 2024 · 5 comments

Comments

@ecm-pushbx
Copy link

The main change in a9adbbf just undoes what f4e868e#diff-52bbf87db189a4af9f24037eb12b3b9563a54bfc343b81073ad25c86fbf9f5dcL111 did!

@boeckmann
Copy link
Collaborator

Yes, wondering why it was not implicitly para-aligned by the previous definition in BIOSGRPS. There it is para-aligned. And this should have propagated to the INITENV in the genercfg.asm.

@boeckmann
Copy link
Collaborator

Btw @ecm-pushbx do you think we can safely remove the 256 byte patch area filled by NOP? To my understanding, we can simply rebuild the kernel if there is something to patch?

@ecm-pushbx
Copy link
Author

I assume you mean

and
patch_area dw 0666h
?

I don't know what exactly this was intended for. You're of the opinion it is for hot patching existing kernel files, to ease this sort of patch? If that is indeed the only use then yeah I'd say drop it.

@boeckmann
Copy link
Collaborator

Exactly, found no other reference to it in the source, so I assume this is for hot patching. But I am not 100% sure. Who knows what legacy DOS program could depend on this?

@ecm-pushbx
Copy link
Author

It is no more than 512 Bytes, maybe less (not sure whether the bio patch is init only area or resident). So I'd rather be careful for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants