기 타 pecmd.exe WimLib BR 에 진행바를 적용하여 보았습니다

78RePack에 있는 진행바가 있어서 개인적은 생각으로는 좋은(?) 소스라는 생각에 WimLib BR에 활용을 하였습니다

좋은(?) 이렇게 표현한데는 이유가 있습니다

생각하고 현실은 전혀 다르다는것을 깨달았습니다

 

wimlib-imagex.exe 프로그램으로 최적화를 할때에는..%를 읽어 오는 pecdm.exe로 된 런처가 cup 사용률이 높지 않습니다

cpu의 대부분을 최적화를 하는 wimlib-imagex.exe에서 차지 합니다

그런데..최적화할때와 백업, 복원시의 명령어가 달라서인지..백업시에는 런처에서 그나마 cup를 차지 하는 비율이 높지 않아서 cmd로

백업 할때보다는 느리지만 그래도 봐줄만합니다

 

복원시가 문제입니다..cmd로 복원 하는 경우 % 값을 표시하는 작업이 없어서 cup의 대부분을 wimlib-imagex.exe에서 차지하여서 복원

작업이 잘 진행이 됩니다

그런데 pecmd.exe에서 %를 보여주는 경우 복원시에 cpu의 대부분을 런처가 차지하고 복원 작업에는 할당량이 적습니다

주객이 전도되어서 복원 시간이 한참 걸립니다..복원을 주로 차지하고 적용 cup 사용량으로 %를 표시를 해하는것이 최상의 작업형태인데

정반로로 작동하고 있어서..실제 백업복원에는 활용하지 못할것 같습니다

 

pecmd.exe ImageX 백업 프로그램을 만들때 진행바를 적용해 본적이 있습니다..이때에는..,cmd 내용을 txt로 저장하고 1초에 한번씩 읽어

서 표시를 하여 주었습니다

 

wimlib-imagex.exe로 복원시에 %를 보여주는 작업이 4번 있습니다..%값이 순각적으로 막 높아지는 경우에도 78RePack 소스에서는 다

보여주는것을 보면 1초에 수십번 이상 같의 변화를 읽어오는것 같습니다..그래서 런처에서 cup를 백업 프로그램보다 더 많이 사용을 하게

되는것 같습니다

 

78RePack 소스에서 1초가 간격으로 cmd 내용을 읽어서 보여주면 좋은데요..정확한 명령어를 알지 못하고 있어서 이 부분은 활용하지

못하고 cmd 내용을 txt로 저장후 이것을 1초에 한번정도 읽어와서 %를 보여주는 방식으로 다시 해봐야할것 같습니다

 

백업은 그나마 조금 시간이 더 걸리더다도 감수를 할수 있지만 복원은..너무 시간이 많이 걸려서..78RePack 소스를 활용하는것을 이정도

에서 무리를 하고..단순히 적용해 보았다는 정도로 만족을 해야 할것 같습니다

 

 

1. 78RePack에서 배운 방식을 활용하여 보았습니다..버튼은 1개만 있습니다...백업 파일이 없는 경우 복원 라디오 버튼은 비활성이 됩니다

 

2. 백업 메세지입니다

 

3. 백업, 복원 진행시에 버튼은 취소 버튼으로 변경이 됩니다..백업이 진행중입니다..백업 테스트시까지는 시간 찾이가 나는것을 별로 느끼

 지 못하였습니다.

 

4. 런처에서 % 값을 보여주는 작업을 하지만 wimlib-imagex.exe 가 cup의 대부분을 사용하고 있습니다..이런 모습이 정상이죠

 

5. wimlib-imagex.exe 사용량도 오르락 내리락합니다.런처 사용량이 점점 증가를 할때가 있습니다

 

6. 마무리 작업시에는 왼쪽에 작업중인것을 표시를 하여 줍니다..완료시에는 %자리에 완료 표시를 하여 주고 3초후 자동 종료 됩니다 

 

