Creo que la razón es bastante clara..

Para una empresa que empieza, poner un precio competitivo, exige ahorrar en costes en alguna parte. Metiendo Linux, ya tienen ese ahorro y el cliente un S.O. totalmente funcional.

No creo que haya que darle más vueltas. Linux sigue sin despegar después de más de 2 décadas...
Las interminables versiones... haciéndose la autocompetencia tampoco ayuda.
Y el exagerado abuso de las consolas (para adentrarte en todo), espanta al usuario que se considera torpe.
Yo mismo me cansé de tener que andar con comandos. Resulta cansino tener que aprenderse de memoria cada comando de cada programa, solo para ver que luego en la próxima versión hay más cambios y que de nuevo vas a tener que aprenderte más cosas de memoria (cosas que ya sabías).
La ventaja de la interfaz, es que no necesitas memorizar prácticamente nada, solo ir al menú, buscar opciones y recorrerlas todas para elegir las opciones de tu preferencia, y si la nueva versión tiene cambios, no tienes que lidiar con tu memoria y te importa un EGG, que hayan cambiado de nombre o el comando asignado, ...desde la interfaz simplemente sigues seleccionando lo que prefieras.
Y mientras los desarrolladores de Linux, no se metan esto en la cabeza seguirá siendo un S.O. minoritario y relegado (y es una lástima, porque potencial le sobra..).

Soy de ambos, aunque me decanto más por el VLC, del MPC, lo que siempre me gustó mucho es la posibilidad de expandir la imagen de vídeo incluso deformando la relación ancho/alto... y lo cómodo y fácil que resulta...

Los hashes no se 'crackean'. Los hashes no son cifrados (aunque se puede cifrar como todo).

Un hash es tan solo unos datos que hacen referencia al objeto del que provienen como un método de verificar que porceden de él, mediante el uso de un método específico.

No es distinto de reconocer a una persona como legítima... imagina el siguiente ejemplo:
Trabajas en una tienda, una joyería por ejemplo, el jefe se ha ido y tu te quedas al cargo.
Entra un señor y dice que quiere vender su Rolex, que vale por lo menos 50.000 tu después de tratar con él lo rebajas a 25.000... cuando viene el jefe dice que es falso, y que por tanto no vale más de 25, 50, así que tras mirar los datos de compra, el tipo firmó como John Smith y que vive en La Luna... entonces os dais cuenta d ela estafa, se llama a la poli y te pide 'referencias' del tipo...
Este es el 'hash' que tu generas para ese tipo: estatura: 1'90 aprox. pelo canoso corto, delgado, con barba y gafas, zapatos rojos, traje a rallas, etc...

Esto es una representación (hasta cierto punto) fidedigna de ese tipo. en informática a esto se le llama HASH, y sirve para lo mismo, reconocer si un 'sujeto' (fichero en el ámbito informático), corresponde o no con dicho hash. es decir si el resumen que se hizo previo es idéntico al resumen que hagamos ahora mismo. Si es distinto, sabemos que no es el mismo, que como mínimo ha cambiado desde entonces...
Que coincida el hash, no asume con absoluta certeza que sea ese el fichero (a esto se llama colisión), lo mismo que cualquiera que encajara en esa descripción del sospechosos no tendría por que ser el 'timador' que busca la poli.

Entonces igual que una descripción de una persona es inútil para encontrar a la persona en sí ni mucho menos para conocer más datos d ela persona que los que recoge la descripción (exigiría compararlo con todas las personas (al menos de la localidad)), del mismo modo el hash no tiene capacidad para identificar de qué fichero procede ese hash, ni tampoco saber más detalles del fichero.

Un hash por ejemplo que aporta info adicional, es el ed2k (el hash que genera emule), que porta datos del tamaño del fichero... peor en general los hashes no aportan nada más que el 'resumen' que genera un método específico que es lo que da nombre al hash.

...aunque da igual, no pasa un mes sin que alguien haga la misma pregunta...

Te pongo el pseudocódigo de lo que podría ser la estructura de una pila. Tu luego lo transformas a código NET, y después creas la interfaz para usarla...

Es mejor separar siempre que sea posible, el objeto que se crea de la operatoria que haga el cliente con ese objeto.

Entonces crea un nuevo proyecto, llámale  como quieras, luego añade una clase y llámala Pîla


