Thread cleanup aisle 6.
Quick cleanup which is all I have time for during my break so if I butchered something that's why.
Best way to ignore is not to respond.

sharangad wrote on 2024-04-03, 16:11:

Dosbox rendition will function without RReady as dosbox. It just can't run rendition games. You can pretty much play or run anything else.

When running Rendition games, dosbox streams the raw data meant for a Verité board over the pipe and accepts keyboard +mouse from the other end. In all other respects it functions as a regular dosbox.

That's not what it sounded like:

sharangad wrote on 2024-04-03, 14:49:

Redline.dll and verite.dll would actually become part of dosbox and it wouldn't function without them. They would become part of it.

It sounds like these aren't your DLLs and were part of some driver. In any case if they're a dependency they need to be open source, as does anything else they depend on. Also ideally they would not strictly be windows-specific libraries - if people see a product labelled as "DOSBox" they expect to be able to use it the same way and on the same platforms as DOSBox.

Dosbox can use draw.dll or direct3d or opengl.
All those is non gpl, closed source products.
Is it means it broke gpl?

Than dosbox which wants to access verite.dll and rredline.dll should not broke gpl, and dosbo-rendition should be open-sourced, bu dll dependencies can be closed source.
Want those dll's? Run dosbox in win98 machine. This is fun made fork as compatibility layer for win98.
Or this dosbox-rendition project is for upcoming open source wrapper, which actually planned but never got realized.

Still not clear to me.
Those hell licenses kills creativity at my sight at my pov

Anyway getting away from licenses to human beings, how one can receive payment for his painful hard work?

Understanding it for myself is very useful, as I am planning to touch other API in future.
And surely I will face all that issues.

RaVeN-05 wrote on 2024-04-03, 18:15:

Dosbox can use draw.dll or direct3d or opengl.
All those is non gpl, closed source products.
Is it means it broke gpl?

No.
GPL isn't a "law" that can be broken. It's a licence, stating how a product can be used, stated by the person who created it. The people who created DOSBox aren't bound by it, they can do whatever they like (including using any dependencies that allow GPL products, such as operating system libraries). When other people come along and want to modify DOSBox - that's when the GPL comes into play.

Than dosbox which wants to access verite.dll and rredline.dll should not broke gpl, and dosbo-rendition should be open-sourced, bu dll dependencies can be closed source.

No, because DOSBox is explicitly GPL. Meaning requirements must be met if you want to use it. Moving closed source dependencies into separate DLLs or processes is not sufficient.

Anyway getting away from licenses to human beings, how one can receive payment for his painful hard work?

If you are going to incorporate other people's work you must abide by the restrictions they place on its use. Otherwise create everything yourself.

@jcmarch

Dosbox-Rendition doesn't have any dependencies on redline.dll or verite.dll. Period. Full stop. Exclaimation Mark! All it needs is the usual sdl2.dll (I think).

I built it to run without any dependencies on anything else and it can run by itself. No RReady no glide wrappers or anything else (apart from SDL).

My fellow Vogons (@robert and @Raven) were suggesting I embed redline.dll and verite.dll as required components of dosbox.

That line you quoted from me was me trying to explain to them that that wasn't allowed. Does that make sense?

It would be useful if you followed the entire thread instead of misquoting random bits out of context to justify your point.

I 100% agree with you. No closed source library or exe can be embedded in a GPL 2.0 app. Dosbox-Rendition does no such thing and I can supply you with a current build if you want to very it for yourself. The next git commit is due soon and you should be able go through the code.

If you want to keep hammering your point about licensing could you create another thread for it? I created this one to ask for help with developement.

RaVeN-05 wrote on 2024-04-03, 18:15:

Dosbox can use draw.dll or direct3d or opengl.
...
Than dosbox which wants to access verite.dll and rredline.dll should not broke gpl, and dosbo-rendition should be open-sourced, bu dll dependencies can be closed source.

Thanks for your support, but:

Ddraw, opengl32 an d3d are system dlls. GPL 2.0 has an exception for OS compoents. Redline and verite haven't been system dlls for over 20 years. I don't think you could legitimately argue that they're system dlls on Win10/11. They were on Win98.

The way closed source 3dfx wrappers worked was via through a named pipe, which is a Windows specific version of a socket or socket like comms channel. Dosbox-Rendition works the same way.

