79 reputation
18
bio website osmanturan.com
location Mersin, Turkiye
age
visits member for 2 years, 7 months
seen Mar 15 at 9:25

I'm Electrical-Electronics Engineer and co-founder of eBilge Internet Technologies.


Jan
22
awarded  Enthusiast
Dec
30
awarded  Supporter
Dec
30
awarded  Scholar
Dec
30
awarded  Benefactor
Dec
30
accepted Is there any license restriction to avoid binary translation of CIL to custom bytecode?
Dec
30
comment Is there any license restriction to avoid binary translation of CIL to custom bytecode?
I've read both your answer and it's links several times. Most interesting part was that ECMA 334 (especially Partition III: CIL Instruction Set) is under Microsoft's Community Promise allows anyone to freely implement alternative implementation of .NET. This answers my question precisely. I was afraid of Microsoft would eventually sue me due to using (actually translating) CIL which is Microsoft's intellectual property. Most of my concern's root was Dalvik VM due to it's same thing what I'm trying to do. But, I've read some sources Oracle sued Google for using it's intellectual properties.
Dec
30
awarded  Commentator
Dec
30
comment Is there any license restriction to avoid binary translation of CIL to custom bytecode?
Forth can be considered as high-level IR. So, in that case it's unsuitable for me. Because, most of optimization job will be implemented in my translator. So, final JIT won't do too much job and this will reduce JIT code size. As to Mono toolchain, I can even write my own C# to CIL compiler, if I "really" need it (actually I don't want to implement it due to lack of time). The problem is CIL's intellectual properties.
Dec
29
comment Best practices for moving large MS Access application towards .Net?
Seems you have a larger problem than it seems :) Because, after each my comments, you revealed something new. I'm not familiar with MSMQ BTW. Sorry.
Dec
29
revised Is there any license restriction to avoid binary translation of CIL to custom bytecode?
added 48 characters in body
Dec
29
comment Best practices for moving large MS Access application towards .Net?
I think, my answer is still valid after your edit. I mentioned about two ways. One of them direct access which is revealed useless after your edit, and the other one is make N-Tier application. I think, you should implement a TCP/IP protocol between your application. I especially recommend this method even if you want to run your applications on same machine. Because, in my old experience I've found that DDE is not very reliable for such usages and it's really annoying. One another approach for local applications can be use custom system messages (window messages).
Dec
29
comment Best practices for moving large MS Access application towards .Net?
@MainMa: No problem.
Dec
29
comment Best practices for moving large MS Access application towards .Net?
"...enable data exchange between this application and running MS Access application." if that statement is not related to my answer. Then I simply don't know anything either.
Dec
29
answered Best practices for moving large MS Access application towards .Net?
Dec
29
revised Is there any license restriction to avoid binary translation of CIL to custom bytecode?
added 536 characters in body
Dec
28
awarded  Teacher
Dec
27
awarded  Promoter
Dec
25
awarded  Editor
Dec
25
revised Is there any license restriction to avoid binary translation of CIL to custom bytecode?
edited body; edited tags; edited title
Dec
25
awarded  Student