7. 백업 파일이 있으면 복원이 자동 선택이 됩니다

 

8. 백업 라디오 버튼을 선택을 하면 백업 버튼으로 변경이 됩니다

 

9. 전용 PE로 부팅한 모습입니다...바로 복원 버튼을 클릭할수 있도록 진행바가 있는 창에 안내 메세지를 보여줍니다

 

10. 복원중입니다 복원 과정에서 %가 사용되는 경우가 4번 있어서..작업에 해당하는 안내글을 왼쪽에 보여줍니다.

  cup를 100로 사용하고 있지만..런처가 대부분을 차지를 하고 있어서 복원 속도가 cmd로 복원하는것보다 많이 느립니다

 

11. wim에서 파일 추출 작업중입니다..여기에서 시간이 제일 많이 걸립니다

 

12. 마무리 작업 메세지입니다

 

13. 완료가 되었습니다

 

14. cpu 사용량이 확인하기 위해서 pe에서 복원을 진행하였습니다.. 백업 프로그램이 cpu의 최대 97%가지 사용을 하는 경우도 있습니다

 

15. 마무리 단계에서는 cpu 사용량이 조금 줄어드네요

 

16. pe에서 실행 모습입니다

 

17. 복원 메세지입니다

 

18. 무결성 확인 하는 %값은 빠르게 진행이 됩니다..이 값을 다 보여주는것을 보면..런처에서 엄청 짧은 시간마다 cmd 내용을 읽어오는것

  으로 짐작이 됩니다

 

19. 파일 생성 과정중입니다..런처 사용량이 13%로 아직은 감수할만합니다

 

20. 시간이 제일 많이 걸리는 파일 추출 과정입니다.. 백업 프로그램이 아니라 런처가 최대 91%까지 cup를 사용합니다..

  이런 현상으로 복원 속도가 cmd에서 복원하는것보다 많이 느려집니다..

 

21. 런처에서 계속 cpu를 많이 차지하고 있습니다.. 백업일때에도..%를 보여주는 작업이 같은것입니다..그런데 복원에서만 이렇게 런처가

  cup를 많이 차지하네요

 

22. 마무리 작업중입니다..여전히 cup차지는 런처가 하고 있습니다

 

23. 윈도우에서 78RePack로 최적화 중입니다..복원하는것과 진행하는 방식이 달라서 인지 런처에서 % 값을 읽어것이 cup를 적게 차지하고

  있습니다

 

24. 다행히 최적화시에는 프로그램이 cpu를 대부분 차지하고 있습니다.런처가 차지하고 있다면 최적화도 다시 cmd로 해야할뻔 했습니다

 

25. 추가입니다

     최적화 소스에서 복원 명령어로 바꾸고 우클릭 메뉴에서 진행을 한것입니다...런처에서 cup를 88%를 차지고 하고 있습니다

     파일생성 과정이어서 시간을 믿을것이 못됩니다

 

26. 파일 추출과정중입니다..런처가 cpu를 99% 차지하네요..완전히 반대로 작동하고 있습니다..

 

27. 마무리

솔직히 78RePack에 있는 진행바 소스에 많은 기대를 했었습니다..

최적화시와 복원시 방식의 차지인지..복원시에 런처 작업량을 줄이기 위해 시간 표시도 제외를 했는데 cpu 사용량이 너무 많네요

%는 잘 보여주고 있지만 복원 속도가 cmd로 바로 복원할때 보다 많이 느려서 실전에 활용하기는 어려울것 같습니다...

 

좀더 여러가지 테스트를 해보고 다른 방식을 사용할지 결정을 내려야 할것 같습니다

많은 아쉬움이 남네요

 

오늘 저녁에 드디어..한국전이 열리네요

다른 나라들처럼...실력으로 기적을 만드는 날이 되었으면 합니다

대~한민국!! 화이팅입니다