Éste pseudocódigo es un sencillo código pero completo para una pila. Incluso contiene dos métodos para consultar el estado de la pila (estaLlena y EstaVacia), que no son imprescindibles, pero internamente las vamos a usar, así que por que no hacerlos públicos...

Cómo usarla ?:
La pila es limitada, al valor que se le indica cuando se contruye una instancia de la clase. Es decir, tú puedes hacer uso de la pila por ejemplo desde una ventana o desde otra clase, lo mejor para probarlo es crear unos botones en un formulario y unas cajas de texto, los botones podrían ser 'crear()', Meter(), Sacar:  (los paréntesis en Crear y Meter, indican que requieren un parámetro que podría tomarlo de una caja de texto asociado a dicho botón.

Crear una instancia de la pil:

Esta pila tiene varias limitaciones, no solo la cantidad de elemntos que puede contener (las pilas en general se diseñan para contener pequeñas cantidades, no cientos de millones, rara vez se necesitará un pila muy grande, un ejemplo de esas excepciones son precisamente los programas compiladores.
Bueno, otra limitación de esta pila es que la hemos limitado al tipo de datos entero. como es un proyecto de prueba, es suficiente, pero podrías hacerla de cualquier tipo incluso para admitir cualquier tipo...

Una Pila, es una estructura para guardar elementos y luego obtenerlos en orden inverso a como se metieron, es decir, la forma lógica de verlo, es imaginandose poner un libro en el suelo y lueo otro encima y luego otro y luego otro... esto es: "apilar libros"... directamente solo puedes coger el último, el que está arriba en  la cima, para coger otro más abajo, debes primero retirar los que tienes encima. Las pilas, por esto mismo se usan en casos donde se requiere precisamente mantener ese orden (inverso al que se ha metido).

Apilar datos:

Probar los métodos y propiedades:

Retirar datos:

etc....

Si tienes alguna duda, pregunta...

p.d.: no te conformes con ejecutar el proyecto a "saco" (F5, run), si no paso a paso (F11, debug... no recuerdo si en C# es también esa tecla F11 )

Lo siento, pero todos esos 'millones' que tú dices es insignificancia... Se pueden gestionar ficheros de hasta gigabytes de tamaño con cierta soltura.

Split, está pensado para cadenas de texto pequeñas, si tienes que manejar archivos muy grandes entonces hay que trabajar a un nivel mucho más bajo, manipulando bytes, aunque tampoco hace falta llegar al ensamblador.

...pero es que ni siquiera te has molestado en explicar si tus datos tienen o no un formato fijo y estricto, ni mucho menos el formato del 'fichero gigante' que dices tener... Pero tú mismo, si no quieres hacerlo eficiente, es cosa tuya... Perder el tren por llegar tarde es una cosa, perderlo por orgullo, es tontería.

No. La base puedes considerarlo la parte común a todos los lenguajes e independiente de ellos. Toca un poco todos los palos.
Y basta que sea a nivel conceptual, aunque al menos la parte matemática debe quedar muy clara. Con una buena base, luego es muy asequible avanzar, sin la base es frecuente tropezar casi con cada cosa que tenga algo de complejidad.

Busca algún libro sobre "fundamentos de programación"... No te preocupes si al principio, no entiendes demasiado, a medida que avances y lo leas 3 o 4 veces, lo verás todo bastante claro, es cuestión de que puedas atar cabos, mientras habrá cabos sueltos por todos lados, cuando logres empezar a atarlos, la complejidad desaparece y todo lo que queda es el trato del inglés...

No entiendo nada.
Si quieres programar, y dedicarte a esto, lo primero e imprescindible es aprender lo básico y elemental, al margen de cualquier lenguaje de programación.

Tienes que saber operar con números, tienes que entender los números negativos y las bases binaria, hexadeciaml y octal (la decimal se supone que uno lo tiene).
Tienes que saber que son las operaciones lógicas, aritméticas, qué son los condicionales y las bifurcaciones, que son las funciones, propiedades, variables, secciones de código...
Tienes que saber la diferencia entre la ejecución compilada e interpretada y por lo mismo que es depurar/'debugar' un programa.
Tienes que conocer las estructuras básicas de datos: array, estructuras, listas enlazadas, pilas (FIFO), colas (LIFO), árboles, ficheros y de las bases de datos al menos algo somero...

...y todo sin profundizar, lo básico al menos. Solo entonces es cuando puedes decantarte por un lenguaje y avanzar en profundidad, si todo lo básico lo conoces, nada en un lenguaje va a ser tan complejo que te resulte incomprensible.

Sin un conocimiento básico, es perder el tiempo. Es como querer arreglar un avión cuando no conoces ni como funciona una bicicleta.

Es impòsible poder prestar ayuda útil a alguien que carece de conocimientos básicos... ¿qué baldosa puedo decirte que pises si tu no la conoces y yo ignoro lo que tu desconoces?. Cuando alguien se pone a programar se le supone que sabe lo básico y si no es así, su prioridad no debe ser otra que adquirir esa base... se torna absurdo querer conbstruir un avión, cuando uno no sabe lo que es un ala, ni un motor a reacción ni siquiera un tobera de escape, ni una hélice. ¿¿¿Cómo se supone que vas a hacer algo que no sabes ni cómo es, ni de qué piezas se compone????.

Vaya... es que eres duro de mollera. Se te ha explicado de todas las maneras posibles y sigues sin entenderlo. Y eso de llegar a nada, lo siento, solucion se te ha dado, otra cosa es que tu desistas de usarlas...

Eso es lo que se ha dicho una y otra vez... y no que no se pueda si no que las soluciones no son eficaces.


FALSO. Ya te comenté eso, otra cosa es que en tu ignorancia no sepas verlo...

Tu problema más elemental se traduce en que no aclaras (ni aún a estas alturas), para que rayos necesitas hacer eso, porque es fijo que hay una manera óptima de tratar los datos, pero tu te cierras en banda en querer usar un array mutidimensional porque sí, y solo si... (y además sin usar un bucle para volcarlo). Es como si alguien dice que quiere ir a la Luna, y contrata a una empresa aeroespacial, pero al final resulta que "quiere ir con su motocicleta y no admite ninguna otra cosa". Pues va a ser que así solo irás al pueblito de al lado o a otra ciudad... pero jamás a la Luna.

Si quieres y realmente lo necesitas, explica como tienes los datos en ¿el fichero?, y explica pará que vas a usarlos y por tanto qué datos son precisos y olvida la parte de cómo o de qué manera hay que tratarlo, eso ya se te aclara... deja abierto que te sugieran como tratar los datos, no te obceques en querer hacer algo de una manera específica. Es seguro que hay mucha maneras de hacerlo óptimo, pero 'usando tu moto, forzosamente', nadie se va a comprometer a que sea óptimo...

A ver, yo personalmente no critico a nadie... la idea de responder es ayudar...

Igual que señalo fallos en el código, señalo fallos en el programador. Pero porque a veces el fallo está en el código y a veces el fallo está en el programador.

Si Elektro te puso el código que cumple tus necesidades y tu luego copias y pegas y añades código superfluo, ahora demuestras que el fallo está en el programador, luego señalo el fallo encontrado...

Si el fallo está en el código, pués señalo por donde puedes avanzar, con código y más a menudo con pseudocódigo. y si el fallo está en el programador, también señalo como avanzar o como evitar o solucionar el tema. De hecho mi mensaje previo está repleto de instrucciones y alternativas, que puedes seguir...

Si tú solo crees que los fallos están el código y que tu no debes 'corregirte' entonces seguirás siempre en la 'oscuridad' sin aprender nada, si no tras tropecientos mil intentos...

No te lo tomes a mal, nadie está aquí para molestar, aprende y sigue adelante...

claro que te entendí... el código y explicaciones que pusiste (y que repito aquí debajo) son suficientemente claro:

' tengo esta variable llamada cadena que es igual a
dim cadena as string = "0-1-2-3-4-5-6-7-8-9"
' y declaro una matriz de 1x10 así
dim matriz(1,9) as string
 
' quiero hacer split y que el resultado sea almacenado en la posicion 0 hasta 10 de la matriz sin hacer esto
dim vector() as string
 
vector=split(cadena,"-")
for x=0 to 9
   matriz(0,x)=vector(x)
next
 
' ... quiero guardar el vector en una fila de la matriz ... y quiero ahorrarme el ciclo
 

Sin embargo, eres tú quien parece no haberme entendido...
Ningún lenguaje se dedica a crear funciones peregrinas para resolver un único caso que se va a usar 1 vez cada 5 años por parte de algún programador... máximo, cuando lo mismo puede hacerse con 3 líneas de código y para colmo a cambio de una complejidad extrema (sería preciso para que fuera útil del todo declarar que partes del array deberían mantenerse, lo que exigiría copias posteriores que lo harían lento).
Pero el principal problema por el que ningún lenguaje ha hecho ni hará jamás (salvo que lo formen chiflados), es crear una función cuyo resultado a priori se desconozca, y por tanto que deba crear y redimensionar un array y que en vez de ello, derive a un array administrado por 'el usuario', para volcar el contenido, pero antes redimensionarlo y J0D35L3 el contenido actual, o a cambio de una complejidad extrema donde declare que partes exigen ser mantenidas... y la función deba restaurar esas partes previas verificaciones de si el nuevo tamaño, lo va a permitir (ajustado a la perfeccción), si va a sobrtar contenido nuevo, o si se va a destruir contenido existente...

- Cuando vas a hacer Split, de entrada no sabes cuantas apariciones habrá, por eso en un primer momento han de contarse (si se quieren guardar en un array), para luego redimensionar el array a la cantidad encontrada y en otro paso volcar ahí los datos. Si en vez de un array se usara por ejemplo una lista enlazada, podría hacerse todo en un solo paso, pero la ventaja de los arrays recae en la contigüidad de sus elementos, y de ahí la facilidad de encontrar la dirección de memoria del elemento 'x'... y con ello la velocidad de acceso.

- Si tu tienes un array ya declarado con más de una dimensión, ese array ya está definido a tener 'x' dimensiones por 'y' elementos en cada dimensión (suponiendo uno de 2 dimensiones). Un Split, podría hacer una de dos cosas sobre un array así: Redimensionarlo de nuevo para que tenga el tamaño que encuentre el 'splitado', o bien usar el espacio actual que tenga el array no redimensionándolo en ningún caso y en tal situación que queden ocurrencias sin copia. ó indices sin una reocupación (con basura del contenido previo). ambas situaciones son una chapuza.... peroooooooooo... si ese es tu caso, YA te puse código para una función que hace eso, luego no vengas con que no te entendí.... prueba la función más arriba y dime si lo hace o no (que desde luego lo hace, porque la he probado).

- Pero el problema es que tu ya tienes ese array, en cambio Split, devuelve un array que Split crea. Split no admite (en ninguna sobrecarga) como parámetro de entrada un array tuyo donde volcar el contenido. Luego Split, no hace lo que tu pides (cierto es que no he probado aún VS-2017, pero dudo mucho que hagan eso ni ahora ni nunca. Es más si a alguien se le ocurriera tamaña patraña, creo que lo despidirían ese mismo día).

- Te decía también, que es posible tras obtener el array que devuelve split, volcar en contenido en tu array (sin usar un bucle), haciendo uso de Marshalling, para operar con punteros de dirección y hacer un: copyMemory(ptrDestino, ptrOrigen, NumBytesACopiar)...
...pero francamente el código necesario en NET para esto, es mucho más que las 3 PUT45 líneas sencillas de un bucle (en vb6 sería solo la línea de código de la llamada a la función, pero en NET al operar con memoria administrada se requiere más código aunque luego compilado no difiera mucho).

- Y en cuanto a la velocidad de copia, creo que estás subestimando los procesadores.... trata de hacer pruebas de velocidad de asignación entre bucles y demuéstrame que es lento, dime cuantos millones de índices por segundo es capaz de transferir tu equipo entre 2 arrays... sin conocer nada de tu equipo, apuesto que más de 20millones por segundo, así que tu aseveración de que 'es lento' es pueril e injustificada.

---------
p.d.: En programación se puede hacer cualquier cosa, pero eso no significa que sea admisible hacer cualquier cosa, hay aberraciones y esta que propones (por no usar un bucle) es una de ellas. Francamente eso dice muy poco a tu favor como programador...

Desde el momento en que se deba realojar memoria para copiar datos y deba modificarse una infinidad y la complejidad lo haga costoso, será relativamente más sencillo proveer una array adicional que se crea en el momento preciso y se destruye cuando ya no se requiera, y se deje el resto 'en paz'.... en general esta ecuación suele ser casi siempre cierta: Mayor sencillez = mayor velocidad.

En fin si no entiendes todo esto que te digo, es que tu madurez como programador aún está muy verde...