Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ReactOS

reactos.org

Post reply on HN
Print view View original

131–140 of 141 posts

Re: ReactOS

#131

Post by marttt »

jeditobe wrote: post #130
marttt wrote: post #117

Earlier quoted context omitted.

My goal is to get Avid Pro Tools 7 working on bare metal ROS. Partially successful attempts thus far: install is going smoothly, but the software doesn't launch. I get the nostalgic Blue Screen of Death and usually end up re-installing the entire OS. I assume it is a driver issue since PT of that era (2007-ish) requires a dedicated audio interface (the Mbox). But I need PT a few times a year, so I'll keep trying. I c…

Unfortunately, I was not able to find any bug-report related to the Avid Pro Tools 7 in the bug-tracker https://jira.reactos.org/ Filling a bug-report is the important first step to have your software working in ReactOS

True, I haven't filled a report yet; will look into this next time, probably when ROS 0.4.14 is released.

Pro Tools, at least in its early versions, tends to show its moods even on a well-tuned Windows system. So I was almost sure that it won't run in ROS out of the box. I was actually surprised to see it installing so smoothly. My guess is that the driver for the audio interface (Mbox 2) needs some attention.

Re: ReactOS

#132

Post by johnsoft »

russelg wrote: post #116
rnd0 wrote: post #50

Earlier quoted context omitted.

>I know of two specific examples of ReactOS code that as of a couple years ago were identical with Windows code. Cool; if they're specific then you ought to be able to cite them for the rest of us.

https://github.com/reactos/reactos/blob/59b78b4756da02e275e3... Is just one example.

A link to a random blob means nothing if it's not actually in the tree. Here's how that link was faked:

- https://news.ycombinator.com/item?id=10005577

- https://news.ycombinator.com/item?id=21025378

Re: ReactOS

#133

Post by CyberDildonics »

iainctduncan wrote: post #122
CyberDildonics wrote: post #14

Earlier quoted context omitted.

Does anyone try to shift audio mixing to the GPU and use the audio output of HDMI? I don't know if modern GPUs can take buffers and move them to the audio buffer without going out and back in through PCIe but it seems plausible.

I'm not sure, but that's a different issue. The latency problem with everything except linux is we can't tell the OS to elevate our audio apps priority above the rest of the kernel, so operating system calls randomly happen and jump in front of the audio callback, hosing latency. I used to get 0.7ms latency on linux with the CPU at over 90%!!! I'm lucky to get 7ms on OSX with the CPU at 30-40%ms, sigh. It sucks so ba…

That's the point though, if the GPU could be doing something uninterrupted the variance in scheduling wouldn't be as much of a factor.

Re: ReactOS

#134

Post by CyberDildonics »

WesolyKubeczek wrote: post #129
CyberDildonics wrote: post #14

Earlier quoted context omitted.

Does anyone try to shift audio mixing to the GPU and use the audio output of HDMI? I don't know if modern GPUs can take buffers and move them to the audio buffer without going out and back in through PCIe but it seems plausible.

Doesn't work like this. HDMI is a separate device; also, in a thread somewhere Paul Davis of Ardour fame explains how exactly infeasible it is. (And you won't be able to do "real time" on a GPU anyway if it's not graphics.) There's also more to audio than mixing (simple mixing was done on G3/G4, come on), when you take all the effects and filters, so to offload that reasonably you'd need an audio card with, say, an F…

> Doesn't work like this. HDMI is a separate device; also, in a thread somewhere Paul Davis of Ardour fame explains how exactly infeasible it is. (And you won't be able to do "real time" on a GPU anyway if it's not graphics.)

Why? HDMI comes from the graphics card with video and audio.

Also I'm pretty sure a graphics card can handle audio effects in real time. 44k samples per second per channel is going to take a lot less than running complex shaders on 240 million pixels per second.

Re: ReactOS

#135

Post by iainctduncan »

CyberDildonics wrote: post #133
iainctduncan wrote: post #122

Earlier quoted context omitted.

I'm not sure, but that's a different issue. The latency problem with everything except linux is we can't tell the OS to elevate our audio apps priority above the rest of the kernel, so operating system calls randomly happen and jump in front of the audio callback, hosing latency. I used to get 0.7ms latency on linux with the CPU at over 90%!!! I'm lucky to get 7ms on OSX with the CPU at 30-40%ms, sigh. It sucks so ba…

That's the point though, if the GPU could be doing something uninterrupted the variance in scheduling wouldn't be as much of a factor.

Well I'm no OS dev, so I will happily defer. But I was under the impression that this would not change the fact that a host audio app is running under user-space and can be pre-empted anytime? The way most pro-audio apps work is they have a callback they run once per audio vector size to fill a buffer of samples for the next buffer to pass to the audio subsystem. So if this gets knocked down the priority list, you get problems. Man I'd love to see any developments to improve that though, on an OS level we've been stalled for 20 FREAKING YEARS now. :-/

Re: ReactOS

