majstang Posted September 24, 2017 Share Posted September 24, 2017 I think you should start considering porting the entire DVBViewer application project to 64 bit soon. Most Windows users have 64-bit OS today and 64-bit with HEVC have nice benefits. Its imperative keeping up with changes of time for DVBViewer to stay amongst the top choices. Quote Link to comment
Tjod Posted September 24, 2017 Share Posted September 24, 2017 http://www.DVBViewer.tv/forum/topic/56578-64-bits-version/ Quote Link to comment
majstang Posted September 24, 2017 Author Share Posted September 24, 2017 Yeah, I can imagine its much work, but it is crucial to do it for the survival of the software whether you like it or not. VideoReDo is pretty much in the same situation (only 32-bit and no HEVC editing capabilities) and are loosing market shares to video editors supporting 64-bit with HEVC. Regarding the high-cost argument for the delphi version required to start a porting, which version do you have? As far as I know you are abled to compile OSX apps and all versions you can do that with are also supporting Win64. Quote Link to comment
Griga Posted September 24, 2017 Share Posted September 24, 2017 20 minutes ago, majstang said: which version do you have? Delphi 7, released 2002, fully XP compatible Quote Link to comment
McenterFreak Posted September 24, 2017 Share Posted September 24, 2017 Not even Microsoft full support 64 bit. https://support.office.com/en-us/article/Choose-between-the-64-bit-or-32-bit-version-of-Office-2dee7807-8f95-4d0c-b5fe-6c6f49b8d261 They only recomends it if yoy really need it Quote Link to comment
majstang Posted September 24, 2017 Author Share Posted September 24, 2017 1 hour ago, Griga said: Delphi 7, released 2002, fully XP compatible ...and what happened with the Delphi XE2 version Christian bought 2012? That expensive badboy version was the reason I bought 2 additional DVBV licenses and Lars started developing the 64-bit DVBViewer Recording Properties.v.2.0 Beta and Lars and Christian started developing the OSX DVBViewer. Quote Link to comment
Griga Posted September 25, 2017 Share Posted September 25, 2017 Well, Christian is playing with this modern stuff, writing apps for fruit company computers and telephones... I'm not in touch with it. And he used it to compile DeviceReset_64.exe that has been added lately to DMS installations in order to enable DVB device reset under 64 bit Windows. Quote Link to comment
hackbart Posted September 25, 2017 Share Posted September 25, 2017 Frankly i don't see any afford in porting the DVBViewer to 64bit. I also have a Rad Studio subscription and the Mac Version is build on Tokyo. What i did a while ago was to build Transedit under XE5 with a portability in mind. It got stuck with tons of errors, raised by problems caused of the fact that we used Ansi and not Unicode under Delphi 7. Quote Link to comment
majstang Posted September 25, 2017 Author Share Posted September 25, 2017 Well, porting DVBViewer might be easier cuz at least large portions of it is already Unicoded, which Transedit isnt afaik. It cant hurt to at least draw up a porting plan to determine the magnitude of the effort required for the port and make a decision form there. MS provides good guidelines for it, which might be helpful. https://msdn.microsoft.com/en-us/library/windows/desktop/aa384190(v=vs.85).aspx Quote Link to comment
Griga Posted September 25, 2017 Share Posted September 25, 2017 Particularly porting my beloved assembler contributions will be big fun Dunno how many mails I already got from Christian asking "What is this in Delphi?" Quote Link to comment
majstang Posted September 25, 2017 Author Share Posted September 25, 2017 (edited) 1 hour ago, Griga said: Particularly porting my beloved assembler contributions will be big fun @Christian...See Griga is on board DVBViewer should remain top of the line many years to come, which will bring additional business Oh and there should be a short learning-curve for as skilled developers as you guys are Edited September 25, 2017 by majstang Quote Link to comment
jenzi80 Posted September 28, 2017 Share Posted September 28, 2017 Just declare the DVBViewer we have bought now as 32 bit version. Then make a 64 bit version which has to be bought separately. Then you sell the 32 bit version and a 64 bit version which is priced somewhat higher. Than you can make some discount when someone already has bought 32 bit version. And then hope for a Windows which only supports 64 bit apps Quote Link to comment
majstang Posted September 28, 2017 Author Share Posted September 28, 2017 8 minutes ago, jenzi80 said: Then you sell the 32 bit version and a 64 bit version which is priced somewhat higher. Than you can make some discount when someone already has bought 32 bit version. Yes, very sensible suggestions, cuz most porting projects of this magnitude usually requires a very big work effort. Quote Link to comment
hackbart Posted September 28, 2017 Share Posted September 28, 2017 As i said it is not really easy to port the application to 64bit and beyond. By sheer coincidence i currently continued working on a Delphi 10.2 based version of Transedit. We do have a lot parts in the code which uses strings and PAnsiChar as pointer to these strings. The compiler does not have a problem with it, but in Delphi 7 strings are Ansistring. So you have to fix every line where you use pointers. Newer Delphi compilers do not like Ansichar and Ansistrings, so you have to use TBytes instead. A simple 100kb in size Unit called JVSimpleXML2 for example is driving me nuts, because it is heavily optimized by Lars in the past and does not work with newer compilers. I have to rewrite this unit which takes hours if not weeks. Quote Link to comment
Bernhard Schornak Posted September 28, 2017 Share Posted September 28, 2017 On 25.9.2017 at 12:00 PM, hackbart said: Frankly i don't see any afford in porting the DVBViewer to 64bit. I also have a Rad Studio subscription and the Mac Version is build on Tokyo. What i did a while ago was to build Transedit under XE5 with a portability in mind. It got stuck with tons of errors, raised by problems caused of the fact that we used Ansi and not Unicode under Delphi 7. There are tons of converters from ASCII to Unicode and vice versa. If you do not use characters beyond ASCII 0x7F (lower + upper case Latin characters, punctuation and numbers, no Umlauts), it is sufficient to clear a register, load each char into its byte portion and store the word register: xor eax, eax ... movb al, [input buffer] movw [output buffer], ax ... Using SSE, this could be done even faster, e.g. using PUNPCKLBW with a cleared second XMM register. For Cyrilic, Arabic, Chinese or other scripts, the old source files were encoded in Unicode, anyway. Many source files are written in plain ASCII, but compiled to Unicode executables - a good compiler can do that with adding a simple switch in the makefile. Moreover, 64-bit Windows still supports both - ASCII and Unicode - so it is not necessarily required to convert stuff to Unicode (except you write pure assembler code where you have to use xxxW() rather than xxxA() API calls...). BTW: Do you see no "effort" in porting (I agree! ), can't you "afford" it (e.g. you have no time or money) or do you just consider porting as pointless? Greetings from Augsburg Bernhard Schornak Quote Link to comment
hackbart Posted September 29, 2017 Share Posted September 29, 2017 It is not a conversion it is the fact that the new Delphi compiler does no longer know Ansichar. Quote Link to comment
majstang Posted September 29, 2017 Author Share Posted September 29, 2017 3 hours ago, hackbart said: It is not a conversion it is the fact that the new Delphi compiler does no longer know Ansichar. Ok, if understand this correctly porting DVBViewer to 64-bit would require a total Ansi to Unicode conversion before porting even can take place? How many code lines are we talking about? Perhaps users with vast or some programming experience might be interested to help out (if you let us). The interest of getting this done is probably higher than you realize. The timing for it is perfect as well, considering if HEVC breaks big in one or two years where we can fully utilize all the great 64-bit omptimizations. Most users may also be willing to pay for a 64-bit version. More info on the aftermaths of the Delphi Unicodification 2009: https://stackoverflow.com/questions/4939854/what-is-the-difference-between-widechar-and-ansichar https://stackoverflow.com/questions/26472257/what-is-the-difference-between-ansichar-and-char Quote Link to comment
Bernhard Schornak Posted September 30, 2017 Share Posted September 30, 2017 19 hours ago, hackbart said: It is not a conversion it is the fact that the new Delphi compiler does no longer know Ansichar. I got that. What I still don't get is where the problem really is. If you need to transfer your entire source files to Unicode, better editors like EditPad can do that. If you need to transfer binary data, a simple batch converter (less than 5 KByte of assembler code) can do the job. If it is just the string type declarations (as mentioned in majstang's links), any editor with advanced batch search capabilities should be sufficient. Have a nice weekend Bernhard Schornak Quote Link to comment
Tjod Posted October 1, 2017 Share Posted October 1, 2017 Zitat How many code lines are we talking about? I don't know the over all number but the file for a small part like the web-interface has more the 10000 lines of code. For sure there are multiple megabyte of source code written for DVBViewer and DMS. And then you mostly would need to replace a lot of not longer working third-party library or port them as well. And to see problems you would need to be able to compile it. And therefore you would mostly need every thing to build the DVBViewer and DMS. And I don't thing that many people will get access to everything. And changing the encoding of the source files is mostly the easiest part. Fixing a lot of small things will take the majority of time. I wound assume porting the DVBViewer to 64bit is more work the including e.g. the TS streaming support. Therefore porting the DVBViewer because of HEVC doesn't really makes seance. If the change (no other new features until it is finished) would start now, I would assume that a public version would take at lest 1-2 years. And by then nearly every graphic-card should have HEVC hardware acceleration. Quote Link to comment
oldgringo Posted October 11, 2017 Share Posted October 11, 2017 I guess also all the plugins should be compiled to 64-bit and this might be even worse problem than the main application. Some plugins are closed source, many of them are not maintained anymore. I find it a blind alley. Quote Link to comment
majstang Posted October 12, 2017 Author Share Posted October 12, 2017 (edited) I dont think you get the point with a 64-bit porting and this argument is far from valid If doing it correctly the 64-bit product should share the same code base as the 32-bit. Then you ensure that your code can be compiled for both 32- and 64-bit Windows. Those who wants to keep running 32-bit plugins can do so with the 32-bit version and if you rather want to utilize the benefits of Intel Itanium optimizations can use the the 64-bit version, but without the 32-bit plugins. Futhermore I dont get which plugins are that important you cant do perfectly fine without? But dont worry, a 64-bit porting wont happen if juding from the non-existent interest from the boss, who seem to think that the task is too complicated as if there is no learning-curve (encountered problems are often timeconsuming to solve at first but easy the second and third time around) and the problem diversity usually isnt that large in a porting project. Of course without a detailed porting plan where every problem is counted for: - Examine the extent of the errors and warnings - Shared components or dependencies. - Legacy or assembly code. ...there is no way to know how much work there will be...afaik christian has only mentioned a few problem areas in the Transedit code (although I suspect DVBV and Transedit shares much of the same code) and DVBV has not been examined in a 64-bit porting context. Tjod argue that most graphic-cards should have HEVC hardware acceleration in 1-2 years, which is correct and that fact alone takes away the main point of doing 64-bit porting. The problem is hardly anyone can say how many more years Windows will support 32-bit (which was introduced 1985). When/if the 96/128-bit processor comes, change can occur much faster than anyone could have predicted. Then you really dont have a choice. Edited October 12, 2017 by majstang Quote Link to comment
hackbart Posted October 14, 2017 Share Posted October 14, 2017 A wise person said: If somebody want something he will find ways, otherwise he will find reasons. To be honest. I already created a platform independent version which runs on 64bit systems and 32bit systems, no matter if they are x86/x64 or arm based. It is not the lack of interest, it is just the fact that there is simply no need to create a 64bit build of the DVBViewer or Media Server. There are simply no efforts. It would not increase the performance magically or whatever. It would be different for sure, if Microsoft would drop the support for 32bit in general. Till then we don't see any reason to go this step. I will close this topic, because it is a road to nowhere and believe it or not. There are only two persons who have enough insight to argue. This is Griga and me, and we both say no Christian Quote Link to comment
hackbart Posted October 15, 2017 Share Posted October 15, 2017 We (the moderators and i) discussed the pro's and con's of closing this topic, so i reopened it. The main reason was that the thread does not violate any of our terms, so there is no real need to close it. Anyhow i won't go into much detail explaining why i have no plans to build a 64bit version, so you have to trust me that it would take weeks if not even months to get it at least compilable. After this it would take even much more time to find all bugs caused by such a port. It is not just a compile for 64bit. We have to get through all classes and rewrite every piece of code where we use things which can not be used on a non 32bit platform. This would go from the pointer handling up to the string handling. A short summary of the no go's can be found here: http://docwiki.embarcadero.com/RADStudio/Berlin/en/LLVM-based_Delphi_Compilers Quote Link to comment
Griga Posted October 15, 2017 Share Posted October 15, 2017 I have no time to deal with this topic because I'm busy with the 6.0.4 / 2.0.4 release preparations. Just a short statement: From my point of view porting the code to 64 bit doesn't make sense. It is so much linked to / dependent on the old development environment / old file formats / libraries / add-ons / components / compatibility requirements, all this historical stuff from the early 200x years, fully XP compatible... Regarding our resources, it will rather come down to dropping DVBViewer / Media Server / TransEdit etc. development and focus on rewriting / redesigning the apps from the scratch. Parts of the old code will be re-usable, the experience gained in many years will be helpful, but who knows to which extent and how long it will take? Maybe years until the current feature level is reached. And who knows if some years from now a DVBViewer / Media Server with a DVB core is still something people want / need? To be true, I'm not sure if I will participate in this... maybe in my next life. Maybe I will rather retire if creating 64 bit versions becomes inevitable or confine myself to consulting. Someone younger than me with more innovative spirit should drop in and take over. Quote Link to comment
oldgringo Posted October 16, 2017 Share Posted October 16, 2017 (edited) On 12. 10. 2017 at 2:13 PM, majstang said: I dont think you get the point with a 64-bit porting and this argument is far from valid If doing it correctly the 64-bit product should share the same code base as the 32-bit. Then you ensure that your code can be compiled for both 32- and 64-bit Windows. Those who wants to keep running 32-bit plugins can do so with the 32-bit version and if you rather want to utilize the benefits of Intel Itanium optimizations can use the the 64-bit version, but without the 32-bit plugins. Futhermore I dont get which plugins are that important you cant do perfectly fine without? But dont worry, a 64-bit porting wont happen if juding from the non-existent interest from the boss, who seem to think that the task is too complicated as if there is no learning-curve (encountered problems are often timeconsuming to solve at first but easy the second and third time around) and the problem diversity usually isnt that large in a porting project. Of course without a detailed porting plan where every problem is counted for: - Examine the extent of the errors and warnings - Shared components or dependencies. - Legacy or assembly code. ...there is no way to know how much work there will be...afaik christian has only mentioned a few problem areas in the Transedit code (although I suspect DVBV and Transedit shares much of the same code) and DVBV has not been examined in a 64-bit porting context. Tjod argue that most graphic-cards should have HEVC hardware acceleration in 1-2 years, which is correct and that fact alone takes away the main point of doing 64-bit porting. The problem is hardly anyone can say how many more years Windows will support 32-bit (which was introduced 1985). When/if the 96/128-bit processor comes, change can occur much faster than anyone could have predicted. Then you really dont have a choice. Rewriting of the code to a 64-bit is only a small piece of necessary work. I know what I am talking about, I was a system programmer for many years. And many of us have the HEVC hw acceleration just today (if we omit missing hevc codecs, I know there are some but they are too far from ideal). So look at the situation also from a business perspective - just ask for a number of downloaded copies of x64 version of ProgDVB. You would probably be very surprised about the small number. And it is the only one application that supports x64! In fact there is a lot of PC sat cards which doesn't support hardware CI slot (and some even doesn't have x64 driver at all!) so without functional soft cam and smartgo/phoenix reader they would became unusable. Do you know some 64-bit soft cam with support of all current systems? That's first and major full stop for big part of PC sat users. Why should somebody buy a new equipment if there is fully functional 32-bit version of the application which works perfectly with their old equipment? Another part are plugins for streaming/recording support for a different sat receivers (like Dreambox etc.). Why would somebody need a 64-bit version of a plugin to communicate with 32-bit software of these receivers? But for proper work with 64-bit application these plugins should have been rewritten to 64-bit too and then tweaked back to communicate with 32-bit linux clients. Weird? There is only a small part of the users with "geek approach" who want to get the maximum from their hardware for any price (including me :-P). As for the Windows 64-bit transition you probably know that 64-bit system fully supports 32-bit applications. So even if MS once would say "Enough of Win32!" they will need to have a backdoor for the old 32-bit applications. In fact they cannot get all their products together to the 64-bit base for a years. Believe me, it's not a short time development. So I agree with board guys that this might be taken a long-term task. Meanwhile they can ask for help some skilled young programmer (for x32 -> x64 code cleanup) or look around for a young people with fresh ideas. Edited October 16, 2017 by oldgringo Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.