Hello, I'm the developper of ultracopier, I propose ultracopier as default copier under reactOS for the reactOS explorer. I will activly developpe it under reactOS. It based on Qt. Only the version 0.2.0.0 is developped for reactOS. Screenshot: http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
I'm pretty sure the people here don't really like frameworks like MFC, wxWidgets, or Qt. If you want it included in ReactOS, it probably will need to be rewritten to use standard Win32 API instead.
On Sun, Nov 1, 2009 at 2:17 PM, alpha_one_x86 < alpha_one_x86@first-world.info> wrote:
Hello, I'm the developper of ultracopier, I propose ultracopier as default copier under reactOS for the reactOS explorer. I will activly developpe it under reactOS. It based on Qt. Only the version 0.2.0.0 is developped for reactOS. Screenshot: http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
-- alpha_one_x86 alpha_one_x86@first-world.info Main developper of Ultracopier, Esourcing and server management IT, OS, technologies, security and business department
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I'm not able to do that's, but supercopier project is in win32 only. Is in coorperation with ultracopier for have same protocol. But ultracopier can by an good idea for have good copier for you explorer.
On Sunday 01 November 2009 22:12:23 King InuYasha wrote:
I'm pretty sure the people here don't really like frameworks like MFC, wxWidgets, or Qt. If you want it included in ReactOS, it probably will need to be rewritten to use standard Win32 API instead.
On Sun, Nov 1, 2009 at 2:17 PM, alpha_one_x86 <
alpha_one_x86@first-world.info> wrote:
Hello, I'm the developper of ultracopier, I propose ultracopier as default copier under reactOS for the reactOS explorer. I will activly developpe it under reactOS. It based on Qt. Only the version 0.2.0.0 is developped for reactOS. Screenshot: http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
-- alpha_one_x86 alpha_one_x86@first-world.info Main developper of Ultracopier, Esourcing and server management IT, OS, technologies, security and business department
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
Unfortunately we don't include apps which aren't part of the base operating system. However, you can help reactos by testing your apps on the operating system and reporting any bugs you may find.
Thanks, Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of alpha_one_x86 Sent: 01 November 2009 20:18 To: ros-dev@reactos.org Subject: [ros-dev] Integration of ultracopier to reactOS
Hello, I'm the developper of ultracopier, I propose ultracopier as default copier under reactOS for the reactOS explorer. I will activly developpe it under reactOS. It based on Qt. Only the version 0.2.0.0 is developped for reactOS. Screenshot: http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
The copy of file is base of OS, and your explorer haven't. Note: I have ReactOS crash when I copy folder in normal mode with ultracopier, but no crash in debug mode. The systray is invisible and unable to interface correctly with the reactOS via COM object like windows explorer. I have less bug on wine, and no bug under windows. Ultracopier note: I try adapte ultracopier 0.2.0.0
On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
Hi,
Unfortunately we don't include apps which aren't part of the base operating system. However, you can help reactos by testing your apps on the operating system and reporting any bugs you may find.
Thanks, Ged.
From an end user perspective I would be frustrated if every time I
wanted to copy a file, an over bloated file copy application was started, loading in a UI framework like QT to do it. Its unnecessary.
Reactos may be lacking now, because its alpha. That's not a reason to slap on a million-pound-gorilla app just to replace what will be a eventually be a standard integrated user32 (shell32?) dialog.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of alpha_one_x86 Sent: Monday, 2 November 2009 8:50 AM To: ReactOS Development List Subject: Re: [ros-dev] Integration of ultracopier to reactOS
The copy of file is base of OS, and your explorer haven't. Note: I have ReactOS crash when I copy folder in normal mode with ultracopier, but no crash in debug mode. The systray is invisible and unable to interface correctly with the reactOS via COM object like windows explorer. I have less bug on wine, and no bug under windows. Ultracopier note: I try adapte ultracopier 0.2.0.0
On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
Hi,
Unfortunately we don't include apps which aren't part of the base operating system. However, you can help reactos by testing your apps on the operating system and reporting any bugs you may find.
Thanks, Ged.
-- alpha_one_x86 alpha_one_x86@first-world.info Main developper of Ultracopier, Esourcing and server management IT, OS, technologies, security and business department
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
I partially disagree. The app might be bloated, but the idea is nice. The typical way of windows to copy files is sometimes very ineffective. There are many tools which try to be faster, especially if you copy several small files or on one hard driver with several partitions. The idea of these apps could be used by default in ROS IMO.
Andrew C schrieb:
From an end user perspective I would be frustrated if every time I wanted to copy a file, an over bloated file copy application was started, loading in a UI framework like QT to do it. Its unnecessary.
Reactos may be lacking now, because its alpha. That's not a reason to slap on a million-pound-gorilla app just to replace what will be a eventually be a standard integrated user32 (shell32?) dialog.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of alpha_one_x86 Sent: Monday, 2 November 2009 8:50 AM To: ReactOS Development List Subject: Re: [ros-dev] Integration of ultracopier to reactOS
The copy of file is base of OS, and your explorer haven't. Note: I have ReactOS crash when I copy folder in normal mode with ultracopier, but no crash in debug mode. The systray is invisible and unable to interface correctly with the reactOS via COM object like windows explorer. I have less bug on wine, and no bug under windows. Ultracopier note: I try adapte ultracopier 0.2.0.0
On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
Hi,
Unfortunately we don't include apps which aren't part of the base operating system. However, you can help reactos by testing your apps on the operating system and reporting any bugs you may find.
Thanks, Ged.
-- alpha_one_x86alpha_one_x86@first-world.info Main developper of Ultracopier, Esourcing and server management IT, OS, technologies, security and business department
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Lot of peaple ask real soft for do the copy. It's because soft like ultracopier, supercopier, teracopier, copyhandler exists. The target is that's will by 100% integrated and transparent to the end user (like firefox). The compatibility with ultracopier via the catchcopy protocol allow use other copier use in api win32 only and asure all copier (which repect the protocol) interpolability. And the style of Qt application is 100% transparent. The copy with copier like ultracopier boost the speed, allow better error management (resume/retry on error), pause, speed limitation, group the copy list for prevent lost of performance.
alpha_one_x86 schrieb:
Lot of peaple ask real soft for do the copy. It's because soft like ultracopier, supercopier, teracopier, copyhandler exists. The target is that's will by 100% integrated and transparent to the end user (like firefox). The compatibility with ultracopier via the catchcopy protocol allow use other copier use in api win32 only and asure all copier (which repect the protocol) interpolability. And the style of Qt application is 100% transparent. The copy with copier like ultracopier boost the speed, allow better error management (resume/retry on error), pause, speed limitation, group the copy list for prevent lost of performance.
Yes, as I said, the idea behind these apps is really great, but I fear we wont add a app which depends on a biiig runtime like QT in here. if it would be plain and fas C code, sure, why not. But QT increases RAM usage, slows down loading of the copy screen and makes ROS depend on it. I hope you understand my argument, we try to keep the OS small and adding QT is not the way we want to go. But maybe you can help us adding the used algorithms and features in our code. We really would appreciate this. Of course the code will be on GPL BSD or LGPL as you declare it and your name will be in there too.
On Sunday 01 November 2009 23:28:02 Daniel Reimer wrote:
I hope you understand my argument, we try to keep the OS small and adding QT is not the way we want to go. But maybe you can help us adding the used algorithms and features in our code. We really would appreciate this. Of course the code will be on GPL BSD or LGPL as you declare it and your name will be in there too.
Yes I understand your arguement. But adpate your explorer for support advanced copier can by usefull and depand of nothing. And the user which user ultracopier download it... And other more ligth can by easy added.
I can explain my algorithm, but I have not the skill and time for program it in api win32.
I thinks if lot of copier/explorer use the protocol enjoye the developper to do copie in various language. And maybe why not, include other copier in win32 pur like supercopier or copyhandler.
I don't know what's so nice about the idea, I've never had the need for a copy utility, explorer has always done a fine job for me. The only case where I had a need for something better was bulk renames, but our explorer could eventually integrate such functionality as well.
IMO there's absolutely no place for such a tool to be integrated in ROS.
Thomas Daniel Reimer wrote:
I partially disagree. The app might be bloated, but the idea is nice. The typical way of windows to copy files is sometimes very ineffective. There are many tools which try to be faster, especially if you copy several small files or on one hard driver with several partitions. The idea of these apps could be used by default in ROS IMO.
Andrew C schrieb:
From an end user perspective I would be frustrated if every time I wanted to copy a file, an over bloated file copy application was started, loading in a UI framework like QT to do it. Its unnecessary.
Reactos may be lacking now, because its alpha. That's not a reason to slap on a million-pound-gorilla app just to replace what will be a eventually be a standard integrated user32 (shell32?) dialog.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of alpha_one_x86 Sent: Monday, 2 November 2009 8:50 AM To: ReactOS Development List Subject: Re: [ros-dev] Integration of ultracopier to reactOS
The copy of file is base of OS, and your explorer haven't. Note: I have ReactOS crash when I copy folder in normal mode with ultracopier, but no crash in debug mode. The systray is invisible and unable to interface correctly with the reactOS via COM object like windows explorer. I have less bug on wine, and no bug under windows. Ultracopier note: I try adapte ultracopier 0.2.0.0
On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
Hi,
Unfortunately we don't include apps which aren't part of the base operating system. However, you can help reactos by testing your apps on the operating system and reporting any bugs you may find.
Thanks, Ged.
-- alpha_one_x86alpha_one_x86@first-world.info Main developper of Ultracopier, Esourcing and server management IT, OS, technologies, security and business department
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Except I doubt such functionality would ever get integrated for the simple reason that Windows doesn't have it. Only a few things ReactOS has that Windows didn't and it seems like those are disappearing soon (Read: virtual desktops).
On Sun, Nov 1, 2009 at 7:12 PM, Thomas Bluemel thomas@reactsoft.com wrote:
I don't know what's so nice about the idea, I've never had the need for a copy utility, explorer has always done a fine job for me. The only case where I had a need for something better was bulk renames, but our explorer could eventually integrate such functionality as well.
IMO there's absolutely no place for such a tool to be integrated in ROS.
Thomas Daniel Reimer wrote:
I partially disagree. The app might be bloated, but the idea is nice. The typical way of windows to copy files is sometimes very ineffective. There are many tools which try to be faster, especially if you copy several small files or on one hard driver with several partitions. The idea of these apps could be used by default in ROS IMO.
Andrew C schrieb:
From an end user perspective I would be frustrated if every time I wanted to copy a file, an over bloated file copy application was started, loading in a UI framework like QT to do it. Its unnecessary.
Reactos may be lacking now, because its alpha. That's not a reason to slap on a million-pound-gorilla app just to replace what will be a eventually be a standard integrated user32 (shell32?) dialog.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of alpha_one_x86 Sent: Monday, 2 November 2009 8:50 AM To: ReactOS Development List Subject: Re: [ros-dev] Integration of ultracopier to reactOS
The copy of file is base of OS, and your explorer haven't. Note: I have ReactOS crash when I copy folder in normal mode with ultracopier, but no crash in debug mode. The systray is invisible and unable to interface correctly with the reactOS via COM object like windows explorer. I have less bug on wine, and no bug under windows. Ultracopier note: I try adapte ultracopier 0.2.0.0
On Sunday 01 November 2009 22:30:17 Ged Murphy wrote:
Hi,
Unfortunately we don't include apps which aren't part of the base operating system. However, you can help reactos by testing your apps on the operating system and reporting any bugs you may find.
Thanks, Ged.
-- alpha_one_x86alpha_one_x86@first-world.info Main developper of Ultracopier, Esourcing and server management IT, OS, technologies, security and business department
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
King InuYasha wrote:
Except I doubt such functionality would ever get integrated for the simple reason that Windows doesn't have it. Only a few things ReactOS has that Windows didn't and it seems like those are disappearing soon (Read: virtual desktops).
I beg to disagree. Just because Microsoft sees fit to remove good functionality for whatever obscure reason, there's no reason ReactOS should do the same. Indeed just like we're not obliged to replicate the plethora of bugs in Windows. Or goal is (I hope) to create something that will eventually be better, in that sense, than Windows, as Microsoft has an annoying tendency to perpetuate their bugs!
Best Regards // Love
__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________
The message was checked by ESET Smart Security.
Thomas Bluemel wrote:
I don't know what's so nice about the idea, I've never had the need for a copy utility, explorer has always done a fine job for me.
Well for starters, Windows Explorer aborts the entire copy list as soon as it hits any little snag, instead of continuing with the rest of the files in the list. This behavior is of course totally unacceptable, but MS won't fix it.
I think ReactOS can do better, but not at the cost of pulling in Qt et.al. We should (naturally) use pure Win32 and native threads.
Rock on // Love
__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________
The message was checked by ESET Smart Security.
On Monday 02 November 2009 05:38:01 Love Nystrom wrote:
Well for starters, Windows Explorer aborts the entire copy list as soon as it hits any little snag, instead of continuing with the rest of the files in the list. This behavior is of course totally unacceptable, but MS won't fix it.
I think ReactOS can do better, but not at the cost of pulling in Qt et.al. We should (naturally) use pure Win32 and native threads.
I agrea with you. For example if intergration of software like supercopier it's 1MB more + 2KB on the explorer, but need wait respect the standard (both supercopier, and reactOS explorer)
alpha_one_x86 wrote:
On Monday 02 November 2009 05:38:01 Love Nystrom wrote:
Well for starters, Windows Explorer aborts the entire copy list as soon as it hits any little snag, instead of continuing with the rest of the files in the list. This behavior is of course totally unacceptable, but MS won't fix it.
I think ReactOS can do better, but not at the cost of pulling in Qt et.al. We should (naturally) use pure Win32 and native threads.
I agrea with you. For example if intergration of software like supercopier it's 1MB more + 2KB on the explorer, but need wait respect the standard (both supercopier, and reactOS explorer)
IMO a basic improvement can be achieved with even less. Just a change in the (Explorer) error handling during copying of multiple files. I.e continue copying instead of going belly up.
I feel like looking into it as soon as my new environment is ready, but anyone with "knowledge of the country" and a functioning setup is of course most welcome to beat me to it ;-)
Rock on // Love
__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________
The message was checked by ESET Smart Security.
On Mon, 02 Nov 2009, Love Nystrom wrote:
alpha_one_x86 wrote:
On Monday 02 November 2009 05:38:01 Love Nystrom wrote:
Well for starters, Windows Explorer aborts the entire copy list as soon as it hits any little snag, instead of continuing with the rest of the files in the list. This behavior is of course totally unacceptable, but MS won't fix it.
I think ReactOS can do better, but not at the cost of pulling in Qt et.al. We should (naturally) use pure Win32 and native threads.
I agrea with you. For example if intergration of software like supercopier it's 1MB more + 2KB on the explorer, but need wait respect the standard (both supercopier, and reactOS explorer)
IMO a basic improvement can be achieved with even less. Just a change in the (Explorer) error handling during copying of multiple files. I.e continue copying instead of going belly up.
I feel like looking into it as soon as my new environment is ready, but anyone with "knowledge of the country" and a functioning setup is of course most welcome to beat me to it ;-)
Isn't the NT code base supposed to have multi-queued IO? to stop such problems? At least that was the NT-zealots' boast during the NT-vs-OS/2 days in the early nineties.
Shouldn't the routine to copy hold another IO queue in hand "just in case", and hand the copying over to it as soon as it hits such a snag?
Mind you, I could think of additional uses for a multi-queued IO - having a anti-malware program kibitzing on the copying, and stalling anything that's questionable, while handing the copying over to Yet Another Copying IO Queue.
As has been said, there's no need to restrict ReactOS to Microsoft's lacks and lacksadaisicality.
just my 0.02c - don't spend it all at once!
Wesley Parish
Rock on // Love
__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________
The message was checked by ESET Smart Security.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Wesley Parish wrote:
Isn't the NT code base supposed to have multi-queued IO? to stop such problems? At least that was the NT-zealots' boast during the NT-vs-OS/2 days
I'd say it's one thing what the system has ability to do do, and another thing entirely what Explorer does with it. Not knowing it's source, I can only say "by the fruit shall the tree be known".
Shouldn't the routine to copy hold another IO queue in hand "just in case", and hand the copying over to it as soon as it hits such a snag?
Precisely. A fault list or whatever you want to call it. This could then be post-processed at the option of the user.
Mind you, I could think of additional uses for a multi-queued IO - having a anti-malware program kibitzing on the copying, and stalling anything that's questionable, while handing the copying over to Yet Another Copying IO Queue.
Bear in mind that there's an inherent danger in exposing the shell's file copying mechanism. While it may seem a convenient way to tie in a malware scanner, it could be used to conveniently inject a payload in every file the shell copies if a "plug-in" gets write access to the file data. Because of this risk any "plug-in" would have to be handed just a copy of the data, which would lead to terrible inefficiency due to all that redundant data copying.
Rock on // Love
Quoting Love Nystrom love.nystrom@gmail.com:
Wesley Parish wrote:
Isn't the NT code base supposed to have multi-queued IO? to stop such
problems? At least that was the NT-zealots' boast during the
NT-vs-OS/2 days
I'd say it's one thing what the system has ability to do do, and another
thing entirely what Explorer does with it. Not knowing it's source, I can only say "by the fruit shall the tree be known".
I'll have to re-read the ReactOS source. I've been doing a bit of thinking since last night, and I think I know where to begin.
Shouldn't the routine to copy hold another IO queue in hand "just in
case",
and hand the copying over to it as soon as it hits such a snag?
Precisely. A fault list or whatever you want to call it. This could then be post-processed at the option of the user.
Indeed. That would be very handy.
Mind you, I could think of additional uses for a multi-queued IO -
having a
anti-malware program kibitzing on the copying, and stalling anything
that's
questionable, while handing the copying over to Yet Another Copying IO
Queue.
Bear in mind that there's an inherent danger in exposing the shell's file copying mechanism. While it may seem a convenient way to tie in a malware scanner, it could
be used to conveniently inject a payload in every file the shell copies if a "plug-in" gets write access to the file data. Because of this risk any "plug-in" would have to be handed just a copy of the data, which would lead to terrible inefficiency due to all that redundant data copying.
The MS Windows Vista DRM vistabetion. After Longhorn, we had vistabeting. :) Little wonder Vista lost IO and went blind!
Little wonder Microsoft stopped giving such names.
I stand corrected. :)
Wesley Parish
Rock on // Love
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
"Sharpened hands are happy hands. "Brim the tinfall with mirthful bands" - A Deepness in the Sky, Vernor Vinge
"I me. Shape middled me. I would come out into hot!" I from the spicy that day was overcasked mockingly - it's a symbol of the other horizon. - emacs : meta x dissociated-press
As a result of this discussion I fetched the sources of both Ultra- and SuperCopier. I have made a very brief review of them and want to communicate my impression.
While the basic idea of both are attractive, neither can be easily integrated in ROS as-is because of their dependencies, Ultra depends on Qt, and Super is written in Pascal and depends on Borland's VCL. To complicate matters further both are written under the precept that they don't have access to the shell source code, and therefore must employ hooking methods to achieve the desired functionality. This is dead weight in the context of ROS.
A much simpler implementation will suffice, and it needs to be written in C or C++. I have not reviewed the relevant parts of the ROS Explorer source (I don't really know it's structure), but as I see it we're just in need of better error handling in Explorer. We need a copy-error list to keep track of faulted copy/move operations. When Explorer hits a snag, it should add the filepath and some flags to the list, and then commence with the rest of the files.
At the conclusion of the copy/move operations, the user should be notified, if necessary, with the list of faulted files, and given some options on action. For example, the files may be added to the boot-move list in SessionManager if they faulted because they where locked, and so on.
I would be happy to look into this myself, but unfortunately my ROS development environment is currently in a shambles after multiple system crashes and loss of code :-/ If someone with insight in Explorer's source feel like I do about the nasty behavior of dropping an entire batch because of one little snag, then please look into it. Then again, as this is not a priority matter, perhaps it can wait a while, and I'll do it later (I guess You're as occupied as I am).
Rock on // Love
__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________
The message was checked by ESET Smart Security.
Have you test copyhandler? It is do in c++ with visual.
Daniel Reimer wrote:
There are many tools which try to be faster, especially if you copy several small files or on one hard driver with several partitions.
I do believe you're thinking about xcopy. You didn't forget xcopy, did you ;-) It would perhaps be a good idea to integrate the concept of packing up small files in bigger blocks in memory before transfer and write, like xcopy does.
Rock on // Love
__________ Information from ESET Smart Security, version of virus signature database 4563 (20091101) __________
The message was checked by ESET Smart Security.