#136

Post by babypuncher »

samatman wrote: post #114
babypuncher wrote: post #89

Earlier quoted context omitted.

The equation is different with video games, but I generally agree with you on everything else. There isn't much value in using Word Perfect 5.1 today beyond historical preservation.

My mother edited four or five academic books on Word Perfect 5.1, and the easiest way to generate offset copy for them would be to boot it up and print them again on an HP LaserJet 4000, just like last time. These will most likely never see another printing, granted. But generalizing across all books published this way, I'm sure this situation will actually arise in the future.

I think I wasn't very clear in my comment. I think that for things like Word Perfect 5.1, the better solution for longevity would be new open source software that recreates it's functionality in a non-hardware dependent manner. Your mother being able to open Word Perfect files in LibreOffice and print them out with the correct formatting on a modern printer would be easier (and more useful) than relying on the original hardware and software.

Re: ReactOS

#137

Post by kmeisthax »

sergeykish wrote: post #60
kmeisthax wrote: post #51

Earlier quoted context omitted.

We don't know. There are several substantiative questions of law and both parties' inability to give the court a clear picture of what an API is may result in the case not actually being decided. There's two questions up in the air with the case: 1. Whether or not you can claim copyright over the name of a function plus the combination of it's input types (an "API"). 2. Whether or not copying APIs can constitute fair…

> They were made public to other developers specifically so that they would write programs that used them. Same could be applied to any public interface. Header files, system calls, standard library, hardware version, language version, network interface. Linux and WINE replaces Windows entirely. Looks like a lot of fans wait exactly that, not ReactOS.

Right, but nobody is asserting an implied license claim (as far as I'm aware). The complaint is whether or not any API declaration bears copyright, and if so, whether or not you can make a fair use of such a declaration. They aren't arguing whether or not publishing said declarations implies copyright permission to use them. Granted, that would probably give the Supreme Court an easy out on this decision without having to throw out a lot of caselaw that seems to hint towards API copyright or suddenly reassign ownership of half the world's operating systems code to a handful of defunct holding companies.

Re: ReactOS

#138

Post by curtis3389 »

colinfinck wrote: post #91
curtis3389 wrote: post #40

Earlier quoted context omitted.

It's really saddening if you've been following the project for years. They had some good progress back when the Russian government got interested in ReactOS, but lately they seem to just be doing webdev stuff not directly related to improving ReactOS. To the ReactOS devs: what's the deal with the last couple years of GSOC projects? Why is there little to no work going on to improve compatibilty?

ReactOS dev here. As of today, compatibility is primarily hampered by the fact that many applications don't run under Windows XP anymore. We don't want to change the entire OS target to something newer than NT 5.2 (XP/Server 2003) at this point. Let's better stabilize on one target than chasing a moving target forever. This is why a versioning system is being implemented right now to allow applications targeting NT 6…

> Let's better stabilize on one target than chasing a moving target forever.

Fuck yeah! That's a solid engineering decision.

Thanks for the response and keep up the extremely impressive work!

Re: ReactOS

#139

Post by sergeykish »

kmeisthax wrote: post #137
sergeykish wrote: post #60

Earlier quoted context omitted.

> They were made public to other developers specifically so that they would write programs that used them. Same could be applied to any public interface. Header files, system calls, standard library, hardware version, language version, network interface. Linux and WINE replaces Windows entirely. Looks like a lot of fans wait exactly that, not ReactOS.

Right, but nobody is asserting an implied license claim (as far as I'm aware). The complaint is whether or not any API declaration bears copyright, and if so, whether or not you can make a fair use of such a declaration. They aren't arguing whether or not publishing said declarations implies copyright permission to use them. Granted, that would probably give the Supreme Court an easy out on this decision without havi…

API is mechanism, honestly I do not understand all that fuss.

Another API implementation is compatibility layer for authors who heavily invested in the platform. They are the reason platform is successful. Car dealerships investment is protected.

Re: ReactOS

#140

Post by Fnoord »

rnd0 wrote: post #69
unishark wrote: post #44

Earlier quoted context omitted.

I think virtual machines are the best way to keep old software around. I have one for 32 bit stuff that's over 15 years old and making something of a comeback. Personally I'd be more interested in ReactOS as a way to run current software without microsoft, as I think they have really started behaving unacceptably with windows 10.

>I think virtual machines are the best way to keep old software around. You're not wrong. However I think that the appeal of ReactOS (in part, and if it was more stable) is that it's currently updated and (in theory) can be secured against modern threats; so you'd be able to put it on a network -which would be masochistic to do with Server 2003 at this point. I could also be modified to run modern Firefox, chrome, et…

Your post seems to assume networking with internet connection is required by the user. Not necessarily the case.

If a company buys a red team test, a Windows XP machine without networking has a different threat model than one with.

Also, Wine on Linux might be better option if its just one incompatible application (with or without networking).

In short I would say both (or rather, all three) have their place.

Post reply on HN