Hi Michael,
there is no need to hardcode the messagebox output language to english.
In the resource files a string exists for what you're doing:
IDS_FINISHEDFIND (probably already loaded into a string in the code
somewhere).
Thanks,
Gregor
"Jan Blomqvist Kinander" <jan.blomqvist(a)reactos.org> wrote:
> Opening many sessions in windows is really bad idea ... for kernel stuff and another csrss, smss problems ... terminal server blue screen, black screen, printers, etc ... so i have an idea for a workaround ...
>
> Is open a session using createwinstation api ... in that session, create multiples desktops, using createdesktop api, in each desktop will be secure shell replacement, ejecuted using x user credentials (runas) ... the printing is gonna be universal virtual printers that receive the buffer from the win32, and send the emf or pdf to the client ...
>
Hi Jan & Gonzalo,
I'm no expert in this particular area, but don't You think it would be
more logical
to give each remote a winstation, and not just a desktop on a shared
winstation ?
Best Regards
// Love
Hi Developers, I have been aproached by a certain Gonzalo from Colombia, he claims to be a developer who wants to make a Terminal Server Clone, I enclose the mail he sent me, please have a look at it and answer him.
Yours Sincerely,
Jaix Bly
>>>
Hey Jaix, i'm Gonzalo from Colombia (South America) tecnologia(a)slmsistemas.net
I'm a coder, i develop more than 500 utils and apps for terminal server and citrix .... i have a product called Galeon that is a "clon" of terminal server with shell replacement, full duplex sound, universal printer driver, etc ...
I want to develop a Open Source Terminal Server based in something like VNC and OpenVPN
Opening many sessions in windows is really bad idea ... for kernel stuff and another csrss, smss problems ... terminal server blue screen, black screen, printers, etc ... so i have an idea for a workaround ...
Is open a session using createwinstation api ... in that session, create multiples desktops, using createdesktop api, in each desktop will be secure shell replacement, ejecuted using x user credentials (runas) ... the printing is gonna be universal virtual printers that receive the buffer from the win32, and send the emf or pdf to the client ...
Using Virtual Channels is a pain in the ass ... because they all travel using only one tcp socket ... (really bad idea) so, problems with video, audio, performance, etc ...i think we can use openvpn to connect to only one port (443 to ssl vpn) and after the vpn is connected, we can open many socket (each service) between the client and the server desktop ... so we can send printing, sound, video, etc ...
I have many things already developed ... createwinstation, createdesktop, impersonate users, universal printer, openvpn implementation .. etc ... but i need help in other areas, like the video grabber in the desktop (maybe a modified vnc) i can make a printscreen of each desktop, and send the jpg ... and is working, but is a really bad idea ...
This product can merge with ReactOS .. and be the ReactOS terminal server ...
https://sourceforge.net/projects/oswts/
What do you think?
Do you receive this mail?
Thanks,
Gonzalo.
--
Cordialmente:
Ing. Gonzalo Araujo C
MCSE, MCSA, MCSD, ITIL, CISSP, C|EH, LPI
Desarrollo SLM Sistemas Ltda
desarrollo(a)slmsistemas.com
tecnologia(a)slmsistemas.net
http://www.slmsistemas.com
Colombia - Guatemala - Chile - Venezuela
<<<
Hello! I already have almost latest trunk build of ReactOS installed.
Now I want to try
modifying some sources, but recompiling whole system takes about 8 hours
on my
very slow PC. How can I recompile only modified part of the system?
I am using RosBE for Linux version 1.5.
Hello,
as you all know we have quite a lot of regressions recently, and
recently they only add up to one another causing annoyances of
testers and developers. There is a strong need to change this
situation as soon as possible, otherwise the project's future is
undetermined.
I want to propose a step-by-step approach. Our brave testing team has
created a good overview of the most important regressions and bugs we
have so far: http://www.reactos.org/wiki/Buglist .
Now, very important(!):
For the first step I would like ALL developers to drop their current
ReactOS-related work, including all work in branches or wherever else
and focus ONLY on fixing regressions from that list. The goal is to
fix all confirmed regressions that have been introduced, starting
from the most recent and going down to the most ancient. All possible
ways to remove a regression could be used: starting from a proper fix
and finishing with a total revert or commenting out even good code.
Process coordination: feel free to commit proper fixes right away,
however as for reverts, I, and/or comittee of our core devs, would
like to have a final say on whether something should be reverted.
I repeat, all other non-regression related commits to the official
ReactOS SVN repository are forbidden, even to branches. The only
exception may be developers whose access is restricted to branches
only.
Thank you for understanding,
Aleksey Bragin.
Gregor Schneider <grschneider(a)gmail.com> wrote:
> Concerning using an internal format: let's assume we got three 8bpp
> surfaces (source, destination, pattern), which are quite big pending
> for a raster operation. You would convert these three to another
> format like 32bpp, process them and convert back?
No, of course not, Gregor,
You're absolutely right about the 8bpp S/D/P situation.
It would be a terrible idea to convert such a simple format to another
for a tertiary rop.
I think I was thinking about an internal graphic structure for the
display context .. ;-)
Accumulate all rops to an 32bit DIB internally, unless the physical
device is low bpp.
Come to think of it, almost anything but RLE is suitable internally,
depending
on the output color requirements. The graphics primitives for lines,
ellipses, and
so on can be small enough to separate a few specialized implementations for
different bit depths. I guess that's what You do ? (I didn't look yet).
Branching for different bit formats in the primitives would be a bad
idea though..
Wouldn't You agree ?
Best Regards
// Love
PS. I have a slice-line routine that's faster than an oiled lightning,
and it's really
small enough that it'd be worth replicating the code for different bit
depths.
Let me know if you're interested.
Hi guys,
Sorry for barging in on a discussion about code that's not on my desk,
but looking at your code there is something I want to point out.
Graphics code need to be *fast*, that's a primary consideration,
so I'm taken aback when I look at your inner bit expansion loop.
This is horrible from a standpoint of performance.
> length = (*bits++) >> shift;
> if (length)
> {
> c = *bits++;
> while (length--)
> {
> if (x >= width) break;
> temp = UncompressedBits + (((height - y) * Delta) + x);
> x++;
> *temp = c;
> }
> }
You're recomputing the start of the bit-run for every pixel you emit,
when you should move that calculation out of the inner loop to get
high performance. Graphics code is not the arena where you can be lazy
and hope that the optimizer will make your inefficient code faster.
At the very least You ought to write it something like this:
> length = (*bits++) >> shift;
> if (length)
> {
> c = *bits++;
> if (x + length > width) {
> // RLE encoding error - Bit-run exceeds width
> length = width - x;
> }
> temp = UncompressedBits + ((height - y) * Delta);
> x += length; // precompute finishing x
> while (length--)
> {
> *temp++ = c;
> }
> }
As a sideline note I'd like to mention that it's standard practice
in graphics libraries to use one unified bitmap format internally
to make internal processing like alpha-blend or text rendering or
whatever straight forward. The 32bit DIB format is quite suitable,
even if it uses the most memory - Graphics never was cheap on memory.
Just my penny to the pot
Best Regards
// Love