An upshot of this is that closed source 3dfx wrappers (or Rendition ones) cannot render into the dosbxox window (because that violates shared process space, it's writing to dosbox video memory). The best they can do is loosely communicate with (this is important) *a very simple* protocol.

GPL 3.0 is even worse. Even named pipe connections aren't allowed. Dosbox is licensed under GPL 2.0.

sharangad wrote on 2024-04-03, 19:41:

If you want to keep hammering your point about licensing could you create another thread for it? I created this one to ask for help with developement.

The opening post of this thread is you asking if what you're trying to do is permitted. As a contributor to DOSBox (i.e. a current rights-holder of the some of the code), I am telling you: no, what you have proposed is not compliant with the GPL.

Running the closed source code in a separate process doesn't make it any less of a dependency, and including what appears to be a dumped proprietary ROM as a binary blob is definitely a no-no. Although I fully expect that now that I've pointed it out, you'll move that into the closed source portion so it isn't as obvious.

RaVeN-05, I was wondering if you have any win vista/7/8/10/11 pc with pci slots to check if the card works there 😀
though i guess a pcie->pci adapter may be enough too, though you may not have such a thing 😉

jmarsh wrote on 2024-04-03, 20:22:

sharangad wrote on 2024-04-03, 19:41:

If you want to keep hammering your point about licensing could you create another thread for it? I created this one to ask for help with developement.

The opening post of this thread is you asking if what you're trying to do is permitted. As a contributor to DOSBox (i.e. a current rights-holder of the some of the code), I am telling you: no, what you have proposed is not compliant with the GPL.

Running the closed source code in a separate process doesn't make it any less of a dependency, and including what appears to be a dumped proprietary ROM as a binary blob is definitely a no-no. Although I fully expect that now that I've pointed it out, you'll move that into the closed source portion so it isn't as obvious.

That ROM's going to go out of existence and replaced with a manufactured one.

jmarsh wrote on 2024-04-03, 20:22:

The opening post of this thread is you asking if what you're trying to do is permitted. As a contributor to DOSBox (i.e. a current rights-holder of the some of the code), I am telling you: no, what you have proposed is not compliant with the GPL.

Which version of the GPL? There's more than one 1.0, 2.0 or 3.0?

They have different rules. As far as I'm aware Dosbox runs on GPL 2.0.

sharangad wrote on 2024-04-03, 20:26:

Which version of the GPL? There's more than one 1.0, 2.0 or 3.0?

They have different rules. As far as I'm aware Dosbox runs on GPL 2.0.

You really want to get this deep into the weeds? Here's the relevant portion straight from the GPL 2.0 FAQ, the bolded sections are what apply in this case:

When are a program and its plug-ins considered a single combined program? […]
Show full quote

When are a program and its plug-ins considered a single combined program?

It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.
If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

You are communicating over a named pipe using defined structures (headers followed by data), even before you've added some sort of feedback mechanism for user input, which qualifies as "intimate communication".

The GPL really isn't complicated, except when people want to try weaseling out of complying with it...

That definitely does look the GPL blocks it but then you have this:
https://www.gnu.org/licenses/old-licenses/gpl … 0legal%20issues

1"Can I write free software that uses nonfree libraries?
2If you do this, your program won't be fully usable in a free environment. If your program depends on a nonfree library to do a certain job, it cannot do that job in the Free World. If it depends on a nonfree library to run at all, it cannot be part of a free operating system such as GNU; it is entirely off limits to the Free World.
3So please consider: can you find a way to get the job done without using this library? Can you write a free replacement for that library?
4
5If the program is already written using the nonfree library, perhaps it is too late to change the decision. You may as well release the program as it stands, rather than not release it. But please mention in the README that the need for the nonfree library is a drawback, and suggest the task of changing the program so that it does the same job without the nonfree library. Please suggest that anyone who thinks of doing substantial further work on the program first free it from dependence on the nonfree library.
6
7Note that there may also be legal issues with combining certain nonfree libraries with GPL-covered Free Software. Please see the question on GPL software with GPL-incompatible libraries for more information."

OR maybe not. Even if I don't distribute it I'm still going to build it. And that ROM BIOS is going to be replaced byan ID string, which I was too lazy to extract.

That does not apply; you are not writing free software. You are modifying somebody else's work and are bound by the existing licence. You don't get to choose to release the program "as is" because it already exists.

jmarsh wrote on 2024-04-03, 21:12:

That does not apply; you are not writing free software. You are modifying somebody else's work and are bound by the existing licence. You don't get to choose to release the program "as is" because it already exists.

How does dgvoodoo operate? That's closed source and it works with dosbox.

jmarsh wrote on 2024-04-03, 20:45:

It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program.

just wondering here:
dosbox pc is only shipping data to gfx plugin, (gfx plugin is not shipping any data to dosbox pc)
so it is shipping forth, only forth, not back and forth
it is shipping not sharing
result: quoted rule not met

other thing is whether we can consider 30 year old game graphics data as complex data structures now

And to avoid intimacy, modify input to be asynced, being intercepted by background, much like joysticks handlers, you can use joystick while window is not active.

The rendition card can be used in windows 10 without rredline API, after win10 installs standart vga drivers, you can use virtualization software with PCI True access option, which leads you can use all APIs provided by card to be used.

I really doubt rendition drivers could be installed on 32bit oses. Maybe on xp?

Rewriting drivers? Oh no, rare hardware, even Rendition Heritage newly made video cards is not mass.

Speaking of newly made things?
They also broke any kind of license(s)?
Is really there still nerds who cares about legality of 30 years old stuff, funny.

No offence, I really need to understand all those for future, as I don't understand all those licenses, I am from Ukraine, no anyone I saw here even understand importance of all that. And as silly gamer I never read or care about that long books of gpl tales. =)

With love to you all, I repeat I don't understand, explain more deeply and detaily.

EDIT: OK, did this product can be funded by Kickstart or patreon or donations?

@Ripsaw-8080, if it's not too much trouble:

What's the easiest way to intercept a 32 bit call instruction to specific addresses? I need to handle protected mode entry points to certain real mode Int calls.

[EDIT] Nm, figured it out.