Jump to content

64-bit porting


majstang

Recommended Posts

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. 

Link to comment

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.

 

clear.cache.gif
Link to comment
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. 

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment
1 hour ago, Griga said:

Particularly porting my beloved assembler contributions will be big fun :)

@Christian...See Griga is on board:D

DVBViewer should remain top of the line many years to come, which will bring additional businessB) Oh and there should be a short learning-curve for as skilled developers as you guys are:bye:

Edited by majstang
Link to comment

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 :D

Link to comment
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.    

Link to comment

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. 

Link to comment
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

Link to comment
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

Link to comment
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

Link to comment
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.

Link to comment
  • 2 weeks later...

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.

Link to comment

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 by majstang
Link to comment

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

Link to comment

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

 

Link to comment

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.

 

Link to comment
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 by oldgringo
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...